multi path interdomain routing by xu and rexford
Download
Skip this Video
Download Presentation
Multi-path Interdomain ROuting by Xu and Rexford

Loading in 2 Seconds...

play fullscreen
1 / 31

Multi-path Interdomain ROuting by Xu and Rexford - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Multi-path Interdomain ROuting by Xu and Rexford' - suchin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
multi path interdomain routing by xu and rexford

Multi-path InterdomainROutingby Xu and Rexford

Alan Dunn

Topics in Network Protocol Design

March 5, 2010

outline
Outline
  • Motivation
  • Protocol Description
  • Evaluation
motivation
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
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
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)

bgp strengths weaknesses
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
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
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
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
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
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
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

miro protocol cont d
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
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
MIRO State Establishment

4. Confirmed, your tunnel ID is 7

3. A accepts route BCF

miro implementation considerations
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

miro implementation considerations cont d
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
Evaluation – What to Evaluate
  • Goal: Demonstrate enough flexibility to implement some potentially desired policies
  • Policies chosen: Avoiding an AS, load balancing
evaluation difficulties
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
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
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

as relationships cont d
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

as relationships cont d1
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>
evaluation
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
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
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
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
Evaluation – Incrementality (cont’d)
  • Deploying at 0.2 percent most connected nodes will yield 50% success rate
evaluation load balancing
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

evaluation load balancing cont d
Evaluation – Load Balancing (cont’d)

Important assumption: Equal traffic per link

ad