Multi-path Interdomain ROuting by Xu and Rexford Alan Dunn Topics in Network Protocol Design March 5, 2010

Outline Motivation Protocol Description Evaluation

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

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

BGP Example AS 7018 (AT&T) AS 1239 (Sprint) AS 18 (UT Austin) /16 next-hop = AS_PATH = AS 209 AS /16 next-hop = 1 AS_PATH = /16 next-hop = 2 AS_PATH = /16 -> /16 -> /16 -> /16 -> 2 ??? /16 next-hop = 3 AS_PATH =

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

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

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

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)

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)

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

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

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)

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

MIRO State Establishment 3. A accepts route BCF 4. Confirmed, your tunnel ID is 7 Tunnel IDNext hop 7C DestinationNext hop “Prefixes with AS routes that end in F” B, id = 7

MIRO – Implementation Considerations Implementation of tunnel concept – Option 1: IP address per link – Option 2: Single link for all tunnels + additional tunnel identifier 1 2 Link addr: 3 Link addr: 4 Link addr: Tunnel addr: 3

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

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

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

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

AS Relationships Guiding principle for AS relationships: Don’t carry traffic unless it benefits your AS AB C AS_PATH = 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!) = Provider to Consumer

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 AB C AS_PATH = D E F = Provider to Consumer = Siblings = Peers

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

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)

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

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

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

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

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” A D C B Congested D: Can you use routes to me that don’t end in AD?

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

Extra Slides