internet routing cos 598a today interdomain traffic engineering l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Internet Routing (COS 598A) Today: Interdomain Traffic Engineering PowerPoint Presentation
Download Presentation
Internet Routing (COS 598A) Today: Interdomain Traffic Engineering

Loading in 2 Seconds...

play fullscreen
1 / 30

Internet Routing (COS 598A) Today: Interdomain Traffic Engineering - PowerPoint PPT Presentation


  • 236 Views
  • Uploaded on

Internet Routing (COS 598A) Today: Interdomain Traffic Engineering. Jennifer Rexford http://www.cs.princeton.edu/~jrex/teaching/spring2005 Tuesdays/Thursdays 11:00am-12:20pm. Outline. Border Gateway Protocol BGP protocol BGP policies BGP decision process

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

Internet Routing (COS 598A) Today: Interdomain Traffic Engineering


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
internet routing cos 598a today interdomain traffic engineering

Internet Routing (COS 598A)Today: Interdomain Traffic Engineering

Jennifer Rexford

http://www.cs.princeton.edu/~jrex/teaching/spring2005

Tuesdays/Thursdays 11:00am-12:20pm

outline
Outline
  • Border Gateway Protocol
    • BGP protocol
    • BGP policies
    • BGP decision process
  • BGP traffic engineering for outbound traffic
    • Predicting effects of policy changes
    • Identifying good policy changes
  • What about inbound traffic?
    • AS prepending and MEDs
    • Inter-AS negotiation
interdomain routing border gateway protocol

“12.34.158.0/24: path (2,1)”

“12.34.158.0/24: path (1)”

2

3

Interdomain Routing: Border Gateway Protocol
  • ASes exchange info about who they can reach
    • IP prefix: block of destination IP addresses
    • AS path: sequence of ASes along the path
  • Policies configured by the AS’s operator
    • Path selection: which of the paths to use?
    • Path export: which neighbors to tell?

1

data traffic

data traffic

12.34.158.5

components of bgp
Components of BGP
  • BGP protocol
    • Definition of how two BGP neighbors communicate
    • Message formats, state machine, route attributes, etc.
    • Standardized by the IETF
  • Policy specification
    • Flexible language for filtering and manipulating routes
    • Indirectly affects the selection of the best route
    • Varies across vendors, though constructs are similar
  • BGP decision process
    • Complex sequence of rules for selecting the best route
    • De facto standard applied by router vendors
    • Being codified in a new RFC for BGP coming soon
bgp protocol bgp sessions
BGP Protocol: BGP Sessions

Establish session on

TCP port 179

AS1

BGP session

Exchange all

active routes

AS2

While connection

is ALIVE exchange

route UPDATE messages

Exchange incremental

updates

bgp protocol update messages
BGP Protocol: Update Messages
  • Update messages
    • Advertisement
      • New route for the prefix (e.g., 12.34.158.0/24)
      • Attributes such as the AS path (e.g., “2 1”)
    • Withdrawal
      • Announcing that the route is no longer available
  • Numerous BGP attributes
    • AS path
    • Next-hop IP address
    • Local preference
    • Multiple-Exit Discriminator
bgp policy applying policy to routes
BGP Policy: Applying Policy to Routes
  • Import policy
    • Filter unwanted routes from neighbor
      • E.g. prefix that your customer doesn’t own
    • Manipulate attributes to influence path selection
      • E.g., assign local preference to favored routes
  • Export policy
    • Filter routes you don’t want to tell your neighbor
      • E.g., don’t tell a peer a route learned from other peer
    • Manipulate attributes to control what they see
      • E.g., make a path look artificially longer than it is
bgp policy influencing decisions
BGP Policy: Influencing Decisions

Open ended programming.

Constrained only by vendor configuration language

Apply Policy =

filter routes &

tweak attributes

Apply Policy =

filter routes &

tweak attributes

Receive

BGP

Updates

Based on

Attribute

Values

Best

Routes

Transmit

BGP

Updates

Apply Import

Policies

Best Route

Selection

Best Route

Table

Apply Export

Policies

Install forwarding

Entries for best

Routes.

IP Forwarding Table

