distributed route aggregation
play

Distributed Route Aggregation on the GlObal Network (DRAGON) Joo - PowerPoint PPT Presentation

Distributed Route Aggregation on the GlObal Network (DRAGON) Joo Lus Sobrinho 1 Laurent Vanbever 2 , Franck Le 3 , Jennifer Rexford 4 ACM CoNEXT 2014, Sydney 1 Instituto de Telecomunicaes, 1 IST Universidade de Lisboa 2 ETH Zurich, 3 IBM


  1. Distributed Route Aggregation on the GlObal Network (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 2 ETH Zurich, 3 IBM T. J. Watson Research, 4 Princeton University

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

  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) 3

  4. Not a scalable routing system 1.0.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.1.0.0/16 1.0.0.0/16 origin AS 4 1.1.0.0/16 1.0.0.0/16 1.0.0.0/16 AS 6 1.1.0.0/16 1.1.0.0/16 origin AS 5 Most of the originated prefixes are routed globally (by BGP) 4

  5. Not a scalable routing system 1.0.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 1.0.1.0/24 AS 1 1.1.0.0/16 1.0.1.0/24 1.0.1.0/24 1.0.0.0/16 origin AS 4 1.1.0.0/16 1.0.1.0/24 1.0.0.0/16 1.0.0.0/16 AS 6 1.1.0.0/16 1.1.0.0/16 origin AS 5 1.0.1.0/24 origin 1.0.1.0/24 Most of the originated prefixes are routed globally (by BGP) 5

  6. No scalability: poor performance • Forwarding tables (FIBs) growth & address look- up time increase • Routing tables (RIBs) growth • BGP session set-up time increase • Churn & convergence time increase 6

  7. Further scalability concerns • IPv6 prefixes can be formed in potentially larger numbers than IPv4 prefixes • Secure BGP adds computational overhead to routing processes 7

  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 8

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

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

  11. Scalability: global view (routing) Specificity Prefix q is more specific than prefix p if the bits of p are AS 1 1.0.0.0/16 the first bits of q 1.0.0.0/16 origin AS 2 1.0.1.0/24 1.0.0.0/16 AS 3 1.0.1.0/24 origin Propagation of more specific prefixes only in a small vicinity of their origin ASs 11

  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 AS 2 1.0.1.0/24 1.0.0.0/16 AS 3 1.0.1.0/24 origin Most ASs forward data-packets on the (aggregated) less specific prefixes 12

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

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

  15. Hope for scalability? Clustering Routing Information Registry (RIR) AS 3 1.0.0.0/24 AS 4 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 15

  16. Challenge: global vs. local 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: • each AS decides where to connect • each AS decides where to acquire address space • each AS sets its own routing policies 16

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

  18. Filtering strategy • Locally filter the more specific prefixes when possible – no black holes – respect routing policies • Use built-in incentives to filter locally – save on forwarding state – forward along best route • Exchange routing information with standard BGP 18

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

  20. Prefixes #1 #2 p : origin #3 #4 #5 #6 q : origin #6 originates q (1.0.0.0/24); #4 originates p (1.0.0.0/16) q more specific than p 20

  21. Routes Route #1 #2 Association between a prefix and an attribute, from a totally ordered set of attributes p : origin #3 #4 q -route #5 #6 q : origin (route pertaining to q ) 21

  22. Gao-Rexford routing policies #1 #2 route attributes: “ customer ” “ peer ” p : origin #3 #4 “ provider ” q -route #5 #6 q : origin preferences: customer then peer then provider exportations: all routes from customers; all routes to customers 22

  23. Gao-Rexford routing policies #1 #2 route attributes: “ customer ” q : cust. “ peer ” p : origin #3 #4 “ provider ” q : cust. q -route #5 #6 q : origin preferences: customer then peer then provider exportations: all routes from customers; all routes to customers 23

  24. Gao-Rexford routing policies #1 #2 route attributes: q : cust. “ customer ” q : cust. “ peer ” p : origin #3 #4 “ provider ” q : cust. q -route #5 #6 q : prov. q : origin preferences: customer then peer then provider exportations: all routes from customers; all routes to customers 24

  25. Gao-Rexford routing policies #1 #2 route attributes: q : cust. q : peer “ customer ” q : cust. “ peer ” p : origin #3 #4 “ provider ” q : cust. q -route #5 #6 q : prov. q : origin preferences: customer then peer then provider exportations: all routes from customers; all routes to customers 25

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

  27. Final state for prefixes q and p p : cust. p : peer #1 #2 route attributes: q : cust. q : peer “ customer ” p : prov. q : cust. “ peer ” p : origin #3 #4 “ provider ” q : cust. p : prov. p : prov. #5 #6 q : prov. q : origin forwarding: longest prefix match rule 27

  28. Filtering code (FC) p : cust. p : peer Filtering Code (FC) #1 #2 q : cust. q : peer p : prov. Other than origin of p , q : cust. in the presence of p, p : origin filter q if only if: #3 #4 q : cust. attribute of p -route same or preferred to p : prov. p : prov. #5 #6 attribute of q -route q : prov. q : origin ASs that filter q upon execution of FC 28

  29. AS 2 applies FC p : cust. p : peer #1 #2 q : cust. filtered prefix p : prov. q : cust. p : origin #3 #4 q : cust. AS forgoes q p : prov. p : prov. #5 #6 q : prov. q : origin • AS 2 saves on forwarding state • AS 1 is oblivious of q ; it saves on AS 2 filters q forwarding and routing state 29

  30. All ASs apply FC p : cust. p : peer #1 #2 q : cust. filtered prefix p : prov. q : cust. p : origin #3 #4 q : cust. AS forgoes q p : prov. p : prov. #5 #6 q : prov. q : origin forwarding to q using less specific p AS 1, AS 2, and AS 3 forgo q 30

  31. Global property: correctness p : cust. p : peer #1 #2 q : cust. p : prov. q : cust. p : origin #3 #4 q : cust. forwarding data-packets with destination in q p : prov. p : prov. #5 #6 q : prov. q : origin Correctness : no routing anomalies (no black holes) 31

  32. Global property: route consistency p : cust. p : peer #1 #2 q : cust. p : prov. q : cust. p : origin #3 #4 q : cust. forwarding data-packets with destination in q p : prov. p : prov. #5 #6 q : prov. q : origin Route consistency : attribute of route used to forward data- packets is preserved Optimal route consistency : set of ASs that forgo q is maximal 32

  33. Partial deployment p : peer #1 q : cust. p : cust. #2 forwarding data-packets q : cust. with destination in q p : peer #3 p : cust. q : peer #4 q : cust. p : origin #5 q : cust. ASs that filter q upon execution of FC p : prov. #6 q : origin 33

  34. Partial deployment: incentives p : peer #1 q : cust. p : cust. #2 forwarding data-packets q : peer with destination in q p : peer #3 p : cust. q : prov. #4 q : cust. p : origin #5 q : cust. p : prov. #6 q : origin AS 2 (and AS 3) has a double incentive to apply the FC: • saves on forwarding state • improves attribute of route used to forward data-packets 34

  35. Partial deployment: incentives p : peer #1 q : cust. p : cust. #2 forwarding data-packets q : peer with destination in q p : peer #3 p : cust. q : prov. #4 q : cust. p : origin #5 q : cust. p : prov. #6 q : origin AS 2 applies FC AS 2 reverts to forwarding data-packets with address in q to AS 4 35

  36. Partial deployment: route consistency p : peer #1 q : cust. p : cust. #2 forwarding data-packets q : cust. with destination in q p : peer #3 p : cust. q : peer #4 q : cust. p : origin #5 q : cust. p : prov. #6 q : origin 36

  37. Partial deployment: route consistency p : peer #1 q : cust. p : cust. #2 forwarding data-packets q : cust. with destination in q p : peer #3 p : cust. q : peer #4 q : cust. p : origin #5 q : cust. p : prov. #6 q : origin First to apply FC are ASs that elect a peer or provider q -route 37

Recommend


More recommend