More Traffic Engineering

1. More Traffic Engineering • TE with MPLS • TE in the inter-domain

2. Practical QoS routing - CSPF • Some form of QoS routing is actually deployed • TE extensions for IGP and Constrained SPF (CSPF) • Find a path to a single destination • Not a shortest path tree to all destinations like SPF • Take into account • available bandwidth on links • Link attributes • Administrative weight • These are advertised by TE extensions to the IGP

3. TE info advertised by the IGP • Bandwidth • This is the available bandwidth on a link • Link attributes • Bitmap of 32 bits to encode “link affinity” • I can use this to avoid certain paths/links, if they belong to the same SRLG for example • Helps achieve path diversity • Administrative weight • It is a link cost specific to TE • Different that the IGP link cost • IGP cost usually reflects bandwidth availability • Can be used to encode TE specific information • Link delays for example • It is still static – configured by the administrator

4. Other TE knobs/functions • Re-optimization • After I compute a route for an LSP I can check for better ones • Periodically, manually or triggered by an event • Tunnel priorities and pre-emption • Each LSP has a 0-7 priority • When establishing a higher priority LSP it is possible to preempt an existing lower priority LSP • Load sharing • Can split arbitrarily the load among multiple LSPs to the same destination • “auto-bandwidth” • Monitor the bandwidth used by the LSP dynamically • Adjust the path/reservation of the LSP accordingly

5. Sending traffic into an LSP • The ingress router can send traffic into the LSP • Include it in its SPF computation, can be used as a next-hop for traffic to destination • Can configure a “cost” for the tunnel • Use the LSP if the IGP path fails • Or vice versa • Could even load share between a LSP and an IGP path • “Forwarding adjacency” • Advertise an LSP in IGP as if it was a regular link • It will be considered when computing shortest paths

6. Off-line MPLS TE • Compute best LSP paths for the whole network • Signal them using RSVP • When something changes • Re-compute all the LSPs again • Off-line allows for better control • Compute best LSP paths for the whole network • No oscillations • Global view can optimize resource usage • But can not respond to sudden traffic changes • Attacks • Flash crowds

7. On-line MPLS TE • Full mesh of LSPs with on-line optimization • Compute the LSPs independently in each ingress • will have to be done in some automated fashion • Periodic re-optimization • Triggered re-optimization • Auto-bandwidth • May be a lot of CPU in a large full mesh • 10,000 – 50,000 LSPs to re-optimize • Can have the oscillations of IGP routing • Re-optimization is a local decision at ingress nodes • Can make conflicting decisions • There can be setup collisions • Two ingress routers attempt to setup an LSP on a link at the same time and fail

8. Improved on-line MPLS TE • Minimum inference routing [kar, kodialam, Lakhsman, 2000] • Avoid loading links that are on multiple shortest paths • Similar to trunk reservation • MATE [Elwalid et al. 2001] • Multiple LSPs for each source/destination pair • Split flow between a source/destination pair among these LSPs • Goal: minimize the cost of routing • Problem: granularity of flow splitting • Each source decides independently using a iterative gradient descent method • Feedback from the network using probe packets • Measure delay over an LSP • TeXCP [kandula et al., 2005] • Similar to the above • Monitor the link utilization with explicit feedback • Problem: Needs support from the network

9. Limitations of On-line solutions • Consider only point-to-point flows • What happens with multicast traffic? • No failures • What happens when links fail? • Effects of BGP/hot-potato? • Can have a dramatic effect on traffic inside the network • Must avoid oscillations • Adjustments to the flow splits must be done carefully

10. Other hard questions • How does my optimal routing depend on the traffic matrix estimation • If my estimation if wrong how bad is my routing • Are there any “universally” good routings? • Overlays? • Traffic may flow very differently than my routing tables may suggest • BGP effects • Hot potato mostly • Security? • Can I adapt traffic engineering fast enough to react to DoS attacks?

11. When links fail? • All this TE is good when links do not fail • What happens in failures? • MPLS TE • Failures are handled by fast reroute • Some minimal optimization when determining backup LSPs • Global re-optimization if the failure lasts for too long • IGP weight optimization • It is possible to optimize weights to take into account single link failures • Other approaches: • Multi-topology traffic engineering • Optimize the weights in the topologies that are used for protecting from failures