bgp decision process path selection on a router
BGP Decision Process: Path Selection on a Router
  • Routing Information Base
    • Store all BGP routes for each destination prefix
    • Withdrawal message: remove the route entry
    • Advertisement message: update the route entry
  • Selecting the best route
    • Consider all BGP routes for the prefix
    • Apply rules for comparing the routes
    • Select the one best route
      • Use this route in the forwarding table
      • Send this route to neighbors
bgp decision process multiple steps
BGP Decision Process: Multiple Steps
  • Highest local preference
    • Set by import policies upon receiving advertisement
  • Shortest AS path
    • Included in the route advertisement
  • Lowest origin type
    • Included in advertisement or reset by import policy
  • Smallest multiple exit discriminator
    • Included in the advertisement or reset by import policy
  • Smallest internal path cost to the next hop
    • Based on intradomain routing protocol (e.g., OSPF)
  • Smallest next-hop router id
    • Final tie-break
bgp decision process in action

“(2, 1)”

“(3, 4, 1)”

“(2, 1)”

BGP Decision Process in Action

But, what if the path “(3,4,1)” would be better?

manipulating policy to move the traffic
Manipulating Policy to Move the Traffic
  • Assign local preference to…
    • Prefer one neighbor over another for a prefix
    • Prefer certain AS paths over others
  • Router configuration languages
    • Specifying rules for setting local-pref attribute
    • “if path(3, *, 1), then local-pref=110”
    • “else, local-pref=100”
  • Allow policy to over-ride shortest AS path
    • Indirect way of making one path look better or worse than another
    • Main way to do BGP traffic engineering today
bgp traffic engineering14
BGP Traffic Engineering
  • Limitations of intradomain traffic engineering
    • Alleviating congestion on edge links
    • Making use of new or upgraded edge links
    • Influencing choice of end-to-end path
  • Extra flexibility by allowing changes to BGP policies
    • Direct traffic toward/from certain edge links
    • Change the set of egress links for a destination

2

4

1

3

bgp modeling for traffic engineering
BGP Modeling for Traffic Engineering
  • Predict effects of changes to import policies
    • Inputs: routing, traffic, and configuration data
    • Outputs: flow of traffic through the network

BGP policy

configuration

Topology

BGP routing

model

eBGP

routes

Offered

traffic

Flow of traffic through the network

steps in the model
Steps in the Model
  • Effects of import policy on the routes
    • Inputs: BGP routes, and import policies
    • Output: BGP routes modified by policies
  • Set of best routes for the network
    • Inputs: BGP routes modified by policies
    • Output: set of best routes (max local-pref, min AS path,…)
  • Best route per router
    • Inputs: set of BGP routes, and intradomain costs
    • Outputs: best route (closest egress) per prefix per router
  • Link-level paths
    • Inputs: best route per router, and intradomain costs
    • Outputs: link-level shortest path(s) from entry to egress
but hard to select good import policy changes
But, Hard to Select Good Import Policy Changes
  • Can’t enumerate all choices
    • Many eBGP sessions
    • Around 100K prefixes
    • Highly programmable policies
  • Risk of creating side-effects
    • Overhead of BGP routing changes
    • Unpredictable behavior of others
  • Vulnerability to changes
    • New eBGP routes from neighbors
    • Shifts in the traffic volume per prefix
traffic engineering guidelines
Traffic Engineering Guidelines
  • Predictability
    • Ensure the BGP decision process is deterministic
    • Assume that BGP updates are (relatively) stable
  • Outbound traffic (import policy, local preference)
    • Easier to control how traffic leaves the network
    • Cooperate with neighbor ASes for inbound traffic
  • Limit overhead introduced by routing changes
    • Minimize frequency of changes to routing policies
    • Limit number of prefixes affected by changes
  • Limit impact on how traffic enters the network
    • Avoid new routes that might change neighbor’s mind
    • Select route with same attributes, or at least path length
measurement data
Measurement Data
  • Analysis of peering links
    • Links connecting AT&T to other large providers
    • Relatively small # of high-end routers
  • BGP routing tables
    • Log daily output of “show ip bgp” command
    • Extract BGP routes for each prefix
  • Cisco Netflow
    • Collect continuous flow-level measurement
    • Aggregate the traffic by prefix
    • Focus on outbound traffic to peers
