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
Last year in the news (August 2014) Some routers could not process the +512 K IPv4 prefixes they were learning about 2
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
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
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
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
Further scalability concerns • IPv6 prefixes can be formed in potentially larger numbers than IPv4 prefixes • Secure BGP adds computational overhead to routing processes 7
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
Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions 9
Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions 10
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
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
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
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
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
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
Outline • Scalability: global view • DRAGON: filtering strategy • DRAGON: aggregation strategy • DRAGON: performance evaluation • Conclusions 17
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
Providers, customers, and peers peer peer #1 #2 provider #3 #4 customer #5 #6 19
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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