Internet Routing Architectures (CISCO):Evolution of the Internet

Route Arbiter Project

Another project for which NSF solicited services is the Route Arbiter (RA) project, which is charged with providing equitable treatment of the various network service providers with regard to routing administration. The RA will provide for a common database of route information to promote stability and manageability of networks.

Multiple providers connecting to the NAP have created a scalability issue because each provider will have to peer with all other providers to exchange routing and policy information. The RA project was developed to reduce the full peering mesh between all providers. Instead of peering among each other, providers will peer with a central system called a route server. The route server will maintain a database of all information needed for providers to set their routing policies. Figure 1-4 shows the physical connectivity and logical peering between a route server and various service providers.

Figure 1-4 Route server handling of routing updates in relation to traffic routing.

The following are the major tasks of the RA per the NSFNET proposal:

• Promote Internet routing stability and manageability.

• Establish and maintain network topology and policy databases by such means as exchanging routing information with and dynamically updating routing information from the attached Autonomous Systems (AS)¹ using standard interdomain routing protocols such as BGP (Border Gateway Protocol) and IDRP (support for IP and CLNP).

¹An Autonomous System is a collection of routers under the same administration and sharing a consistent policy.

• Propose and establish procedures to work with personnel from the NAP manager(s), the vBNS provider, and regional and other attached networks to resolve problems and to support end-to-end connectivity and quality of service for network users.

• Develop advanced routing technologies such as type of service and precedence routing, multicasting, bandwidth on demand, and bandwidth allocation services, in cooperation with the global Internet community.

• Provide for simplified routing strategies, such as default routing, for attached networks.

• Promote distributed operation and management of the Internet.

Today, the RA project is a joint effort of Merit Network, Inc.[1], the University of Southern California Information Sciences Institute (ISI)[2], Cisco Systems, as a subcontractor to ISI, and the University of Michigan ROC, as a subcontractor to Merit.

The RA service is comprised of four projects:

• Route server—The route server can be as simple as a Sun workstation deployed at each NAP. The route server exchanges routing information with the service provider routers attached to the NAP. Individual routing policies requirements (RIPE 181)² [3] for each provider are maintained. The route server itself does not forward packets or perform any switching function. Those functions are taken care of by the NAP's physical network.

²The RIPE language is covered in Appendix A.

The server(s) facilitate interconnections between ISPs by gathering routing information from each ISP, applying the ISP's predefined set of rules and policies, and then redistributing the processed routing information to each ISP. This process saves the routers from having to peer with all other routers, thus cutting down the number of peers from (n-1) to (1), where n is the number of routers.
In this configuration, the routers of the different providers concentrate on switching the traffic between one another and do relatively little filtering and applying of policies.

• Network management system—This software monitors the performance of the RS. Distributed rovers run at each RS and collect information such as performance statistics. The central network management station (CNMS) at the Merit Routing Operation Center queries the rovers and processes the information.

• Routing Arbiter Database (RADB)³ [1]—This is one of several routing databases collectively known as the Internet Routing Registry (IRR). Policy routing in the Routing Arbiter Database is expressed by using RIPE-181 syntax developed by the RIPE Network Coordination Center (RCC). The Routing Arbiter Database was deployed in dual mode with the Policy Routing Database (PRDB). The PRDB had been used to configure the NSFNET's backbone routers since 1986. With the introduction of the RIPE-181 language, which provided better functionality in recording global routing policies, the PRDB was to be retired in 1995 for full RADB functionality.

³The RADB is covered in Appendix A.

• Routing engineering team—This team works with the network providers to set up peering and to resolve network problems at the NAP. The team provides consultation on routing strategies, addressing plans, and other routing related issues.

As you have already seen, the main parts of the Route Arbiter concept are the route server and the RADB. The practical and administrative goals of the RADB apply mainly to service providers connecting to the NAP. Configuring the correct information in the RADB is essential in setting the required routing policies, as explained in Appendix A, "RIPE-181." As a customer of a provider, you may never have to configure such language. What is important, though, is not the language itself but rather understanding the reasoning behind the policies being set. As you will see in this book, policies are the basis of routing behaviors and architectures.

On the other hand, the concept of a route server and peering with centralized routers is not restricted to providers and NAPs, and could be implemented in any architecture that needs it. As part of the implementation section of this book, the route server concept will come up as a means of creating a one-to-many relationship between peers.

Table of Contents