Traffic Engineering in IP Networks Jennifer Rexford Computer Science Department Princeton University; Princeton, NJ http:/...
A Little About Me… <ul><li>Technical interests: data networking </li></ul><ul><ul><li>Network measurement </li></ul></ul><...
Outline <ul><li>Internet routing protocols </li></ul><ul><li>Traffic engineering using traditional protocols </li></ul><ul...
Internet Architecture <ul><li>Divided into Autonomous Systems </li></ul><ul><ul><li>Regions of administrative control </li...
Path Traversing Multiple ASes 1 2 3 4 5 6 7 Client Web server Path: 6, 5, 4, 3, 2, 1
Interdomain Routing: Border Gateway Protocol <ul><li>ASes exchange info about who they can reach </li></ul><ul><ul><li>IP ...
Intradomain Routing: OSPF or IS-IS <ul><li>Shortest path routing based on link weights </li></ul><ul><ul><li>Routers flood...
Motivating Problem: Congested Link <ul><li>Detecting that a link is congested </li></ul><ul><ul><li>Utilization statistics...
Traffic Engineering in an ISP Backbone <ul><li>Network topology </li></ul><ul><ul><li>Connectivity and capacity of routers...
Modeling Traffic Demands <ul><li>Volume of traffic  V(s,d,t) </li></ul><ul><ul><li>From a  source  s </li></ul></ul><ul><u...
Traffic Matrix in out Traffic matrix: V(in,out,t) for all pairs (in,out)
Problem: Hot Potato Routing <ul><li>AS is in the  middle  of the Internet </li></ul><ul><ul><li>Multiple connections to mu...
Traffic Demand: Multiple Egress Points <ul><li>Definition:  V(in, {out}, t) </li></ul><ul><ul><li>Entry link ( in ) </li><...
Traffic Mapping: Ingress Measurement <ul><li>Packet measurement (e.g., Netflow, sampling) </li></ul><ul><ul><li>Ingress po...
Traffic Mapping: Egress Point(s) <ul><li>Routing data (e.g., forwarding tables) </li></ul><ul><ul><li>Destination prefix  ...
Traffic Mapping: Combining the Data <ul><li>Combining multiple types of data </li></ul><ul><ul><li>Traffic:  V id  (ingres...
Application on the AT&T Backbone <ul><li>Measurement data </li></ul><ul><ul><li>Netflow data (ingress traffic) </li></ul><...
Three Traffic Demands in San Francisco
Underpinnings of the Optimization <ul><li>Route prediction engine (“what-if” tool) </li></ul><ul><ul><li>Model the influen...
Weight Optimization <ul><li>Local search </li></ul><ul><ul><li>Generate a candidate setting of the weights </li></ul></ul>...
Incorporating Operational Realities <ul><li>Minimize configuration changes </li></ul><ul><ul><li>Changing just one or two ...
Application to AT&T’s Backbone Network <ul><li>Performance of the optimized weights </li></ul><ul><ul><li>Good solution wi...
Conclusions <ul><li>Our approach </li></ul><ul><ul><li>Measure: network-wide view of traffic and routing </li></ul></ul><u...
Stepping Back: IP Network Management <ul><li>Lessons learned </li></ul><ul><ul><li>Good:  network-wide  views, control and...
To Learn More… <ul><li>Traffic engineering overview </li></ul><ul><ul><li>“ Traffic engineering for IP networks”  ( http:/...
Upcoming SlideShare
Loading in …5
×

ida05.ppt

572 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
572
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ida05.ppt

  1. 1. Traffic Engineering in IP Networks Jennifer Rexford Computer Science Department Princeton University; Princeton, NJ http://www.cs.princeton.edu/~jrex
  2. 2. A Little About Me… <ul><li>Technical interests: data networking </li></ul><ul><ul><li>Network measurement </li></ul></ul><ul><ul><li>Network operations </li></ul></ul><ul><ul><li>Internet routing and infrastructure </li></ul></ul><ul><li>Job history </li></ul><ul><ul><li>2005-onward: Professor in Computer Science at Princeton </li></ul></ul><ul><ul><li>1996-2005: AT&T Labs—Research </li></ul></ul><ul><ul><ul><li>Technology transfer of tools for measurement, configuration, troubleshooting, and traffic engineering to network operators </li></ul></ul></ul><ul><li>DARPA involvement </li></ul><ul><ul><li>Member of the ISAT study group </li></ul></ul><ul><ul><li>Knowledge Plane seedling project </li></ul></ul><ul><ul><li>NetVision2012 workshops </li></ul></ul>
  3. 3. Outline <ul><li>Internet routing protocols </li></ul><ul><li>Traffic engineering using traditional protocols </li></ul><ul><ul><li>Optimizing configuration to the traffic </li></ul></ul><ul><ul><li>Needs topology, routing, and traffic data </li></ul></ul><ul><li>Traffic demands </li></ul><ul><ul><li>Volume of load between edges of the network </li></ul></ul><ul><ul><li>Measuring the traffic demands </li></ul></ul><ul><li>Route optimization </li></ul><ul><ul><li>Tuning the link weights to the traffic </li></ul></ul><ul><ul><li>Satisfying the operational constraints </li></ul></ul><ul><li>Conclusions </li></ul>
  4. 4. Internet Architecture <ul><li>Divided into Autonomous Systems </li></ul><ul><ul><li>Regions of administrative control </li></ul></ul><ul><ul><li>Routers and links managed by an institution </li></ul></ul><ul><ul><li>Service provider, company, university, … </li></ul></ul><ul><li>Hierarchy of Autonomous Systems </li></ul><ul><ul><li>Tier-1 provider with nationwide backbone </li></ul></ul><ul><ul><li>Medium-sized regional provider </li></ul></ul><ul><ul><li>Campus or corporate network </li></ul></ul><ul><li>Interaction between Autonomous Systems </li></ul><ul><ul><li>Internal topology is not shared </li></ul></ul><ul><ul><li>… but, ASes interact to coordinate routing </li></ul></ul>
  5. 5. Path Traversing Multiple ASes 1 2 3 4 5 6 7 Client Web server Path: 6, 5, 4, 3, 2, 1
  6. 6. Interdomain Routing: Border Gateway Protocol <ul><li>ASes exchange info about who they can reach </li></ul><ul><ul><li>IP prefix: block of destination IP addresses </li></ul></ul><ul><ul><li>AS path: sequence of ASes along the path </li></ul></ul><ul><li>Policies configured by the AS’s network operator </li></ul><ul><ul><li>Path selection: which of the paths to use? </li></ul></ul><ul><ul><li>Path export: which neighbors to tell? </li></ul></ul>Client (12.34.158.5) 1 2 3 12.34.158.5 “ I can reach 12.34.158.0/24” “ I can reach 12.34.158.0/24 via AS 1”
  7. 7. Intradomain Routing: OSPF or IS-IS <ul><li>Shortest path routing based on link weights </li></ul><ul><ul><li>Routers flood the link-state information to each other </li></ul></ul><ul><ul><li>Routers compute the “next hop” to reach other routers </li></ul></ul><ul><li>Weights configured by the AS’s network operator </li></ul><ul><ul><li>Simple heuristics: link capacity or physical distance </li></ul></ul><ul><ul><li>Traffic engineering: tuning the link weights to the traffic </li></ul></ul>3 2 2 1 1 3 1 4 5 3
  8. 8. Motivating Problem: Congested Link <ul><li>Detecting that a link is congested </li></ul><ul><ul><li>Utilization statistics suggest overloaded link </li></ul></ul><ul><ul><li>Probe traffic suffers degraded performance </li></ul></ul><ul><ul><li>Customers complain (via the phone network?) </li></ul></ul><ul><li>Reasons why the link might be congested </li></ul><ul><ul><li>Increase in the offered traffic </li></ul></ul><ul><ul><li>Routing change due to equipment failure </li></ul></ul><ul><ul><li>Routing change due to a change in another AS </li></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>Know the cause , not just the manifestations </li></ul></ul><ul><ul><li>Predict the effects of possible changes to link weights </li></ul></ul>
  9. 9. Traffic Engineering in an ISP Backbone <ul><li>Network topology </li></ul><ul><ul><li>Connectivity and capacity of routers and links </li></ul></ul><ul><li>Traffic demands </li></ul><ul><ul><li>Offered load between points in the network </li></ul></ul><ul><li>Routing configuration </li></ul><ul><ul><li>Link weights for selecting paths </li></ul></ul><ul><li>Performance objective </li></ul><ul><ul><li>Balanced load, low latency, … </li></ul></ul><ul><li>Question: Given the topology and traffic demands in an IP network, what link weights should be used? </li></ul>
  10. 10. Modeling Traffic Demands <ul><li>Volume of traffic V(s,d,t) </li></ul><ul><ul><li>From a source s </li></ul></ul><ul><ul><li>To a destination d </li></ul></ul><ul><ul><li>Over a time period t </li></ul></ul><ul><li>Time period </li></ul><ul><ul><li>Performance debugging – minutes </li></ul></ul><ul><ul><li>Traffic engineering – hours or days </li></ul></ul><ul><ul><li>Network design – days to weeks </li></ul></ul><ul><li>Sources and destinations </li></ul><ul><ul><li>Hosts – interesting, but huge, and hard to measure </li></ul></ul><ul><ul><li>IP prefixes – still big, and not seen by any one AS </li></ul></ul><ul><ul><li>Edge routers – hmmm…. </li></ul></ul>
  11. 11. Traffic Matrix in out Traffic matrix: V(in,out,t) for all pairs (in,out)
  12. 12. Problem: Hot Potato Routing <ul><li>AS is in the middle of the Internet </li></ul><ul><ul><li>Multiple connections to multiple other ASes </li></ul></ul><ul><ul><li>Egress point depends on intradomain routing </li></ul></ul><ul><li>Problem with point-to-point models </li></ul><ul><ul><li>Want to predict impact of changing intradomain routing </li></ul></ul><ul><ul><li>But, a change in weights may change the egress point! </li></ul></ul>1 2 3 4
  13. 13. Traffic Demand: Multiple Egress Points <ul><li>Definition: V(in, {out}, t) </li></ul><ul><ul><li>Entry link ( in ) </li></ul></ul><ul><ul><li>Set of possible egress links ( {out} ) </li></ul></ul><ul><ul><li>Time period ( t ) </li></ul></ul><ul><ul><li>Volume of traffic ( V(in,{out},t) ) </li></ul></ul><ul><li>Computing the traffic demands </li></ul><ul><ul><li>Measure the traffic where it enters the ISP backbone </li></ul></ul><ul><ul><li>Identify the set of egress links where traffic could leave </li></ul></ul><ul><ul><li>Sum over all traffic with same in , {out}, and t </li></ul></ul>
  14. 14. Traffic Mapping: Ingress Measurement <ul><li>Packet measurement (e.g., Netflow, sampling) </li></ul><ul><ul><li>Ingress point i </li></ul></ul><ul><ul><li>Destination prefix d </li></ul></ul><ul><ul><li>Traffic volume V id </li></ul></ul>i d ingress destination
  15. 15. Traffic Mapping: Egress Point(s) <ul><li>Routing data (e.g., forwarding tables) </li></ul><ul><ul><li>Destination prefix d </li></ul></ul><ul><ul><li>Set of egress points e d </li></ul></ul>d destination
  16. 16. Traffic Mapping: Combining the Data <ul><li>Combining multiple types of data </li></ul><ul><ul><li>Traffic: V id (ingress i , destination prefix d ) </li></ul></ul><ul><ul><li>Routing: e d (set e d of egress links toward d ) </li></ul></ul><ul><ul><li>Combining: sum over V id with same e d </li></ul></ul>i ingress egress set
  17. 17. Application on the AT&T Backbone <ul><li>Measurement data </li></ul><ul><ul><li>Netflow data (ingress traffic) </li></ul></ul><ul><ul><li>Forwarding tables (sets of egress points) </li></ul></ul><ul><ul><li>Configuration files (topology and link weights) </li></ul></ul><ul><li>Effectiveness </li></ul><ul><ul><li>Ingress traffic could be matched with egress sets </li></ul></ul><ul><ul><li>Simulated flow of traffic consistent with link loads </li></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>Loss of Netflow records during delivery (can correct for it!) </li></ul></ul><ul><ul><li>Egress set changes between table dumps (not very many) </li></ul></ul><ul><ul><li>Topology changes between configuration dumps (just one!) </li></ul></ul>
  18. 18. Three Traffic Demands in San Francisco
  19. 19. Underpinnings of the Optimization <ul><li>Route prediction engine (“what-if” tool) </li></ul><ul><ul><li>Model the influence of link weights on traffic flow </li></ul></ul><ul><ul><ul><li>Select a closest exit point based on link weights </li></ul></ul></ul><ul><ul><ul><li>Compute shortest path(s) based on link weights </li></ul></ul></ul><ul><ul><ul><li>Capture splitting over multiple shortest paths </li></ul></ul></ul><ul><ul><li>Sum the traffic volume traversing each link </li></ul></ul><ul><li>Objective function </li></ul><ul><ul><li>Rate the “goodness” of a setting of the link weights </li></ul></ul><ul><ul><li>E.g., “max link utilization” or “sum of exp(utilization)” </li></ul></ul>
  20. 20. Weight Optimization <ul><li>Local search </li></ul><ul><ul><li>Generate a candidate setting of the weights </li></ul></ul><ul><ul><li>Predict the resulting load on the network links </li></ul></ul><ul><ul><li>Compute the value of the objective function </li></ul></ul><ul><ul><li>Repeat, keeping solution with lowest objective function </li></ul></ul><ul><li>Efficient computation </li></ul><ul><ul><li>Explore the “neighborhood” around good solutions </li></ul></ul><ul><ul><li>Exploit efficient incremental graph algorithms </li></ul></ul>
  21. 21. Incorporating Operational Realities <ul><li>Minimize configuration changes </li></ul><ul><ul><li>Changing just one or two link weights is often enough </li></ul></ul><ul><li>Tolerate equipment failures </li></ul><ul><ul><li>Weights settings usually remain good after failure </li></ul></ul><ul><ul><li>… or can be fixed by changing one or two weights </li></ul></ul><ul><li>Limit the number of weight values </li></ul><ul><ul><li>Small number of integer values is sufficient </li></ul></ul><ul><li>Tolerate inaccuracy in the traffic demands </li></ul><ul><ul><li>Good weights remain good after introducing random noise </li></ul></ul><ul><li>Limit frequency of link-weight changes </li></ul><ul><ul><li>Joint optimization for day and night traffic matrices </li></ul></ul>
  22. 22. Application to AT&T’s Backbone Network <ul><li>Performance of the optimized weights </li></ul><ul><ul><li>Good solution within a few minutes </li></ul></ul><ul><ul><li>Much better than traditional heuristics </li></ul></ul><ul><ul><li>Competitive with multi-commodity flow solution </li></ul></ul><ul><li>How AT&T changes the link weights </li></ul><ul><ul><li>Maintenance done from midnight to 6am </li></ul></ul><ul><ul><li>Predict effects of removing link(s) </li></ul></ul><ul><ul><li>Reoptimize the link weights to avoid congestion </li></ul></ul><ul><ul><li>Configure new weights before disabling equipment </li></ul></ul>
  23. 23. Conclusions <ul><li>Our approach </li></ul><ul><ul><li>Measure: network-wide view of traffic and routing </li></ul></ul><ul><ul><li>Model: data representations and “what-if” tools </li></ul></ul><ul><ul><li>Control: intelligent changes to operational network </li></ul></ul><ul><li>Application in AT&T’s network </li></ul><ul><ul><li>Capacity planning </li></ul></ul><ul><ul><li>Customer acquisition </li></ul></ul><ul><ul><li>Preparing for maintenance activities </li></ul></ul><ul><ul><li>Comparing different routing protocols </li></ul></ul>
  24. 24. Stepping Back: IP Network Management <ul><li>Lessons learned </li></ul><ul><ul><li>Good: network-wide views, control and objectives </li></ul></ul><ul><ul><li>Bad: indirect control and non-real-time control </li></ul></ul><ul><li>Next steps: Routing Control Platform </li></ul><ul><ul><li>Direct, real-time control over the routing </li></ul></ul><ul><ul><li>Network control entirely in the management system </li></ul></ul><ul><ul><li>Routers just forward packets and provide measurements </li></ul></ul><ul><ul><li>Initial prototype and results are very promising </li></ul></ul><ul><ul><li>Platform for incremental deployment of secure protocols </li></ul></ul>
  25. 25. To Learn More… <ul><li>Traffic engineering overview </li></ul><ul><ul><li>“ Traffic engineering for IP networks” ( http://www.cs.princeton.edu/~jrex/papers/ieeenet00.ps ) </li></ul></ul><ul><ul><li>“ Traffic engineering with traditional IP routing protocols” ( http://www.cs.princeton.edu/~jrex/papers/ieeecomm02.ps ) </li></ul></ul><ul><li>Traffic measurement </li></ul><ul><ul><li>&quot;Measurement and analysis of IP network usage and behavior” ( http://www.cs.princeton.edu/~jrex/papers/ieeecomm00.ps ) </li></ul></ul><ul><ul><li>“ Deriving traffic demands for operational IP networks” ( http://www.cs.princeton.edu/~jrex/papers/ton01.ps ) </li></ul></ul><ul><li>Route optimization </li></ul><ul><ul><li>“ Internet traffic engineering by optimizing OSPF weights” ( http://www.ieee-infocom.org/2000/papers/165.ps ) </li></ul></ul><ul><ul><li>“ Optimizing OSPF/IS-IS weights in a changing world” ( http://www.research.att.com/~mthorup/PAPERS/change_ospf.ps ) </li></ul></ul><ul><li>Routing Control Platform </li></ul><ul><ul><li>“ The case for separating routing from routers” ( http://www.cs.princeton.edu/~jrex/papers/rcp.pdf ) </li></ul></ul><ul><ul><li>“ Design and implementation of a Routing Control Platform” </li></ul></ul>

×