Dynamic Connectivity Management with an Intelligent Route Service

Dynamic Connectivity Management with an Intelligent Route Service Control Point Kobus van der Merwe AT&T Labs - Research A. Cepleanu, K. D’Souza, B. Freeman, A. Greenberg, D. Knight, R. Mc. Millan, D. Moloney, J. Mulligan, H. Nguyen, M. Nguyen, A. Ramarajan, S. Saad, M. Satterlee, T. Spencer, D. Toll and S. Zelingher

Motivation • New wanted and unwanted traffic – – • • New pressures on network operators Need improved network management practices to dynamically control if/how traffic flows in a network: – 2 Vo. IP, MMOG DDo. S attacks Dynamic Connectivity Management INM Sept 2006

BGP for connectivity management? • BGP is inherently involved in connectivity • Ideal vehicle to control connectivity – Used to realize a variety of business and/or network management tasks • • But, – BGP is inherently complex • – – Assembly language like configuration distributed over 100 s or 1000 s of routers – Changing dynamically, challenging (if possible) Lack of direct control • Influence decision process indirectly – Set attributes locally to influence decision process on a remote router Network unaware • 3 Typically over slower timescales Decision making not influenced by dynamic changes in network INM Sept 2006

IRSCP for Dynamic Connectivity Management • Intelligent Route Service Control Point (Formerly: Route Control Platform) • Logically centralized BGP speaking network entity: – Control plane only function, separate from routers – Connectivity control at protocol timescales – Raise level of abstraction to simplify connectivity management tasks – Allows connectivity management to be influenced by external network intelligence • Sampling of connectivity management applications – Illustrate approach + research direction 4 INM Sept 2006

IRSCP Operator Input�� Network Intelligence�� IRSCP R R RR RR R R • Logically centralized, speaks i. BGP (phase-1 RCP) – Routers still make own decisions + information hiding Initially deploy in parallel with route-reflector hierarchy • Direct operator and/or (controlled) customer input • • 5 Network intelligence input – Routing decisions influenced by external information INM Sept 2006 IBGP Control Monitoring

Selective DDo. S blackholing Wanted Attack PE PE PE 3 PE 4 PE IBGP Physical link DDo. S Detection PE 2 CE • PE 5 IRSCP Pre-configure blackhole static route to /dev/null on all PEs • When detect DDo. S attack, advertise very specific route to attack target with next-hop pointing to BH static route – Only to PEs where there is attack traffic – DDo. S attacks are not that distributed (LSAD DDo. S analysis paper) Network intelligence: DDo. S detection system • Still collateral damage, good traffic on that PE also dropped • • • BGP speaking IRSCP too coarse grained – Rudimentary form of type of control possible with non-BGP speaking IRSCP (LSAD PRIMED paper) 6 INM Sept 2006

Planned Maintenance Dryout IBGP Physical link CE PE 2 PE 1 • • • PEi Other ISP PEiii PE 3 PE 4 PE 5 PE 6 IRSCP PE 7 Goal: move traffic off network element that will undergo planned maintenance (PM) without any impact (I. e. , no session resets) With IRSCP, if alternate path exists – Multihomed customers/data centers (multihomed to IRSCP capable provider) – Multiple peering sessions Two directions, traffic going to PM element + traffic coming from PM element Towards PM element – Steer traffic away by making alternate path(s) more preferable (e. g. , by increasing the local preference attribute) From PM element: – Convince network elements on “other side” of PM element to steer traffic away – Data center case: pre-configure policy on CE, routes with special community value less preferred – Peering case: advertise routes with lower MED via desired peering points Network intelligence: planned maintenance event, alternate paths, load 7 INM Sept 2006

