1 / 53

D istributed R oute A ggregation on the G l O bal N etwork (DRAGON)

D istributed R oute A ggregation on the G l O bal N etwork (DRAGON). João Luís Sobrinho 1. Laurent Vanbever 2 , Franck Le 3 , Jennifer Rexford 4. ACM CoNEXT 2014, Sydney. 1 Instituto de Telecomunicações, 1 IST Universidade de Lisboa

burnst
Download Presentation

D istributed R oute A ggregation on the G l O bal N etwork (DRAGON)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DistributedRouteAggregationontheGlObalNetwork(DRAGON) João Luís Sobrinho1 Laurent Vanbever2, Franck Le3, Jennifer Rexford4 ACM CoNEXT 2014, Sydney 1Instituto de Telecomunicações, 1IST Universidade de Lisboa 2ETH Zurich, 3IBM T. J. Watson Research, 4Princeton University

  2. Last year in the news (August 2014) Some routers could not process the +512 K IPv4 prefixes they were learning about

  3. Not a scalable routing system 1.0.0.0/16 1.0.0.0/16 AS 2 1.0.0.0/16 AS 3 AS 1 1.0.0.0/16 origin AS 4 1.0.0.0/16 1.0.0.0/16 AS 6 AS 5 Most of the originated prefixes are routed globally (by BGP)

  4. Not a scalable routing system 1.0.0.0/16 1.1.0.0/16 1.0.0.0/16 1.1.0.0/16 AS 2 1.0.0.0/16 1.1.0.0/16 AS 3 AS 1 1.0.0.0/16 origin 1.1.0.0/16 AS 4 1.0.0.0/16 1.1.0.0/16 1.0.0.0/16 1.1.0.0/16 origin AS 6 AS 5 Most of the originated prefixes are routed globally (by BGP)

  5. Not a scalable routing system 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 AS 2 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 AS 3 AS 1 1.0.0.0/16 origin 1.1.0.0/16 1.0.1.0/24 AS 4 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 origin 1.0.0.0/16 1.1.0.0/16 origin 1.0.1.0/24 AS 6 AS 5 Most of the originated prefixes are routed globally (by BGP)

  6. No scalability: poor performance • Forwardingtables (FIBs) growth & address look-up time increase • Routingtables (RIBs) growth • BGP sessionset-up time increase • Churn& convergence time increase

  7. Further scalability concerns • IPv6 prefixes can beformed in potentiallylargernumbersthan IPv4 prefixes • Secure BGP addscomputationaloverhead to routing processes

  8. DRAGON Distributed solution to scale the Internet routing system Basic DRAGON: 49% savings on routing state Full DRAGON: 79% savings on routing state No changes to the BGP protocol No changes to the forwarding plane Readily implemented with updated router software

  9. Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions

  10. Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions

  11. Scalability: global view (routing) Specificity Prefixqis more specificthanprefixpifthe bits ofp are thefirst bits ofq AS 1 1.0.0.0/16 1.0.0.0/16 origin 1.0.1.0/24 AS 2 1.0.0.0/16 1.0.1.0/24 origin AS 3 Propagation of more specific prefixes only in a small vicinity of their origin ASs

  12. Scalability: global view (forwarding) dest. addr. data-packet AS 1 1.0.0.0/16 1.0.1.1 1.0.0.0/16 origin 1.0.1.0/24 AS 2 1.0.0.0/16 1.0.1.0/24 origin AS 3 Most ASs forward data-packets on the (aggregated) less specific prefixes

  13. Scalability: global view (forwarding) dest. addr. data-packet AS 1 1.0.0.0/16 1.0.0.0/16 origin 1.0.1.0/24 AS 2 1.0.1.1 1.0.0.0/16 1.0.1.0/24 origin AS 3

  14. Hope for scalability? Hierarchies 1.0.0.0/16 provider AS 1 AS hierarchy Prefixhierarchy 1.0.1.0/24 customer AS 2 AS-hierarchy aligned with prefix hierarchy

  15. Hope for scalability? Clustering RoutingInformationRegistry (RIR) AS 3 AS 4 1.0.0.0/24 1.0.1.0/24 1.0.2.0/23 AS 5 1.0.0.0/24 AS 1 1.0.1.0/24 AS 6 AS 2 1.0.2.0/23 AS 3 1.0.0.0/24 + 1.0.1.0/24 + 1.0.2.0/23 = 1.0.0.0/22 Geography roughly clusters together ASs with aggregatable address space

  16. Challenge: global vs. local • each AS decides where to connect • each AS decides where to acquireaddressspace • each AS sets itsownrouting policies How to realize the global view through automated local routing decisions? especially, given that the Internet routing system is as decentralized as it can be:

  17. Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions

  18. Filteringstrategy • Locallyfilterthe more specific prefixes whenpossible • no blackholes • respectrouting policies • Use built-in incentives to filterlocally • saveonforwardingstate • forwardalongbestroute(dictatedbyrouting policies) • Exchange routinginformationwith standard BGP

  19. Providers, customers, andpeers peer peer #1 #2 provider #3 #4 customer #5 #6

  20. Prefixes #1 #2 p: origin #3 #4 #5 #6 q: origin #6 originatesq (1.0.0.0/24); #4 originatesp (1.0.0.0/16) q more specificthanp

  21. Routes Route Associationbetween a prefixandanattribute, from a totallyordered set ofattributes #1 #2 #3 #4 p: origin q: origin q-route (routepertaining to q) #5 #6

  22. Gao-Rexfordrouting policies #1 #2 routeattributes: “customer” “peer” #3 #4 “provider” p: origin q: origin q-route #5 #6 preferences: customerthenpeerthenprovider exportations: allroutesfromcustomers; allroutes to customers

  23. Gao-Rexfordrouting policies #1 #2 routeattributes: “customer” “peer” #3 #4 “provider” p: origin q: cust. q: cust. q: origin q-route #5 #6 preferences: customerthenpeerthenprovider exportations: allroutesfromcustomers; allroutes to customers

  24. Gao-Rexfordrouting policies #1 #2 routeattributes: “customer” “peer” #3 #4 “provider” q: cust. p: origin q: cust. q: cust. q: prov. q: origin q-route #5 #6 preferences: customerthenpeerthenprovider exportations: allroutesfromcustomers; allroutes to customers

  25. Gao-Rexfordrouting policies q: peer #1 #2 routeattributes: “customer” “peer” #3 #4 “provider” p: origin q: cust. q: cust. q: cust. q: prov. q: origin q-route #5 #6 preferences: customerthenpeerthenprovider exportations: allroutesfromcustomers; allroutes to customers

  26. Final state for prefixq q: peer #1 #2 routeattributes: “customer” “peer” #3 #4 “provider” q: cust. q: cust. p: origin q: cust. q: prov. q: origin #5 #6

  27. Final state for prefixes q andp p: peer q: peer #1 #2 routeattributes: “customer” “peer” #3 #4 “provider” p: origin q: cust. p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: prov. q: origin #5 #6 forwarding: longestprefix match rule

  28. Filteringcode (FC) p: peer q: peer FilteringCode (FC) Otherthanoriginofp, in thepresenceofp, filterqifonlyif: attributeofp-route sameorpreferred to attributeofq-route #1 #2 #3 #4 p: origin q: cust. p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: prov. q: origin #5 #6 ASsthatfilterquponexecutionof FC

  29. AS 2 applies FC p: peer #1 #2 filteredprefix #3 #4 p: origin q: cust. p: cust. q: cust. p: prov. q: cust. AS forgoes q p: prov. q: prov. p: prov. q: origin #5 #6 • AS 2 savesonforwardingstate • AS 1 isobliviousofq; itsavesonforwardingandroutingstate AS 2 filtersq

  30. AllASsapply FC p: peer #1 #2 filteredprefix #3 #4 p: origin q: cust. p: cust. q: cust. p: prov. q: cust. AS forgoes q p: prov. q: prov. p: prov. q: origin #5 #6 forwarding to qusinglessspecificp AS 1, AS 2, and AS 3 forgoq

  31. Global property: correctness p: peer #1 #2 #3 #4 p: origin q: cust. p: prov. q: cust. p: cust. q: cust. forwarding data-packetswithdestination in q p: prov. q: prov. p: prov. q: origin #5 #6 Correctness: no routinganomalies (no blackholes)

  32. Global property: routeconsistency p: peer #1 #2 #3 #4 p: origin q: cust. p: prov. q: cust. p: cust. q: cust. forwarding data-packetswithdestination in q p: prov. q: prov. p: prov. q: origin #5 #6 Routeconsistency: attributeofrouteused to forward data-packetsispreserved Optimalrouteconsistency: set ofASsthatforgoqis maximal

  33. Partialdeployment #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: peer #5 ASsthatfilterquponexecutionof FC #6

  34. Partialdeployment: incentives #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: peer p: peer q: prov. #5 #6 AS 2 (and AS 3) has a double incentive to applythe FC: • savesonforwardingstate • improves attributeofrouteused to forward data-packets

  35. Partialdeployment: incentives #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: peer p: peer q: prov. #5 #6 AS 2 applies FC AS 2 reverts to forwarding data-packetswithaddress in q to AS 4

  36. Partialdeployment: routeconsistency #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: peer #5 #6

  37. Partialdeployment: routeconsistency #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: peer #5 #6 First to apply FC are ASsthatelect a peerorproviderq-route

  38. Partialdeployment: routeconsistency #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: prov. #5 #6 Next to apply FC are ASs for whichprovidershavealreadyapplied FC

  39. Partialdeployment: routeconsistency #1 #2 forwarding data-packetswithdestination in q #3 #4 p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: peer p: peer q: prov. #5 #6 Next to apply FC are ASs for whichprovidershavealreadyapplied FC

  40. Filteringstrategy: general case • Treesof prefixes learnedfrom BGP • FC for a prefix in relation to theparentprefix • Correctness • for therouting policies for which BGP iscorrect • Routeconsistency (optimalandthroughpartialdeployment) • for isotonerouting policies (includesGao-Rexford) Optimal route consistency is not synonymous with efficiency (thinkshortestpaths)

  41. Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions

  42. Aggregationstrategy • Locallyoriginateaggregation prefixes whenbeneficial • newaddressspaceisnotcreated • allowfilteringofprovider-independent prefixes • self-organizationwhen more thanone AS originatesthesameaggregationprefix • Again, exchangeroutinginformationwith standard BGP

  43. Aggregationprefix #1 Aggregationprefix no routableaddressspaceiscreated atleasttwocovered prefixes customerrouteiselected for eachofthecovered prefixes #2 #3 #4 #5 #6 p0: origin p10: prov. p11: prov. p0: prov. p10: origin p11: prov. p0: prov. p10: prov. p11: origin p0: cust. p10: cust. p11: cust. p0 + p10 + p11= p; p isanaggregationprefixat AS 3

  44. AS 3 originatesp AS 1 isobliviousofp0, p10, andp11 #1 #2 AS 2 filtersp0, p10, andp11 p: origin p0: cust. p10: cust. p11: cust. #3 #4 #5 #6 p:prov. p0: origin p10: prov. p11: prov. p:prov. p0: prov. p10: origin p11: prov. p:prov. p0: prov. p10: prov. p11: origin p: cust. p0: cust. p10: cust. p11: cust. p: cust. AS 4filtersp10 andp11 AS 5 filtersp0 andp11 AS 6 filtersp0 andp10

  45. Aggregationstrategy: general case • Treesof prefixes learnedfrom BGP • aggregation prefixes cover parentless prefixes • Self-organization • for therouting policies for which BGP iscorrect • Optimalorigins • for isotonerouting policies (includesGao-Rexford)

  46. Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions

  47. Data-sets • Annotatedtopology (CAIDA, Feb. 2015) • ~50K ASs; ~42K stubASs • ~94K provider links; ~94K customer links; 180K peer links • IPv4-prefixes-to-ASs mapping (CAIDA, Feb. 2015) • ~530K prefixes • ~270K parentless prefixes • ~210K prefixes havesameorigin AS asparent

  48. FIB filteringefficiency: definition Normalized amount of reduction brought by DRAGON to the forwarding tables of an AS # (FIB entries BGP) – # (FIB entries DRAGON) FilterEff = # (FIB entries BGP)

  49. FIB filteringefficiency: results

  50. FIB filteringefficiency: results

More Related