270 likes | 459 Views
Wresting Control from BGP: Scalable Fine-grained Route Control. Patrick Verkaik. Dan Pei, Tom Scholl, Aman Shaikh, Alex C. Snoeren, Kobus van der Merwe. UCSD / AT&T Research Usenix —June 22, 2007. What is route control?. Route control. Traffic. ?. destination. ISP. measurement. ?.
E N D
Wresting Control from BGP: Scalable Fine-grained Route Control Patrick Verkaik Dan Pei, Tom Scholl, Aman Shaikh, Alex C. Snoeren, Kobus van der Merwe UCSD / AT&T Research Usenix —June 22, 2007
What is route control? Route control Traffic ? destination ISP measurement ? Traffic • ISPs need to control selection of alternate paths • … in response to dynamic network conditions • Historically routing provides simple connectivity • But demands are changing: gaming, DDoS defense • However, demands are changing:
IRSCP: enabling route control • IRSCP: Intelligent Route Service Control Point • Next step after RCP [Caesar et al.] • Enable route controlfor inter-domain traffic: • Automated, based on network conditions • Scalable to demands of large ISP • No changes to existing ISP infrastructure
Simple example: load balancing Egress router R1 Ingress router R5 Traffic on customer access links is balanced Customer ISP Overloaded link R4 R2 • Border Gateway Protocol (BGP) • BGP defaults to hot potato routing • Effectively: shortest path routing • Simple route control objective • Customers are asking for this • Yet BGP can’t do it! R3 Traffic
External BGP (eBGP) session Internal BGP (iBGP) session ISP router External router Why does BGP do that? Select route R1 dest d Customer 1 ISP 2 dest d • Hundreds of ISP routers making local decisions • Hot potato default policy: • Ensures consistency • ..but precludes control over routing R4 Select route R2 Customer 2 Select route R3 Select route ISP 1
IRSCP route control • Abstraction: “for this destination, direct traffic from this ISP router to that ISP router” • Automated, based on network conditions: route control application • Backwards compatible, consistent and scalable • Selective: allow default BGP decision where desired
Outline • IRSCP architecture • Routing consistency • Implementation • Evaluation
Traffic Route control abstraction • RC App assigns egress links to ISP routers • Speak BGP to routers • …using IRSCP R1 iBGP session ISP 1 ? Route Assign Customer 1 ISP 2 ? RC App IRSCP Egress links R3 Assign-ments R2 RC App Customer 2 R4
Route failover • What if a route for egress link fails? • RC application at relatively slow timescale • IRSCP must fail over instantly • So application sends a list of egress links for each ISP router • We call this a ranking
1 2 R1 R3 R2 R4 1 2 Rankings Select route for R1 and R3 Select route for R2 and R4 Rankings R1 ISP 1 Customer 1 ISP 2 IRSCP • Rankings map traffic from ingress to egress arbitrarily • And allow route fail-over at routing time-scale R3 R2 Rankings RC App Customer 2 R4 Traffic
What about scalability? • IRSCP talks to many thousands of routers • Responsible for route decision for each ISP router: • Computation • Single point of failure • Maintaining BGP session for each router : • State per session • Each eBGP session may add a route Distributed IRSCP 2-3 GB sufficient
IRSCP IRSCP IRSCP Distributed IRSCP • Multiple IRSCP servers: • To distribute BGP sessions • For geographic diversity • Routers may peer with several IRSCP servers • IRSCP servers are replicas: exchange all routes R1 IRSCP session ISP 1 Customer 1 ISP 2 R4 R3 R2 Customer 2
Outline • IRSCP architecture • Routing consistency • Implementation • Evaluation
Consistency Forwarding anomalies: Traffic R2 R1 R2 Deflection R1 R3 Looping R3 Rankings must be “consistent”
1 2 3 1 2 3 Example of inconsistent rankings RC application checks consistency constraints on rankings R2 R1 R3 R4 Traffic Rankings R1 R2 R3 R4 No anomalies Deflection
Outline • IRSCP architecture • Routing consistency • Implementation • Evaluation
IRSCP server IRSCP server Expl. ranked decision process Hot potato/BGP decision process Prototype implementation Import policy IRSCP server R1 Routes Routing information base I1 I2 RC App Rankings R2 Export policy
Outline • IRSCP architecture • Routing consistency • Implementation • Evaluation • Can IRSCP handle routing load in a real ISP? • Both explicitly ranked and hot potato decision process
Methodology • Emulation of realistic large ISP topology and routing load • Connect IRSCP implementation to emulation of ISP • Measure if our implementation handles the emulated load
IRSCP Customer 1 ISP 2 Deployment Scenario 40 POPs POP 240 external routers per POP IRSCP session BGP session 1 IRSCP server per POP 15 ISP routers per POP Throughput of IRSCP server depends on how many of each kind of session it has
IRSCP Finding maximum throughput Mix of BGP and IRSCP sessions based on ISP scenario IRSCP implementation: • 3.6-GHz Xeon • 4 GB memory Route update generator Route update receiver Input update rate Output update rate Multiplier Search for maximum sustainable input rate: • Gradually increase input rate, sustaining for twenty minutes • Compute expected output rate given input rate • Once measured output rate falls behind, we’ve reached maximum throughput
Maximum throughput 3600 Input rate Hot potato 2400 Explicitly ranked Output rate updates/s 600 220 41000 27000 Average in real ISP 95% in real ISP updates/s • Flexibility of rankings has a cost • But IRSCP handles Tier-1 ISP routing load, and more
Conclusion • IRSCP route control platform: • Feedback of network conditions into route selection • Scalable, robust against failures, backward compatible • Powerful, yet safe ranking abstraction • Enables new class of “route control application”: • Security • Traffic engineering • Customer-oriented services Trials of IRSCP for several applications taking place in AT&T!
Dan Alex Tom Kobus Patrick Aman Questions?
BGP sessions • As we saw, IRSCP speaks iBGP to ISP routers • For full control, IRSCP must also speak eBGP to external routers Select route eBGP session Select route for I E2 I IRSCP E1 iBGP session Multihop eBGP session
1 2 3 1 2 3 Example consistency constraint • Two simple consistency constraints • Checked by RC application before sending to IRSCP • Example: If e1outrankse2at R1 then must also do so at router(e1)=R3 e1 R2 R1 R1 R2 e2 e2 e1 R3 R4 e2 R3 R4 e1
Throughput Achieved output rate Achieved input rate Estimated 95 perc. required input rate Out of 255 routers per POP