miro : m ulti-path i nterdomain ro uting
DESCRIPTION
Wen Xu July 30, 2009. MIRO : M ulti-path I nterdomain RO uting. Internet Routing : current status. AS 1. AS 7018. AS 701. AS 29. AS 88. AS = Autonomous System 31,311 ASes in 2009 Internet. The Internet. Interdomain Routing. Interdomain routing is important 31,311 ASes in April 2009 - PowerPoint PPT PresentationTRANSCRIPT
Slide 1
MIRO: Multi-path Interdomain ROuting
Wen XuJuly 30, 2009
Slide 2
AS 701
AS 29 AS 88
AS7018
AS 1
AS = Autonomous System31,311 ASes in 2009
Internet
Internet Routing : current status
The Internet
Slide 3 Interdomain Routing
Interdomain routing is important 31,311 ASes in April 2009 Most traffic traverses multiple ASes
Interdomain routing is challenging A federation of multiple independent
ASes Economic factors drive routing policies Not necessarily using shortest path People are not willing to reveal internals
Slide 4 Our Contribution: MIRO
Motivation Current protocol lacks flexibility and control
MIRO: a new Interdomain routing protocol Offers substantial flexibility Avoid state explosion in disseminating info Give ASes control over the traffic in their networks
Backward compatible and incrementally deployable
Slide 5 Outline of The Talk
Motivation and Related Work Design and Implementation Measurement Based Evaluation
Guarantee the Convergence
Slide 6
Current Interdomain Routing Protocol: BGP (Border Gateway Protocol)
Path-Vector Protocol:Each node calculates its AS paths to each reachable destination and advertises that to adjacent neighbors
Only a single route is chosen
A
B
D
F
C
EDEF*DABEF
CF*CEFCBEF
ABEF*ADEF
F*
CF*
EF *EF *ECF
BEF*BCF
DEF*
CF*CEF
Slide 7
When BGP is not enough: Avoiding an AS
AS A does not trust AS E to carry its traffic AS A wants the route BCF in AS B instead of BEF Even if B is willing to satisfy A’s request, B can not do
that because all of B’s neighbors would also switch to BCF
BCF is available, it is just not advertised or used
A
B
D
F
C
E
CF*CEFCBEF
EF *ECF
BEF*BCF
DEF*DABEF
ABEF*ADEF
F*
Slide 8
When BGP is not enough: Incoming Traffic Control
Too much traffic uses EF, CF barely used Receiving AS has little say over which path to use People do want that in today’s Internet
12,468 stubs out of 31,311 ASes multi-homed More than 4,900 ASes use AS prepending
A
B
D
F
C
CF*CEFCBEF
BEF*BCF
ABEF*ADEF
F*
EF *ECF
DEF*DABEF
E
Slide 9 The High Level Problem Flexibility: single path routing limits flexibility
Different people have different needs They care about properties of the paths
Efficiency: avoid disclosing states unnecessarily Most ASes are satisfied with BGP routes
Control: give intermediate ASes more control Get more alternative paths Current business relationship limited to adjacent ASes
Slide 10 Option 1: BGP
Flexibility No, single path limits flexibility
Efficiency Yes
Control Yes, but not perfect ASes use local policies to control its traffic But very hard to control non-adjacent
ASes
Slide 11
Option 2: Source Routing Flexibility
Yes, ultimate flexibility Efficiency
No, all internal states exposed Control
No, intermediate ASes lose control
A
B
D
F
C
E
ABCF
ADECF
ABEF
Slide 12 At Another Level: Overlays
Virtual networks above physical networks
Additional cost in setting up overlay boxes
They have no control over physical paths
A
B
D
F
C
EOverlay nodes
Slide 13 Our Proposal: MIRO
Flexibility Expose the alternative routes already there
Efficiency Use BGP for default routes Explore alternatives only when necessary
Control Intermediate ASes still have routing policies They can negotiate with an arbitrary AS They can control what routes they expose
Slide 14 Outline of The Talk
Motivation and Related Work Design and Implementation Measurement Based Evaluation
Guarantee the Convergence
Slide 15
MIRO Design: AS-level Path-Vector Protocol
AS-level routing How do you divide the boundaries AS as a natural entity of trust and policy
specifications Each AS decides how traffic should flow
Path-vector protocol Path-vector protocol fits “federated” world Build AS paths along the way Downstream AS should be able to control who may
send traffic through its network
Slide 16
MIRO Design: Route Negotiation
Pull-based route retrieval Solicit routes only when necessary
Bilateral negotiations Business relationships usually bilateral anyway
A
B
D
F
C
E
CF*CEFCBEF
EF *ECF
BEF*BCF
DEF*DABEF
ABEF*ADEF
Any route to F avoiding E?
BCF
BCF is OK
F*
Slide 17
MIRO Design: Negotiation with Anyone
Negotiate with adjacent/non-adjacent ASes Negotiate with ASes in either direction
Sender-side negotiation Receiver-side negotiation
A F
C
CF*CEFCBEF
ABEF*ADEF
F*
DEF*DABEF
E
BEF*BCF
EF *ECF
Any route to F avoiding EF?
Yes BCFBCF OK
BEFBCF*
ABCF*ADEF
DEF*DABCF
D
B
Slide 18
MIRO Design: Routing Tunnels
Destination based routing is no longer sufficient Tunnels transmit traffic between two endpoints Normally implemented by IP-in-IP encapsulation Assign unique tunnel id upon successful negotiation
A
B
D
F
C
E
Old packet
New IP header
New IP header
Old packet
Old packet
Slide 19
MIRO Implementation: Revisiting Intra-AS Structure
AS AIngress routers
Egress routers
AS C AS E
AS F
Use IBGP todistribute routes
R1(12.34.56.1)
R2(12.34.56.2) R3(12.34.56.3)
AS B(12.34.56.0/24)
Slide 20
What IP Do We Use in Encapsulation?
IP of exit links
IP of egress routers
One IP for all tunnels Rewrite to IP
of egress router at ingress routers
AS AIngress routers
Egress routers
AS C AS E
R1(12.34.56.1)
R2(12.34.56.2) R3(12.34.56.3)
AS B(12.34.56.0/24)
Slide 21 When to Destroy Tunnels
Terminating the business contract Either party may tear it down actively
BGP route is withdrawn or changed The route from upstream to
downstream The route selected at the responding
AS Failure of the ASes
Slide 22 Outline of The Talk
Motivation and Related Work Design and Implementation Measurement Based Evaluation
Guarantee the Convergence
Slide 23 Evaluation Outline
FlexibilityMIRO does provide more flexibility
EfficiencyNot exploring too much state in
negotiations Control
ASes can choose strict or flexible policy, strict policy already gives much benefit
Slide 24 Evaluation Methodologies
How do we evaluate a new routing protocol without deploying it
Something resembling the Internet The behavior of routing protocols
governed by local policies Where do we find local policies
Slide 25
AT&T 2
sibling sibling
Local Policies in Today’s Internet
AT&T
Princeton
provider
customer
$$
UUNETpeer peer
Export rules: Advertise all paths to customers or siblings Advertise only customer routes to peers or providersPreference rules: Prefer customer routes over peer or provider routes
Slide 26 Evaluation Methodologies
Local policies not available Use business relationships to
approximate Business relationships not available
Use relationship inferring algorithm which takes real BGP dumps as input
They are not perfect, but they are the closest we can get toward Internet
Slide 27 The Data
2000/2003/2005 RouteView BGP dump Gao’s AS relationship inference algorithm Each AS is one node in the topology
687375340558449982093010/8/2005
520306230649342311613010/8/2003
23110311653117793882910/1/2000
Sibling Links
Peering links
P/C links
Link #AS #Date
Slide 28 Node Degree Distribution
0
0.2
0.4
0.6
0.8
1
1 10 100 1000
Number of Edges (Log Scale)
Node P
erc
enta
ge
2000 2003 2005
10/48/80 nodes with degree >
200
1/3 of nodes with only 1
edge
40% of nodes with 2
edges
Slide 29 Evaluation Methodologies
Evaluated applications Avoid an AS for security or performance Controlling incoming traffic
Evaluated policies Strict policy (/s) Respect export policy (/e) Most flexible policy (/a)
Only build one tunnel Negotiate with adjacent neighbors and the
ASes on the default BGP path only (avoiding AS)
Slide 30 Avoiding AS: success rate
BGP only gets around 30% Strict policy can already get around 65% More flexible policy can get around 76% Even source routing can only push 10% more
91.1%
76.0%73.7%67.8%29.5%2005
90.4%
76.6%74.6%67.0%31.2%2003
89.5%
75.3%72.9%65.4%27.8%2000
SourceRoutin
g
MIRO/aMIRO/eMIRO/sBGPDate
Slide 31
Avoiding AS: state explosions
76.0%73.7%
67.8%Success rate
139.02.38Flexible
58.92.53Export
36.6
2.80Strict2005
Path #/tupleAS #/tuplePolicy
With more flexible policies Number of ASes we negotiated with decrease Number of paths increase
Results on 2000 and 2003 data Number of ASes roughly the same Number of paths increase with time
Slide 32
Avoiding AS: Incremental Deployment
0
20
40
60
80
100
0.01 0.1 1 10 100
Percentage of ASes Adopted MIRO (log scale)
Perc
enta
ge o
f to
tal gain
2005/ s 2005/ e 2005/ a
44% of total gain if 0.2% of
nodes (40 nodes) adopted
MIRO
82% of total gain if 25% of nodes adopted
MIRO
53% of total gain if 0.2% of
nodes (40 nodes) adopted
MIRO
99.9% of total gain if 25% of nodes adopted
MIRO
Slide 33
Another Real Application:Incoming Traffic Control
Assume that a multi-homed stub AS wants to balance incoming traffic How much traffic can it move by just
negotiating with one upstream AS 10,383 stubs out of 20,930 ASes (2005
data) 90% can move more than 10% of the traffic 50% can move more than 40% (flexible
policy) 50% can move more than 25% (strict policy)
Slide 34
Another Real Application:Incoming Traffic Control (cont)
In the MIRO paper, we assume stub AS blindly obey selection made by power node, here, stub AS re-run BGP selection process
10,383 stubs out of 20,930 ASes (2005 data) 77% can move more than 10% of the traffic 28% can move more than 40% (flexible policy) 50% can move more than 18% (strict policy)
Slide 35 Outline of The Talk
Motivation and Related Work Design and Implementation Measurement Based Evaluation
Guarantee the Convergence
Slide 36 The Convergence Problem
Oscillation is bad, it leads to lost packets BGP does not guarantee convergence MIRO introduces more flexibility, so it
opens up new problems for convergence Certain policies guarantees convergence
One tunnel + do not advertise to others Advertise to stub ASes only
Slide 37
Convergence Problem:BGP May Not Converge
X
A prefers ABX over AXB prefers BCX over BXC prefers CAX over CX
A
B C
A counter-example that does not converge
AX
BX CX
AX
BX
CX
ABX
CAXBCX
AX
BX CXBCX CAX
ABX
Slide 38
Topology + Policy -> Convergence
Many scenarios do not happen in the real world A few prevalent relationships
Provider/Customer, Peer/Peer, Sibling/Sibling Topology
Provider/customer relationships implies a partial order Policy:
Export policy -> some paths never occur Preference policy -> some paths always favored
Conclusion:BGP converges without global coordination
Slide 39 The Convergence of MIRO
Counter-examples show that MIRO does not converge without restrictions
Proved that MIRO would converge if certain policy guidelines are obeyed
Guideline A is the original Guideline that guarantees the convergence of BGP:customer routes are always preferred over any provider routes or peer routes
Slide 40
Guideline B: Tunnels as a Higher Level
Tunnels constructed using only BGP and not advertised back to BGP
A
B
D
F
C
E
CF*CEFCBEF
BCEFBEF*BCF
ABCFABEF*ADEF
Slide 41
Guideline C: Advertise Tunnels to Stub ASes Only
Advertise tunnels as BGP paths to stubs only
A
B
D
F
C
E
CF*CEFCBEF
BCEFBEF*BCF
ABCEFABEF*ADEF
Stub node
Slide 42
Strict Policy Does Not Guarantee Convergence
Slide 43
Strict Policy with Restriction Guarantees Convergence Guideline D:
Require that each AS enforces a strict order such that first_downstream(r) ≺ a(r.prefix)
Guideline E:Only allow a tunnel if the route from current node to first_downstream(r) does not contain a tunnel
Slide 44
Mixing and Matching the Guidelines
Guideline A can be replaced with the other Guidelines in the original paper
Each AS can choose between A+C and A+D, or they can choose between A+C and A+E
Guideline B-tunnel can be built on top of Guideline C-tunnel, Guideline D-tunnel, or Guideline E-tunnel
Slide 45
These Guidelines Are Practical
Most end-to-end paths contain only 1 tunnel Many ASes are stub ASes Average AS path is 4 Negotiations allowed between non-adjacent ASes
Most stub ASes can be satisfied by Guideline C Economic incentives motivate for strict policy,
and the restrictions are easy to implement
Slide 46 Summary
MIRO: Multi-path Interdomain ROuting Use BGP for default routes, negotiate
only when necessary Give more power to individual ASes Incrementally deployable Much flexibility achieved using one
tunnel Can adopt flexible policies
Slide 47
Thanks