Multi-path Interdomain ROutingby Xu and Rexford

Alan DunnTopics 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 ExampleAS 7018(AT&T)

AS 1239(Sprint)

AS 18(UT Austin)

128.83.0.0/16next-hop = 128.83.4.5AS_PATH = <18>

AS 209

AS 6543128.83.0.0/16next-hop = 1AS_PATH = <209,6922,18>

128.83.0.0/16next-hop = 2AS_PATH = <6543,270,123,18>

128.83.0.0/16 -> 1

128.83.0.0/16 -> 2

1 2

128.83.0.0/16 -> 1

128.83.0.0/16 -> 2??? 3

128.83.0.0/16next-hop = 3AS_PATH = <7018,209,6922,18>

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 ID Next hop7 C

Destination Next 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

12

Link addr: 3

Link addr: 4

Link addr: 5

12

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

A B

C AS_PATH = <C,A>

• 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

A B

CAS_PATH = <D,B,C>

DAS_PATH = <B,C>

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 = <D,…,C,B,…,A>

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

BCongested

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