Internet Routing Architectures (CISCO):Evolution of the Internet



























Previous
Table of Contents
Next




Internetworking Routing Registries (IRR)
With the creation of a new breed of ISPs that want to interconnect with one another, offering the required connectivity while maintaining flexibility and control has become more challenging. Each provider has a set of rules, or policies, that describe what to accept and what to advertise to all other neighboring providers. Example policies include determining route filtering from a particular ISP and choosing the preferred path to a specific destination. The potential for the various policies from interconnected providers to conflict with and contradict one another is enormous.

To address these challenges, a neutral Routing Registry (RR) for each global domain had to be created. Each RR will maintain a database of routing policies created and updated by each service provider. The collection of these different databases is known as the Internetworking Routing Registries (IRR).
The role of the RR is not to determine policies, but rather to act as a repository for routing information and to perform consistency checking on the registered information with the other RRs. This should provide a globally consistent view of all policies used by providers all over the world.
Autonomous Systems (ASs) use exterior gateway protocols such as BGP to work with one another. In complex environments, there should be a formal way of describing and communicating policies between different ASs. Maintaining a huge database containing all registered policies for the whole world is cumbersome and difficult to maintain. This is why a more distributed approach was created. Each RR will maintain its own database and will have to coordinate extensively to achieve consistency between the different databases. Some of the different IRR databases in existence today are:

•  RIPE Routing Registry (European Internet service providers)
•  MCI Routing Registry (MCI customers)
•  CA*net Routing Registry (CA*net customers)
•  ANS Routing Registry (ANS customers)
•  Routing Arbiter Database (all others)
•  JPRR Routing Registry (Japanese Internet service providers)

Each of the preceding registries serves a limited number of customers except for the Routing Arbiter Database (RADB), which handles all requests not serviced by other registries. As mentioned earlier, the RADB is part of the Routing Arbiter (RA) project, which is a collaboration between Merit and ISI with subcontracts to Cisco Systems and the University of Michigan ROC.

Looking Ahead
The decommissioning of the NSFNET in April 1995 marked the beginning of a new era. The Internet today is a playground for hundreds and thousands of providers competing for market share. For many businesses and organizations, connecting their networks to the global Internet is no longer a luxury but a requirement for staying competitive.

The structure of the contemporary Internet has implications for service providers and their customers in terms of speed of access, reliability, and cost of use. Some of the questions organizations that want to connect to the Internet should ask are: Are providers—whether established or relatively new to the business—well-versed with routing behaviors and architectures? For that matter, how much do customers of providers need to know and do with respect to routing architecture? Do we really know what constitutes a stable network? Is the bandwidth of our access line all we need to worry about to have the "fastest" Internet connection? The next chapter is intended to help ISPs and their customers evaluate these questions in a basic way. Later chapters get into details of routing architecture.
Interdomain routing is fairly new to everybody and is evolving every day. The rest of this book builds upon this chapter's overview of the structure of the Internet in explaining and demonstrating current routing practices.



Frequently Asked Questions
Q—Are there other NAPs besides the four NSF-awarded NAPs?
A—Yes. As connectivity needs keep growing, more NAPs are being created. Many exchange points are spread over North America, Europe, Asia/Pacific, South America, Africa, and the Middle East.
Q—If I am a customer of a provider, do I have to connect to a NAP?
A—No. NAPs are mainly for interconnection between providers. If you are a customer of a provider, your connection will be to the provider only. But how your provider is connected to one or more NAP can affect the quality of your connection.
Q—Is the function of the route server at the NAP to switch traffic between providers?
A—No. The route server keeps a database of routing policies used by providers. Providers use the NAP physical media to exchange traffic directly between one another.
Q—Do all providers that connect to a NAP have to peer with the route server?
A—Although this is the recommended procedure, in some situations, major providers end up peering directly with each other, while smaller providers are required to peer with the route server.
Q—What is the difference between IRs and IRRs?
A—Internet Registries (IRs) such as the InterNIC are responsible for registration services such as IP address assignment. Internet Routing Registries are responsible for maintaining databases of routing policies for service providers.
Q—How are database services different from the Route Arbiter Database?
A—Database services are part of the Network Information Services. These databases include communication documents such as RFCs. The RADB is a database of routing policies.


References
[1] www.merit.edu
[2] www.isi.edu
[3] RFC 1786; Representation of IP Routing Policies in a Routing Registry (Ripe-81++)
[4] ds.internic.net
[5] www.ripe.net
[6] www.apnic.net



Previous
Table of Contents
Next