ECSE-6660 Traffic Engineering

1. ECSE-6660Traffic Engineering http://www.pde.rpi.edu/ Or http://www.ecse.rpi.edu/Homepages/shivkuma/ Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

2. Introductions:course description & calendar • Answers to frequently asked questions • Prerequisites • Informal Quiz Overview

3. Without Traffic Engineering Cars: SFO-LAX SAN-SMF LAX-SFO SMF-SAN No Traffic Engineering analogy to Human Drivers

4. Traffic Engineering: Analogy Cars: SFO-LAX SAN-SMF LAX-SFO SMF-SAN Traffic Engineering analogy

5. Links AB and BD are overloaded Links AC and CD are overloaded B 1 1 2 B B A 1 1 D 1 4 E 2 2 1 2 A C D D E E 1 2 Can not do this with OSPF 1 2 A C C Motivation • TE: “…that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks …’’ • 90’s approach to TE was by changing link weights in IGP (OSPF, IS-IS) or EGP (BGP-4) • Performance limited by the shortest/policy path nature • Assumptions: Quasi-static traffic, knowledge of demand matrix

6. Fundamental Requirements • Need the ability to: • Map traffic to an LSP • Monitor and measure traffic • Specify explicit path of an LSP • Partial explicit route • Full explicit route • Characterize an LSP • Bandwidth • Priority/ Preemption • Affinity (Link Colors) • Reroute or select an alternate LSP

7. Traffic Engineering Steps • First, determine how to lay out traffic on the physical topology • Measure traffic (e.g., city-pair-wise) • Crunch numbers • Second, do something to convince the packets to follow your plan

8. Traffic Engineering Options • BGP – play with communities, filtering • IGP – play with metrics • Linear programming can help • Source routing • ATM • MPLS

9. Routing Solution to Traffic Engineering • Construct routes for traffic streams within a service provider in such a way, as to avoid causing some parts of the provider’s network to be over-utilized, while others parts remain under-utilized (I.e. load-balance) R2 R3 R1

10. Linear Programming • TE among N cities: N² city pairs • Set up N² by N² matrix for LP • Matrix multiplication/inversion is O(M³) for M x M matrix;simplex is O(M³) matrix operations • So, LP problem is O(N12) • Also can’t deal with “looped routes”

11. The “Overlay” Solution • Routing at layer 2 (ATM or FR) is used for traffic engineering • Analogy to direct highways between SFO-LAX & SAN-SMF. Nobody enters the highway in between. L3 L3 L3 L3 L2 L2 L3 L2 L3 L3 L3 L2 L2 L2 L3 L3 L3 L3 Physical Logical

12. Traffic engineering with overlay R2 R3 R1 PVC for R2 to R3 traffic PVC for R1 to R3 traffic

13. Connectionless Routing Today • Internet connectionless routing protocols originally designed to find one route • Eg: shortest route or policy route) • Connectionless routing relies upon a global consistency criterion (GCC) • The GCC is constructed using globally known identifiers (Eg: ASNs, link weights)

14. DV: Global Consistency Criterion • The subset of a shortest path is also the shortest path between the two intermediate nodes. • If the shortest path from node i to node j, with distance D(i,j) passes through neighbor k, with link cost c(i,k), then: D(i,j) = c(i,k) + D(k,j) • D(i,*) is a distance vector at node i. j D(k,j) i c(i,k) k

15. Link State (LS): Global Consistency Criterion • The link state (Dijkstra) approach is iterative, but itpivots around destinations j, and their predecessors k = p(j) • Alternative version of the consistency condition: D(i,j) = D(i,k) + c(k,j) • Each node i collects all link states c(*,*) first and runs the complete Dijkstra algorithm locally. j c(k,j) i D(i,k) k

16. Path-Vector: BGP’s Consistency Criterion • Policy-based routing: • Arbitrary preference among a menu of available routes (based upon routes’ attributes) 135.207.0.0/16 ASPATH = 3 2 1 AS 1 AS 3 AS 4 AS 2 135.207.0.0/16 IP Packet Dest = 135.207.44.66 • Consistency: If AS2 announces a route, it is actively using the route, and will honor forwarding requests on that route Acknowledgement: Based upon Dr. Tim Griffin’s SIGCOMM Tutorial Slides

17. Limitations of Today’s Connectionless TE • Traffic mapping coupled with route availability • Changing parameters changes routes AND changes the traffic mapped to the routes • Priority rules only: • LOCAL-PREF, MED, longest-prefix match • Cannot split traffic to same destination among two paths

18. Signaled Approach (eg: MPLS) • Nice features: • In MPLS, choice of a route (and its setup) is orthogonal to the problem of traffic mapping onto the route • Signaling maps global IDs (addresses, path-specification) to local IDs (labels) • Nice label stacking, tunneling features

19. IP IP IP IP Label 0 120 1321 Label-Switched Forwarding • San Francisco prepends MPLS header to the IP packet • MPLS label is swapped at each hop along the LSP • Forwarding is done based on a label table Seattle New York (Egress) 5 San Francisco (Ingress) 1321 120 Miami

20. What Does MPLS Offer? • Tunnels • Drop a packet in, and out it comes at the other end without being IP routed • Explicit (source) routing (circuits) • Label stack • 2-label stack: “outer” label defines the tunnel; “inner” label de-multiplexes • Layer 2 independence