VPN Gateway selection Site E Site D GW IBGP Physical link CE 4 CE 5 PE 4 P 1 PE 2 CE 1 Site B • CE 2 PE 3 CE 3 Site C E. g. , east & west gateways, utilize both under normal conditions IRSCP: allow customer to dictate policy of which sites should be using which GW + backup strategies – IRSCP adjust preference of routes based on these policies • Adjusting local preference settings Allow customer to dynamically change policies (Web portal) – Can be done dynamically based on GW load + load on ingress Network Intelligence: customer policy, load information – • IRSCP Problem: MPLS VPNs, two routes to the same destination, PE breaks tie based on IGP distance – E. g. , two default routes for Internet gateways – Tie breaking reasonable in terms of delay, not so in terms of VPN customer needs • • P 2 P 3 PE 1 Site A GW 8 INM Sept 2006

Network aware load balancing AS 1 IBGP Physical link PE 2 CE Customer Network • PEiii PE 3 PE 4 PE 5 P 1 PE 6 P 2 P 3 IRSCP E. g. , customer/data center dual homed to provider Depending on offered load, egress links completely unbalanced Common problem: 72% multihomed customers, � one links carries all traffic (red curve) – – IRSCP: selects routes for ingress so as to balance traffic – Take offered load, egress load and IGP distance into account during route selection – Simulation: offered load balanced on per prefix/per ingres PE basis (green curve) • • PEii PE 7 AS 0 Problem: two routes to the same destination, PE breaks tie based on IGP distance – • PE 1 PEi 25% still unbalanced, 50% customers link ratio 0. 85 or better, for top 30% ratio is 0. 98 or better Network Intelligence: balancing policy, offered + egress load information, IGP 9 INM Sept 2006

Implementation Operator Application Logic External Information IRSCP Glue Logic IRSCP Core Network Elements • IRSCP Core – Sends/receives BGP messages • • • 10 Current implementation built on Quagga Application logic – Deals with “network intelligence” – Invokes high level interface on IRSCP Glue logic – Convert high level commands to detailed configuration INM Sept 2006

Raising level of abstraction Operator/application logic interface (what rather than how): • Selective blackholing --cmd addblackhole --routerlist PE 1, . . PEn, --prefix • PM dryout --cmd adddryout --dryout PE 1 --backup PE 2 • VPN gateway selection/Load balancing --cmd addgroup --ingress PEa --group N (--vpn VPNA) --cmd addpolicy --egress PEb -- group N 11 INM Sept 2006

VPN Gateway selection - Example Site E Site D GW IBGP Physical link CE 4 CE 5 PE 4 P 1 P 2 IRSCP P 3 PE 1 Site A GW PE 2 CE 1 Site B CE 2 PE 3 CE 3 Site C • Ensure PE 1 selects default route via PE 4 with highest priority and use route via PE 5 as backup 1. addgroup --ingress PE 1 --vpn VPNA --group 1 2. addpolicy --egress PE 4 --vpn VPNA --group 1 --prefix DEFAULT --pref 110 3. addpolicy --egress PE 5 --vpn VPNA --group 1 --prefix DEFAULT --pref 100 12 INM Sept 2006

Example glue logic addpolicy --egress PE 4 VPN gateway selection --vpn VPNA --group 1 addgroup --ingress PE 1 --prefix DEFAULT --pref 110 --vpn VPNA --group 1 route-map vpnin-a permit 1 route-map vpnout-b permit 1 VPN Selection match ip next-hop PE 4 match extcommunity VPNA on-match goto 3 match ip address prefix-list DEFAULT ! Per VPN PE Selection set community GRP 1_LP 110 additive route-map vpnout-b permit 3 on-match next match ip peeraddress PE 1 on-match goto 6 ! ! route-map vpnout-b permit 6 match community GRP 1_LP 100 Group 1 Policy Selection set local-preference 100 ! route-map vpnout-b permit 7 match community GRP 1_LP 110 set local-preference 110 ! 13 • INM Sept 2006 • Similarly for other addpolicy command Works well – – Kind of ugly! Room for improvement

Conclusion • Dynamic Connectivity Management Applications – • Various stages of trial deployment Work in progress – – High level abstraction desirable Exploring alternative implementations of IRSCP core and glue logic • – 14 IOS like CLI, right abstraction? More applications in the pipeline INM Sept 2006