Networked Systems Design and Implementation, May 2, 2005
The routers in an Autonomous System (AS) must distribute the information they learn about how to ... more The routers in an Autonomous System (AS) must distribute the information they learn about how to reach external destinations. Unfortunately, today's internal Border Gateway Protocol (iBGP) architectures have serious problems: a "full mesh" iBGP configuration does not scale to large networks and "route reflection" can introduce problems such as protocol oscillations and persistent loops. Instead, we argue that a Routing Control Platform (RCP) should collect information about external destinations and internal topology and select the BGP routes for each router in an AS. RCP is a logicallycentralized platform, separate from the IP forwarding plane, that performs route selection on behalf of routers and communicates selected routes to the routers using the unmodified iBGP protocol. RCP provides scalability without sacrificing correctness. In this paper, we present the design and implementation of an RCP prototype on commodity hardware. Using traces of BGP and internal routing data from a Tier-1 backbone, we demonstrate that RCP is fast and reliable enough to drive the BGP routing decisions for a large network. We show that RCP assigns routes correctly, even when the functionality is replicated and distributed, and that networks using RCP can expect comparable convergence delays to those using today's iBGP architectures.
Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, 2004
Over the past decade, the complexity of the Internet's routing infrastructure has increased drama... more Over the past decade, the complexity of the Internet's routing infrastructure has increased dramatically. This complexity and the problems it causes stem not just from various new demands made of the routing infrastructure, but also from fundamental limitations in the ability of today's distributed infrastructure to scalably cope with new requirements. The limitations in today's routing system arise in large part from the fully distributed path-selection computation that the IP routers in an autonomous system (AS) must perform. To overcome this weakness, interdomain routing should be separated from today's IP routers, which should simply forward packets (for the most part). Instead, a separate Routing Control Platform (RCP) should select routes on behalf of the IP routers in each AS and exchange reachability information with other domains. Our position is that an approach like RCP is a good way of coping with complexity while being responsive to new demands and can lead to a routing system that is substantially easier to manage than today. We present a design overview of RCP based on three architectural principles-path computation based on a consistent view of network state, controlled interactions between routing protocol layers, and expressive specification of routing policies-and discuss the architectural strengths and weaknesses of our proposal.
Despite the architectural separation between intradomain and interdomain routing in the Internet,... more Despite the architectural separation between intradomain and interdomain routing in the Internet, intradomain protocols do influence the path-selection process in the Border Gateway Protocol (BGP). When choosing between multiple equally-good BGP routes, a router selects the one with the closest egress point, based on the intradomain path cost. Under such hot-potato routing, an intradomain event can trigger BGP routing changes. To characterize the influence of hot-potato routing, we conduct controlled experiments with a commercial router. Then, we propose a technique for associating BGP routing changes with events visible in the intradomain protocol, and apply our algorithm to AT&T's backbone network. We show that (i) hot-potato routing can be a significant source of BGP updates, (ii) BGP updates can lag 60 seconds or more behind the intradomain event, (iii) the number of BGP path changes triggered by hot-potato routing has a nearly uniform distribution across destination prefixe...
Despite the architectural separation between intradomain and interdomain routing in the Internet,... more Despite the architectural separation between intradomain and interdomain routing in the Internet, intradomain protocols do influence the path-selection process in the Border Gateway Protocol (BGP). When choosing between multiple equally-good BGP routes, a router selects the one with the closest egress point, based on the intradomain path cost. Under such hot-potato routing, an intradomain event can trigger BGP routing changes. To characterize the influence of hot-potato routing, we propose a technique for associating BGP routing changes with events visible in the intradomain protocol, and apply our algorithm to a tier-1 ISP backbone network. We show that (i) BGP updates can lag 60 seconds or more behind the intradomain event, (ii) the number of BGP path changes triggered by hot-potato routing has a nearly uniform distribution across destination prefixes, and (iii) the fraction of BGP messages triggered by intradomain changes varies significantly across time and router locations. We show that hot-potato routing changes lead to longer delays in forwarding-plane convergence, shifts in the flow of traffic to neighboring domains, extra externally-visible BGP update messages, and inaccuracies in Internet performance measurements. 1 To obtain up-to-date information about the size of routing tables, please reference http://www.cidr-report.org.
Many recent router architectures decouple the routing engine from the forwarding engine, allowing... more Many recent router architectures decouple the routing engine from the forwarding engine, allowing packet forwarding to con- tinue even when the routing process is not active. This opens up the possibility of using the forwarding capability of a router even when its routing process is brought down for software upgrade or maintenance, thus avoiding the route aps that normally oc- cur when the routing process goes down. Unfortunately, current routing protocols, such as BGP, OSPF and IS-IS do not sup- port such operation. In an earlier paper (1) , we described an enhancement to OSPF, called the IBB (I'll Be Back) capability, that enables a router to continue forwarding packets while its routing process is inactive. When the OSPF process in an IBB-capable router is inactive, it cannot adapt its forwarding table to reect changes in network topology. This can lead to routing loops and/or black holes. In this paper we focus on the loop problem, and provide a detailed analysis of how and when loops are formed and propose solu- tions to prevent them. We develop two necessary conditions for the formation of routing loops in the general case when multi- ple routers are inactive. These conditions can easily be checked by the neighbors of the inactive routers. Simulations on several network topologies showed that checking the two conditions to- gether signaled a loop in most cases only when a loop actually existed.
Networked Systems Design and Implementation, May 2, 2005
The routers in an Autonomous System (AS) must distribute the information they learn about how to ... more The routers in an Autonomous System (AS) must distribute the information they learn about how to reach external destinations. Unfortunately, today's internal Border Gateway Protocol (iBGP) architectures have serious problems: a "full mesh" iBGP configuration does not scale to large networks and "route reflection" can introduce problems such as protocol oscillations and persistent loops. Instead, we argue that a Routing Control Platform (RCP) should collect information about external destinations and internal topology and select the BGP routes for each router in an AS. RCP is a logicallycentralized platform, separate from the IP forwarding plane, that performs route selection on behalf of routers and communicates selected routes to the routers using the unmodified iBGP protocol. RCP provides scalability without sacrificing correctness. In this paper, we present the design and implementation of an RCP prototype on commodity hardware. Using traces of BGP and internal routing data from a Tier-1 backbone, we demonstrate that RCP is fast and reliable enough to drive the BGP routing decisions for a large network. We show that RCP assigns routes correctly, even when the functionality is replicated and distributed, and that networks using RCP can expect comparable convergence delays to those using today's iBGP architectures.
Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, 2004
Over the past decade, the complexity of the Internet's routing infrastructure has increased drama... more Over the past decade, the complexity of the Internet's routing infrastructure has increased dramatically. This complexity and the problems it causes stem not just from various new demands made of the routing infrastructure, but also from fundamental limitations in the ability of today's distributed infrastructure to scalably cope with new requirements. The limitations in today's routing system arise in large part from the fully distributed path-selection computation that the IP routers in an autonomous system (AS) must perform. To overcome this weakness, interdomain routing should be separated from today's IP routers, which should simply forward packets (for the most part). Instead, a separate Routing Control Platform (RCP) should select routes on behalf of the IP routers in each AS and exchange reachability information with other domains. Our position is that an approach like RCP is a good way of coping with complexity while being responsive to new demands and can lead to a routing system that is substantially easier to manage than today. We present a design overview of RCP based on three architectural principles-path computation based on a consistent view of network state, controlled interactions between routing protocol layers, and expressive specification of routing policies-and discuss the architectural strengths and weaknesses of our proposal.
Despite the architectural separation between intradomain and interdomain routing in the Internet,... more Despite the architectural separation between intradomain and interdomain routing in the Internet, intradomain protocols do influence the path-selection process in the Border Gateway Protocol (BGP). When choosing between multiple equally-good BGP routes, a router selects the one with the closest egress point, based on the intradomain path cost. Under such hot-potato routing, an intradomain event can trigger BGP routing changes. To characterize the influence of hot-potato routing, we conduct controlled experiments with a commercial router. Then, we propose a technique for associating BGP routing changes with events visible in the intradomain protocol, and apply our algorithm to AT&T's backbone network. We show that (i) hot-potato routing can be a significant source of BGP updates, (ii) BGP updates can lag 60 seconds or more behind the intradomain event, (iii) the number of BGP path changes triggered by hot-potato routing has a nearly uniform distribution across destination prefixe...
Despite the architectural separation between intradomain and interdomain routing in the Internet,... more Despite the architectural separation between intradomain and interdomain routing in the Internet, intradomain protocols do influence the path-selection process in the Border Gateway Protocol (BGP). When choosing between multiple equally-good BGP routes, a router selects the one with the closest egress point, based on the intradomain path cost. Under such hot-potato routing, an intradomain event can trigger BGP routing changes. To characterize the influence of hot-potato routing, we propose a technique for associating BGP routing changes with events visible in the intradomain protocol, and apply our algorithm to a tier-1 ISP backbone network. We show that (i) BGP updates can lag 60 seconds or more behind the intradomain event, (ii) the number of BGP path changes triggered by hot-potato routing has a nearly uniform distribution across destination prefixes, and (iii) the fraction of BGP messages triggered by intradomain changes varies significantly across time and router locations. We show that hot-potato routing changes lead to longer delays in forwarding-plane convergence, shifts in the flow of traffic to neighboring domains, extra externally-visible BGP update messages, and inaccuracies in Internet performance measurements. 1 To obtain up-to-date information about the size of routing tables, please reference http://www.cidr-report.org.
Many recent router architectures decouple the routing engine from the forwarding engine, allowing... more Many recent router architectures decouple the routing engine from the forwarding engine, allowing packet forwarding to con- tinue even when the routing process is not active. This opens up the possibility of using the forwarding capability of a router even when its routing process is brought down for software upgrade or maintenance, thus avoiding the route aps that normally oc- cur when the routing process goes down. Unfortunately, current routing protocols, such as BGP, OSPF and IS-IS do not sup- port such operation. In an earlier paper (1) , we described an enhancement to OSPF, called the IBB (I'll Be Back) capability, that enables a router to continue forwarding packets while its routing process is inactive. When the OSPF process in an IBB-capable router is inactive, it cannot adapt its forwarding table to reect changes in network topology. This can lead to routing loops and/or black holes. In this paper we focus on the loop problem, and provide a detailed analysis of how and when loops are formed and propose solu- tions to prevent them. We develop two necessary conditions for the formation of routing loops in the general case when multi- ple routers are inactive. These conditions can easily be checked by the neighbors of the inactive routers. Simulations on several network topologies showed that checking the two conditions to- gether signaled a loop in most cases only when a loop actually existed.
Uploads
Papers by Aman Shaikh