21. Why Tunnels? • Can’t IP route • Non-IP packets • IP packets with private addresses • Don’t want toIP route • “BGP-free” core • Don’t like IP multicast model

22. MPLS (LDP) tunnels Small header Label stacking Signaling for demux Automagic tunnels Tracks IP routing Harder to spoof No data security IP tunnels Big header No stacking (*) No signaling (yet) Configured tunnels Duh! Spoofable IPSec Tunnel Comparison

23. Bottom Line on Tunnels • Don’t need MPLS for tunnels • But MPLS tunnels have some nice properties • Decision (should be) based on cost of deploying new protocol vs. benefits

24. IP IP IP IP Label 0 120 1321 MPLS Signaling and Forwarding Model • MPLS label is swapped at each hop along the LSP • Labels = LOCAL IDENTIFIERS … • Signaling maps global identifiers (addresses, path spec) to local identifiers Seattle New York (Egress) 5 San Francisco (Ingress) 1321 120 Miami

25. Limitations of Signaled TE Approach • Requires extensive upgrades in the network • Hard to inter-network beyond area boundaries • Very hard to go beyond AS boundaries • Even within the same organization/ISP ! • Note: large ISPs (eg: ATT) have several AS’es • Impossible for inter-domain routing across multipleorganizations • Inter-domain TE has to be connectionless

26. Traffic Engineering w/o Signaling? • Fine-grained Traffic Engineering needs some form of source routing • Specific incremental changes much easier with source routing • Change a single city-pair flow • Reacting to a link failure • Can we do source-routing efficiently in connectionless protocols?

27. Seattle 5 New York (Egress) 4 4 18 IP 27 3 10 San Francisco (Ingress) 1 9 Miami 5 IP IP IP IP 36 27 PathId 0 Idea! • Instead of using local path identifiers (Labels in MPLS), use global path identifiers Routers have capability to compute multiple paths using map from IGP (OSPF/IS-IS)

28. Seattle 5 New York (Egress) 4 4 18 IP 27 3 10 San Francisco (Ingress) 1 9 Miami 5 IP IP IP IP 27 36 0 PathId Global Path Identifiers • Instead of using local path identifiers (Labels in MPLS), we propose the use of global path identifiers

29. IP IP PathId(i,j) PathId(1,j) Global Path Identifier j 2 k wm w2 i w1 m-1 1 Central idea: Swap global pathids instead of local labels!

30. j 2 wm w2 i w1 m-1 1 k Path suffix Global Path Identifier (contd) • Path = {i, w1, 1, w2, 2, …, wk, k, wk+1, … , wm, j} • Sequence of globally known node IDs & Link weights • Global Path ID is a hash of this sequence => locally computable without the need for signaling! • Potential hash functions: • [j, { h(1) + h(2) + …+h(k)+ … +h(m-1)} mod 2b ]: node ID sum • MD5 one-way hash, XOR, 32-bit CRC etc… • We propose the use of MD5 hashing of the subsequence of nodeIDs followed by a CRC-32 to get a 32-bit hash value • Very low collision (I.e. non-uniqueness) probability

31. PathID SuffixPathID H{k, k+1, … , m-1} H{k+1, … , m-1} j 2 wm w2 i w1 m-1 1 k Path suffix Abstract Forwarding Paradigm • Forwarding table (Eg; at Node k): • [Destination Prefix, ]  [Next-Hop, ] • [j, ]  [k+1,] • Incoming Packet Hdr: Destination address (j) & PathID = H{k, k+1, … , m-1} • Outgoing Packet Hdr: [j, PathID =H{k+1, … , m-1} ] • Longest prefix match + exact label match + label swap! • PathID mismatch => map to shortest (default) path, and set PathID = 0 • No signaling because of globally meaningful pathIDs!

32. 27 IP IP IP IP IP IP 27 36 0 0 5 PathId BANANAS TE: Explicit, Multi-Path Forwarding… • Explicit Source-Directed Routing: Not limited by the shortest path nature of IGP • Different PathIds => different next-hops (multi-paths) • No signaling required to set-up the paths • Traffic splitting is decoupled from route computation Seattle 5 New York (Egress) 4 4 18 IP 3 10 San Francisco (Ingress) 1 9 Miami 5

33. IP IP IP IP IP IP 27 27 27 0 0 5 BANANAS TE: Partial Deployment • Only “red” routers are upgraded • Link State Advertisements (LSAs) may indicate (with 1 bit) which routers are upgraded • Non-upgraded routers forward everything on the shortest path (default path): forming a “virtual hop” Seattle 5 New York (Egress) 4 4 28 IP 27 30 10 San Francisco (Ingress) 1 9 1 X 2 Miami 3 1

34. Multiplicity Paradigm • Unlike telephony, data networking can get statistical multiplexing gains from simultaneously using: • Multiple transmission modes (802.11a/b, 3G etc) • Multiple exits (USB, Firewire, Ethernet, modem) • Multiple paths (routes) • Lightweight distributed QoS on each path • Can then quickly meet the performance thresholds of high-quality multimedia apps! Phone modem USB/802.11a/b 802.11a Firewire/802.11a/b WiFi Ethernet

35. “Slow” path “Fast” path P I Eg: Multipath MPEG using Multi-band 802.11a/b Community Wireless Networks