Multi-path Interdomain ROuting by Xu and Rexford

1. Multi-path InterdomainROutingby Xu and Rexford Alan Dunn Topics in Network Protocol Design March 5, 2010

2. Outline • Motivation • Protocol Description • Evaluation

3. Motivation • Examine “large scale” (interdomain) routing • Involves parties with varying security and performance needs • Claim: Current interdomain routing is too inflexible for current needs

4. Reminder: BGP – Border Gateway Protocol • Standard Autonomous System (AS) level routing protocol • “BGP speakers” for AS advertise complete AS paths for aggregate routes as represented by IP prefixes • BGP routes combine with Interior Gateway Protocol (IGP) routing schemes (RIP, OSPF) to form full routes across Internet

5. BGP Example AS 1239 (Sprint) 128.83.0.0/16 next-hop = 3 AS_PATH = <7018,209,6922,18> AS 7018 (AT&T) 128.83.0.0/16 -> 1 128.83.0.0/16 -> 1 3 ??? 128.83.0.0/16 -> 2 128.83.0.0/16 -> 2 128.83.0.0/16 next-hop = 1 AS_PATH = <209,6922,18> AS 6543 128.83.0.0/16 next-hop = 2 AS_PATH = <6543,270,123,18> 1 2 AS 209 128.83.0.0/16 next-hop = 128.83.4.5 AS_PATH = <18> AS 18 (UT Austin)

6. BGP Strengths/Weaknesses • AS level management allows tractability (16-bit AS space) • Routing metric is coarse • Number of ASes: not necessarily related to path performance or length • Inflexible • ASes export one path per prefix • No recourse for downstream nodes for undesirable paths

7. Problem Description • Allow for greater flexibility in path selection • Concerns: • Incrementality – hard to modify deployed system • Manageability – can’t keep track of too much data • Authority – allow for AS autonomy

8. Potential Solutions • Source routing: Let hosts or edge routers pick route • Very flexible • Problems: • Ends have to know which route to take • Intermediate domains lose control

9. Source Routing Example Feedback Based Routing (Zhu et. al. 02) • Two types of routers: Access routers and Transit routers • One access router per end organization • Transit routers in non-stub ASes • Transit routers only forward packets based upon contained tokens and propagate (flood) link existence information • Access routers are responsible for route computation and monitoring (select best route based upon RTT)

10. Potential Solutions (cont’d) • Overlay routing: Impose virtual topology over the Internet • Choice in routing by picking intermediate nodes from the overlay which in turn forward toward the ultimate destination • Problems: • Encapsulation overhead • Little path control: dependent on underlying paths that exist between intermediate nodes (runs on top of existing Internet protocols)

11. MIRO Protocol • Main idea: Add route negotiation to BGP • Party that desires change in routing contacts other ASes • ASes may reveal other stored routes that were not previously exported • Exact form of querying – types of policy that routers will be able to understand - left unspecified

12. Example of MIRO Negotiation A queries B: Any route to F avoiding E? AS A wants to select a route to F that avoids AS E 2. B responds to A: BCF 3. A accepts

13. MIRO Protocol (cont’d) How does this address our goals? • Incrementality: Nodes that don’t know about MIRO simply ignore it and continue with BGP • Manageability: Routing still on AS level, only new state is that of added tunnels, which should be small compared to BGP routing • Authority: Intermediate ASes get to choose which routes to reveal - additionally could set conditions for revealed routes (eg: charge for traffic)

14. MIRO Protocol – Additional Details • Negotiation Details • No special multilateral negotiation • Querying can be done by proxy – AS that receives a request can in turn query other nodes • Not necessarily clear who to query for particular request • Conceptual state for established routes • When path established by negotiation, tunnel identifier created at AS that originated new route • Querying AS uses that identifier to send along the chosen AS route

15. MIRO State Establishment 4. Confirmed, your tunnel ID is 7 3. A accepts route BCF

16. MIRO – Implementation Considerations • Implementation of tunnel concept • Option 1: IP address per link • Option 2: Single link for all tunnels + additional tunnel identifier Tunneladdr: 3 Linkaddr: 4 Linkaddr: 3 2 2 1 1 Linkaddr: 5

17. MIRO – Implementation Considerations (cont’d) • IP address per link • Easier to implement • Reveals extra topology information to upstream • Could break from changes in internal AS topology • Single address and separate tunnel identifier • Reveals no extra topology information • Requires packet rewriting

18. Evaluation – What to Evaluate • Goal: Demonstrate enough flexibility to implement some potentially desired policies • Policies chosen: Avoiding an AS, load balancing

19. Evaluation – Difficulties • Ideally, would test on Internet • Unfortunately, impossible for protocol that changes core routing • Instead used RouteViews • As part of AS 6447, conducts eBGP pairings with a number of network backbones • Allowed to do this because it does not pass on any information learned • Can use this data to see which BGP routes an AS knows and further which routes it actually propagated

20. Evaluation – Difficulties (cont’d) • AS generally not willing to export all routes • Economic reasons at play: AS relationships • AS relationships and their details are often not public information • Four main roles (Gao 01): • Provider • Consumer • Siblings • Peers

21. AS Relationships • Guiding principle for AS relationships: Don’t carry traffic unless it benefits your AS • Producer: Provides service to Consumer, wants Consumer to know routes through it • Consumer: Receives routes from Producers, does not want to transit traffic between them (would get charged twice!) A B C AS_PATH = <C,A> = Provider to Consumer

22. AS Relationships (cont’d) • Peers: Willing to cooperate to service each others customers, but not willing to transit for other peers • Siblings: Full cooperation – willing to transit for other siblings AS_PATH = <B,C> AS_PATH = <D,B,C> A B C D E F = Provider to Consumer = Siblings = Peers

23. AS Relationships (cont’d) • Can infer AS relationships from BGP route data • Idea: Allowed exports have a certain pattern – moved “uphill” to providers and then redistributed “downhill” to consumers … … A B C D • AS_PATH = <D,…,C,B,…,A>

24. Evaluation • MIRO evaluated under three conditions depending on willingness of ASes to export routes: • Strict: ASes only export routes with same local preference • Respect export policy: ASes willing to export routes obeying previously described relationships • Most flexible ASes willing to export all routes (mostly hypothetical scenario)

25. Evaluation – Avoiding an AS • For each AS, examine ability to avoid every non-neighbor AS • Why is this not 100%? Although any AS path can be chosen with source routing, sometimes there is no path that can avoid an AS • Probably due to distribution of number of neighbors per node

26. Evaluation – Cost of Avoiding an AS AS#/tuple: Number of ASes that were contacted in order to establish a new pair (= communication cost) Path#/tuple: Number of candidate paths that were considered (= server load) Note: Unclear from their work whether these include unsuccessful attempts, which could be costly

27. Evaluation - Incrementality • Observation: Only a small number of ASes in the BGP topology are particularly well connected • Deploying MIRO at these nodes may have a greater effect

28. Evaluation – Incrementality (cont’d) • Deploying at 0.2 percent most connected nodes will yield 50% success rate

29. Evaluation – Load Balancing • AS wants to rebalance incoming traffic among its incoming links • Can do this by asking upstream node to advertise alternate routes • Upstream nodes that lie on route to destination for many sources: “power nodes” D: Can you use routes to me that don’t end in AD? A D C B Congested

30. Evaluation – Load Balancing (cont’d) Important assumption: Equal traffic per link

31. Extra Slides