controlling the scale
Controlling the Scale
  • Destination prefixes
    • More than 90,000 destination prefixes
      • Don’t want to have per-prefix routing policies
    • Small fraction of prefixes contribute most of the traffic
      • Focus on the small number of heavy hitters
    • Define routing policies for selected prefixes
  • Routing choices
    • About 27,000 unique “routing choices”
      • Help in reducing the scale of the problem
    • Small fraction of “routing choices” contribute most traffic
      • Focus on the very small number of “routing choices”
    • Define routing policies on common attributes
avoid impacting downstream neighbors
Avoid Impacting Downstream Neighbors

Will traffic volume change???

predictable routing change
Predictable Routing Change
  • Predictability
    • Do not change the route sent to downstream neighbor
    • Focus on prefixes where all “best” routes are identical
    • Neighbors do not even receive a new BGP advertisement!
  • Example application
    • Multiple links to same peer, with one congested link
    • Assign lower local-pref at that link for some prefixes
  • Empirical results
    • 83.5% of prefixes have shortest AS paths that are all identical (same next-hop AS, same AS path, etc.)
    • These prefixes are responsible for 45% of the traffic
    • Plenty of scope to move traffic in a predictable fashion
semi predictable routing change
Semi-Predictable Routing Change
  • Semi-predictability
    • Do not change the length of the AS path sent to neighbor
    • Neighbors receive new advertisement with same length
    • (Hopefully) they still make the same routing decision
  • Example application
    • Need to move some traffic from one peer to another
    • Find prefixes with “best” paths via both neighbors
    • Assign lower local-pref at some links for some prefixes
  • Empirical results
    • 10-15% of prefixes have shortest paths with 2 next hops
    • These prefixes contribute 35-40% of the traffic
    • Potential to move traffic in a semi-predictable fashion
influence of as path length
Influence of AS Path Length
  • AS path length
    • Plays a significant role in the BGP decision process
    • All “best” routes must have the same AS path length
    • 10% of prefixes have choices with different path lengths
  • An idea: a more flexible approach
    • Possible to disable consideration of AS path length, and incorporate AS path length in local-pref assignment
    • E.g., treat paths of length 3 and 4 as equally good
  • AS prepending by other ASes
    • Inflating AS path length by adding fake hops
    • E.g., “701 80 80 80” instead of “701 80”
    • 18% of routes had some form of AS prepending
why inbound traffic is hard to manage
Why Inbound Traffic is Hard to Manage
  • Other ASes decide how to send to you
    • Destination-based routing
    • Other ASes decide which path to take
    • Based on their own policies

2

p

4

1

3

AS 2 doesn’t know how AS 1 will send traffic toward p

as prepending
AS Prepending
  • Artificial inflate AS path length
    • Prepend your own AS in the path
    • E.g., turn “3 4 5” into “3 3 3 4 5”
    • Hope to make the path less attractive

“3 4 5”

1

3

“3 3 3 4 5”

multiple exit discriminator med
Multiple Exit Discriminator (MED)
  • Tell your neighbor what you want
    • MED attribute to indicate receiver preference
    • Decision process picks route with smallest MED
    • Can use MED for “cold potato” routing
    • But, have to get your neighbor to accept MEDs

“3 4 5” with MED=1

1

3

“3 4 5” with MED=2

inter as negotiation
Inter-AS Negotiation
  • Better to cooperate?
    • Negotiate where to send
    • Inbound and outbound
    • Mutual benefits
  • But, how to do it?
    • What info to exchange?
    • How to prioritize the many choices?
    • How prevent cheating?
  • Open research territory

Customer B

Provider B

multiple

peering

points

Early-exit

routing

Provider A

Customer A

next time multi homed customers
Next Time: Multi-Homed Customers
  • Two papers
    • “A Measurement-Based Analysis of Multi-homing” (SIGCOMM’03)
    • “Optimizing Cost and Performance for Multihoming” (SIGCOMM’04)
  • Reviews of both papers
    • Brief summary of the paper
    • Reasons to accept the paper
    • Reasons to reject the paper
    • Suggestions for future research directions