12. More IGP TE • Can take BGP effects into account • Consider them when computing how traffic is routed after each weight setting • It is possible to extend this in a multi-topology model • Optimize the different backup topologies • Achieve optimal traffic engineering even after failures • And very fast repair times • Active research area

13. Diff-Serv and TE and MPLS • Diff-Serv defines multiple classes of service • Can reserve resources for each class of service • Not per flow • Different trade-off • Better scalability • Worse QoS guarantees for my traffic • In diff-serv each packet is marked • IP packet • 6 DSCP bits in the IP header • MPLS packet • 3 EXP bits in the MPLS header

14. Issues • 6 DSCP bits do not fit in the 3 EXP bits • Can define DSCP -> EXP mappings • Can have different LSPs for each DSCP value • L-LSP mode • Available bandwidth now is advertised per EXP class • Different amount of bandwidth per class available on each link • CSPF can take this into account • Admission control also takes this into account

15. How to combine IP and MPLS diff-serv? • Tunneling • IP inside MPLS • MPLS inside MPLS • Each level has its down EXP/DSCP bits • How to set them? • What are the new EXP bits when I do a push? • What are the old EXP bits when I do a pop? • Different models • Uniform: all levels have the same values • Single ISP, single DS model • Pipe: different levels have their own values • Do not touch the values at the lower levels • ISP provides transit to traffic with different DS models

16. How to tunnel Diff-Serv traffic over MPLS • E-LSP: • Can combine different Diff-serv levels of traffic into a single LSP • The service given to each packet is determined by the EXP bits in the MPLS header • Can have only 8 Diff-Serv levels • L-LSP: • Each LSP carries only a single Diff-Serv level • The service given to each packet is determined by the MPLS label • Can have more precise control of the QoS given to the traffic • Worse scaling though, will need many more LSPs

17. How to select where to send QoS traffic? • How do I choose where to send traffic? • May have data traffic and VoIP traffic • VoIP traffic should go over the DS LSP • Use the FEC • Define a filter that will cover the traffic • May be able to include DSCP values in the filter • Based on its destination • Need to design my network so that I can distinguish traffic

18. Traffic engineering and overlays • Overlays may/will get popular • Will carry a lot of traffic • Overlays may affect how traffic moves in my network • Overlays often have a mechanism to monitor (overlay) links and choose the ones that are better • Usually lower latency • This may cause a lot of traffic shifts in the IP network • Will interfere with the TE in the IP network • TE and overlay decisions are probably • Independent • Conflicting • Different goals • May end up causing oscillations in the IP network • Not too different than the BGP effects

19. What is going on in the Inter-Domain • All the above apply to the network of a single provider • Things are much harder in the Inter-domain • Can rely only on BGP • And BGP was not designed for TE • Does not convey information about the performance of paths

20. BGP techniques • Basic BGP tools are • For inbound traffic • AS path pre-pending • Export policies • Provider gives some options to the customer • Customer selects according to his goals • De-aggregation and selective advertisement • MED • For outgoing traffic • Local preference • The problems is that it is hard to predict the effect of certain changes • It may make things worse

21. Overlays for improving QoS in the Inter-domain • Use an overlay to “augment” the performance of BGP • Overlays have been used for long time • To introduce new functionality • Multicast, IPv6 • Content distribution networks • RON – Resilient overlay network • Build a small (<50 nodes) overlay • N nodes in a full mesh • Use probing to constantly estimate the quality of the paths between the nodes • Path availability • Path loss rate • Path TCP throughput • Flood this information over the overlay using a link state-link protocol • Select which path to use based on rich application specific policies

22. RON works but there are some problems • In most of the cases RON improved the performance seen by the packets • One extra hop is sufficient • But • Overlay forwarding is a bit slower than native forwarding • Like in all load sensitive routing can have oscillations • Keep using a good path for a while • Latency measurements are round-trip • By overlay links are asymmetric • Probing limits the scalability of the overlay • Overlay nodes may be connected through DSL

23. Overlays and multi-homing • Similar problems • Overlay can improve the performance of a singly connected network • But when the network is connected through multiple providers (> 2) then it can do quite well • if it implements clever route selection • Based on monitoring paths similar to the way the overlay monitors overlay links