Irscp.Phase2.Pdf

Wresting Control from BGP: Scalable Fine-grained Route Control ¡ ¡ ¡ Patrick Verkaik , Dan Pei , Tom Scholl , Aman Shaikh , ¡ Alex C. Snoeren , and Jacobus E. van der Merwe ¡ University of California, San Diego AT&T Labs Abstract Internet paths can often provide improved performance characteristics [1, 2, 20], suggesting the potential bene- Today's Internet users and applications are placing in- fit of making routing aware of network conditions [11]. creased demands on Internet service providers to deliver Additionally, today's operators are often required to re- fine-grained, flexible route control. To assist network op- strict the any-to-any connectivity model of the Internet erators in addressing this challenge we present an Intelli- to deal with unwanted traffic in the form of DDoS at- gent Route Service Control Point (IRSCP), a route con- tacks. Responses can take the form of black-holing traf- trol architecture that allows a network operator to flexibly fic, redirecting it to “scrubbing complexes”, or even more control routing between the traffic ingresses and egresses sophisticated differentiation of unwanted traffic based on of an ISP's network without modifying existing routers. network intelligence [24]. Finally, in some cases the de- In essence, IRSCP subsumes the control plane of an ISP's fault BGP decision process is simply at odds with provider network by replacing the distributed BGP decision pro- and/or customer goals. For example, using IGP cost as cess of each router in the network with a more flexi- a tie breaker in the decision process can lead to unbal- ble, logically centralized route computation. IRSCP ex- anced egress links for customers that are multi-homed to tends the traditional BGP decision process to allow route- a provider [23]. control applications to provide a per-destination, per- All these demands have in common the need for route ingress ranking of traffic egresses. We describe a straight- control that is (i) fine-grained, (ii) informed by exter- forward set of correctness requirements that prevents rout- nal information, and (iii) applied at time-scales much ing anomalies, and demonstrate through emulation that shorter than normal routing configuration changes. Unfor- our implementation is both scalable and fault-tolerant. To tunately, BGP does not provide adequate means for per- illustrate the potential of application-controlled route se- forming fine-grained route control. The tuning parameters lection, we use our IRSCP prototype to implement a sim- BGP does provide are both arcane and indirect. Opera- ple form of dynamic customer-traffic load balancing. tors are forced to tweak BGP attributes in cumbersome, vendor-specific router configuration languages at a low level of abstraction, frequently leading to ineffective or, 1 Introduction worse, incorrect route selections. Given the best-effort communication model of the Inter- We address these requirements by presenting a logi- net, routing in the Internet has historically been purely cally centralized—but physically distributed—Intelligent concerned with connectivity; that is, concerned with find- Route Service Control Point (IRSCP), which subsumes ing a loop free shortest path between Internet endpoints. the BGP decision process in a platform separate from the Deviations from this default behavior normally involved routers in a network. The concept of a logically central- policy changes at fairly slow time-scales to effect busi- ized Route Control Platform (RCP) that is separate from ness and network management objectives [6]. Further, and backwards compatible with existing routers was in- within a particular network (or autonomous system), rout- troduced previously [12]. The original RCP work envi- ing was realized by a fixed, fairly simple decision pro- sioned different phases of evolution that would eventu- cess, designed to ensure consistent decision making be- ally allow the replacement of BGP as the inter-domain tween the routers in the network. As networked appli- routing protocol. We initially presented a realization of cations and traffic engineering techniques have evolved, the simplest of these phases [7]. Specifically, we demon- however, they have placed increasingly sophisticated de- strated the feasibility of a centralized iBGP-speaking RCP mands on the routing infrastructure. For example, ap- that performed per-router route selection and thereby im- plications such as VoIP and online gaming can be very plemented a “correct” route-reflector replacement. Be- sensitive to the characteristics of the actual chosen data cause of the modest scaling requirements in that scenario, path [8, 9, 18]. Numerous studies have shown non-default each RCP instance dealt with the complete network and 1 the system simply relied on replicated RCP instances to strained to the standard BGP decision process. We exploit deal with redundancy. By integrating external informa- this possibility to ease the realization of dynamic connec- tion into the RCP decision process, however, we can en- tivity management applications. Specifically, we allow able a number of sophisticated connectivity management route control applications to impact the route selection applications [23]. In particular, we can utilize “network process by directly introducing a ranking of egress routes intelligence” to influence the route selection process. To on a per-ingress PE and per-destination basis through a reflect this thinking we changed the name of our archi- well-defined interface. tecture to the Intelligent Route Service Control Platform We demonstrate the effectiveness of IRSCP's route (IRSCP). control interface by evaluating an example application The work presented in this paper builds on this ear- that uses the IRSCP's interface to load-balance customer lier work and has three important new contributions in the traffic [23]. The key challenge to extending the BGP deci- evolutionary path towards a new routing infrastructure: sion process, however, is to ensure that the resulting protocol retains BGP's robustness, scalability, and consistency Phase-two IRSCP: Following our previous taxon- properties. We prove that a simple set of constraints on the omy [12], the architecture presented in this paper rep- application-provided route ranking ensure that IRSCP in- resents a phase-two IRSCP in that it enables the IRSCP stalls only safe routing configurations, even in the face of to communicate directly with routers in neighboring net- router failures or dramatic changes in IGP topology. We works via eBGP in addition to speaking iBGP with the further show through experimentation that our prototype routers in the IRSCP network. This has a number of de- implementation is capable of managing the routing load sirable properties: First, the IRSCP now has complete of a large tier-I ISP. visibility of all routes available to the network, as opposed to the iBGP-speaking (phase-one) case, where the routers only pass routes they have themselves selected to the IRSCP. Complete visibility is useful for a variety of 2 Background reasons. For one, as we demonstrate in this paper, complete visibility is an important ingredient for preventing We begin by providing a brief background about how route oscillations within the network [3, 15, 17]. Sec- routing and forwarding happens in typical ISP networks. ond, given that the routers in the IRSCP network no longer We specifically consider the role played by BGP, IGP and maintain eBGP sessions with routers in neighboring net- MPLS and describe BGP's default route selection process. works, IRSCP is now (effectively) the sole controller of Figure 1-a shows a simplified view of the physical BGP route selection. This means that all of the network's infrastructure of an MPLS-enabled ISP backbone. The routing policy can be handled in the IRSCP, as opposed routers at the periphery of the ISP network connect to to placing some policy configuration on the routers them- customers and other ISPs (called peers). These routers selves. are termed as Provider Edge (PE) routers, and the routers that interconnect the PE routers are called Provider Core Physical distribution: An eBGP-speaking (phase-two) (P) routers. The customer routers connecting to PEs are IRSCP has two important consequences. First, because called Customer Edge (CE) routers. BGP allows an ISP to the IRSCP forms BGP peering sessions with all remote learn about destinations reachable through its customers routers connected to the IRSCP network, the scalability and through its peers. Typically every PE runs BGP ses- requirements are significantly higher than that of a phase- sions with its attached CEs, and also with other PEs in one IRSCP: each provider edge (PE) router at the edge the ISP network; the former are known as eBGP sessions of a provider network typically peers with tens to hun- while the latter are termed as iBGP sessions as shown in dreds of eBGP speaking routers (i.e., customer edge (CE) Figure 1-b. When a PE router learns a route over its eBGP routers or PE routers in neighboring networks). Second, session, it propagates the route to other PEs over the iBGP because routers in the IRSCP network now completely sessions which allows every PE to learn how to reach ev- rely on the IRSCP for routes, the redundancy requirement ery customer network. When a data packet arrives at a of the IRSCP infrastructure is much more critical than PE for a given customer, this ingress PE uses the BGP with a phase-one IRSCP. For these reasons, the architec- routing table to determine the PE that is connected to the ture presented in this paper is physically distributed while destination customer, and forwards the packet to this PE. maintaining the ability to reason about the architecture in This is depicted in Figure 1-c. Since the packet leaves ISP a logically centralized manner and ensuring consistent de- network at the PE directly connected to the customer, we cision making across different replicas. call it an egress PE, and its link to the CE an egress link.

Load more