MichNet News
Summer 1995
Merit Coordinates U.S. Internet Routing
by Susan R. Harris, Merit
Merit continues to play a vital role in national networking as the Routing Arbiter for the post-NSFNET environment. The five-year Routing Arbiter (RA) project, funded by the National Science Foundation, is the successor to the acclaimed NSFNET backbone project--a seven-year undertaking during which the amount of traffic on the U.S. Internet increased more than 400-fold. Merit was a joint partner in the NSFNET project with NSF, ANS, IBM, MCI, and the State of Michigan. (See Merit Retires NSFNET Backbone Service in the Spring '95 MichNet News.)
Charged with the task of providing routing coordination in the post-NSFNET environment, the Routing Arbiter project represents a partnership between five organizations:
- Merit Network, Inc.
- University of Michigan Routing Operations Center, as a subcontractor to Merit
- University of Southern California Information Sciences Institute (ISI)
- Cisco as a subcontractor to ISI
- National Science Foundation
U.S. connectivity is provided at the four NSF-awarded interconnection points, called Network Access Points (NAPs), by Ameritech (in Chicago), PacBell (in San Francisco), Sprint (in New York City) and MFS Datanet (MAE-East in Washington, D.C.). MAE-West, an additional interconnection point, is provided by MFS Datanet on the West Coast. A NAP is a physical location where network traffic is transmitted through high-speed routers.
Internet service providers (ISPs) that are placing routers at NAPs include Sprintlink, internetMCI, ANS, CERFnet, and many emerging carriers. The RA project's Route Servers-- powerful Sun SPARC 20 workstations running a customized version of the GateD routing software--are also located at the intercon-nection points. As of this writing, seven primary and backup Route Servers have been deployed at the NAPs.
Table of Contents
Route Servers Optimize Routing
Developed for the new architecture, the Route Servers represent a breakthrough in providing scalable, optimized routing at the interconnection points. Each Sun SPARC 20 workstation imports routing information from "peer" ISP routers at the interconnection points. The Route Servers create a "view" (a Routing Information Base) reflecting each ISP's policy requirements, and pass the processed routing information on to each ISP router.
Without the Route Servers, each ISP router would have to exchange routing information with every other router at the connection point. This could require more than a dozen peering sessions per router, and would represent a significant drain on router resources. With each new connection to a NAP, a new routing session would need to be established between the new ISP and each existing ISP (creating an n2 problem). Reducing the number of peering sessions to one (or two, counting the backup Route Servers) dramatically improves the efficiency of each ISP router.
Routing Arbiter Database
The Routing Arbiter Database (RADB) is the successor to the Policy Routing Database, which was long used to generate the configuration files for the NSFNET backbone routers. The RADB is one of several databases collectively known as the Internet Routing Registry (IRR). Other databases in the IRR include:
- RIPE (Reseaux IP Europeens) Routing Registry
- internetMCI Routing Registry
- CA*net Routing Registry
Networks and providers worldwide enter data directly into these registries in order to publish the set of routes and routing policies that an Autonomous System (AS), or group of TCP/IP networks, announces to and accepts from its neighbor ASs.
All the registries base their routing policy expressions on a language called RIPE-181, which was developed by the RIPE Network Coordination Centre and other contributors. Routing policy in the registries is processed and can be used to load the configuration files for the routers that transmit each provider's network traffic--that is, information in the registry determines what traffic can be imported from and exported to the networks that lie behind the routers.
Routing policy in the Routing Arbiter Database is used to configure the Route Servers at the interconnection points. Providers who want to use the Route Servers must register in the RADB or one of the other registries of the IRR.
RADB Ensures Consistent Routing Policy
With the exception of the Routing Arbiter Database, each registry serves a well-defined customer base. MCI accepts routing registrations for its customers only, the RIPE Network Coordination Centre oversees European registrations, and CA*net is authoritative for Canadian registrations. The Routing Arbiter Database is unique in that it handles registrations for networking organizations not covered by the other routing registries.
The Routing Arbiter also collaborates with all the registries to ensure consistent representation of routing policies. In this sense, the RADB is much like the InterNIC, which provides integrated IP registration services for the Internet, but is not the only place where users go to obtain an IP network number.
North American Network Operator's Group
Three times each year, Merit organizes meetings of the North American Network Operator's Group (NANOG). This lively group brings together engineers and managers from Internet service providers, federal networks, and the interconnection points, as well as representatives from the regional networks and the various Internet registries. More information about NANOG and the Routing Arbiter project is available on the Merit Web pages.