Trafffic Engineering 2015/16 1

Transcription

1 Traffic Engineering 2015/2016 Traffic Engineering: from ATM to MPLS Instituto Superior Técnico Trafffic Engineering 2015/16 1

2 Outline Traffic Engineering revisited Traffic optimization and traffic control From circuit switching to software defined networking MPLS: benefits and fundamentals References: Cisco, Yun Teng (UMBC) Trafffic Engineering 2015/16 2

3 Traffic Engineering Revisited Goals of Traffic Engineering To optimize the performance of a telecommunications network by dynamically analyzing, predicting and regulating the behavior of data transmitted over that network Avoid network congestion Assure Quality of Service (QoS) and contracted Service Level Agreement (SLA) Trafffic Engineering 2015/16 3

4 Traffic Engineering over IP networks Main goals of Traffic Engineering are difficult to accomplish on pure IP networks TCP/IP is based on the best effort model The distributed nature of IP networks is mostly based on a per hop behavior Delivery, QoS, jitter or delay difficult do assure on a end-to-end basis Routing decisions are taken on a per-hop behavior, difficulting end-to-end traffic optimization Trafffic Engineering 2015/16 4

5 QoS over IP networks Traditional solutions to QoS and SLA provision on IP networks IntServ Fine-grained, flow-based mechanism End to end resource reservation (through the Resource Reservation Protocol, RSVP) All routers must comply with the protocol Must return an explicit reject message if there are not enough resources to comply with the request Architecture can only be deployed on small scale networks Non scalable Heterogenous policies from different network operators further complicate the scenario Trafffic Engineering 2015/16 5

6 QoS over IP networks (cont) Traditional solutions to QoS and SLA provision on IP networks (cont) DiffServ Coarse-grained, class-based mechanism for traffic management Operates on the principle of traffic classification Each data packet is placed into a limited number of traffic classes and service is differentiated accordingly Each router on the network is configured to differentiate traffic based on its class. Each traffic class can be managed differently, ensuring preferential treatment for higher-priority traffic on the network. DiffServ does recommends a standardized set of traffic classes, but does not make strict assumptions Policing and classifying is done at the boundaries between DiffServ domains prioritizing the traffic This approach provides scalability, but does not assure QoS Once again, heterogenous policies between operators further complicate end to end QoS assurance Trafffic Engineering 2015/16 6

7 TE at the Operator Core While overall end-to-end QoS can not be assured between different operators and ASs over the Internet, several challenges remain for TE within a single network operator: Voice and video QoS must be fully assured within the network for telephone and TV commercial services When connecting two remote sites of a single client, contracted SLA must be strictly accomplished Optimization of available data paths/qos within the network mesh may require different data routes for the same destination in order to optimize available resources Pure decentralized IP routing can not accomplish this requirement Dedicated links from different clients must be isolated, and should not rely on layer 3 routing alone Think, for example, what happens if two clients share the same (private) IP addresses: these can not be used for operator routing IntServ could be applied within a single operator core in order to provide strict assured QoS, but it does not offers solutions to all challenges above. Trafffic Engineering 2015/16 7

8 Operators approach to TE First phase Dedicated circuits Derived directly from conventional telephone networks Rigid topology, low flexibility. Phased out Frame Relay Today almost deprecated (proposed in 1988) Conceived to run over ISDN circuits Over subscription model One may burst above your purchased Committed Information Rate (CIR), but in times of heavy network congestion any packets you send above the CIR will be eligible for discard by the carrier. Does not provide QoS mechanisms Legacy Trafffic Engineering 2015/16 8

9 Operators approach to TE (2) Second phase ATM (Asynchronous Transfer Mode) Cell-switching and multiplexing technology Combines the benefits of circuit switching (guaranteed capacity and constant transmission delay) with those of packet switching (flexibility and efficiency for intermittent traffic). Provides scalable bandwidth up to many gigabits per second (Gbps). Transfers information in fixed-size units called cells. Each cell consists of 53 octets, or bytes. The first 5 bytes contain cellheader information, and the remaining 48 contain the payload (user information). Small, fixed-length cells are well suited to transferring on-line streaming data (namely, voice and video traffic) Provides native QoS mechanisms Can be used to encapsulate IP packets over dedicated channels Proposed 1986, deployed 1991 While in phase-out process, still in use in legacy environments Trafffic Engineering 2015/16 9

10 Operators approach to TE (3) ATM (Asynchronous Transfer Mode) limitations Designed mainly for voice communications Poor adjustment to IP traffic Requires complex processing at the edges to transport IP packets Packet size misadjustement As IP, is based on a per-hop routing Layer 2 devices are unaware of layer 3 routing, and may provide sub-optimal data paths Switch of business from voice to data networks, and transport of data and video over data networks, reduced the role of the Integrated Service (ISDN) solutions. ATM, while still has a large installed base world wide today (2012), it is currently considered as deprecated and no new links have established in the last few years Trafffic Engineering 2015/16 10

11 Operator alternatives for TE (4) MPLS Currently the largest backbone base in many/most operators Able to encapsulate many other protocols Simple Well fitted to support end to end IP links (and L2 tunnels also) QoS support built Widely deployed Trafffic Engineering 2015/16 11

12 Basic MPLS motivation and requirements Allow core routers/networking devices to switch packets based on some simplified header Enable simpler and faster switching at the network core Native QoS provision Provide a highly scalable mechanism that was topology driven rather than flow driven Leverage hardware so that simple forwarding paradigm can be used It has evolved a long way from the original goal Hardware became better and looking up longest best match was no longer an issue MPLS offer L3 VPNs and L2 VPNs when required GMPLS enable generalization of MPLS to other data link protocols Trafffic Engineering 2015/16 12

13 MPLS essentials Work on MPLS started by IETF (Internet Engineering Task Force) on 1997 Integrates key features of Layer 2 and 3 technologies w/o limitation to a particular protocol Packets labeled and sent through network on paths rather than hop-to-hop as in IP datagrams MPLS started as an hybrid approach aimed to combine the best properties in both packet routing & circuit switching Trafffic Engineering 2015/16 13

14 MPLS and the protocol stack Multi Protocol Label Switching usually resides between Layer 2 and Layer 3 Often designated as 2.5 level layer Trafffic Engineering 2015/16 14

15 MPLS characteristics Mechanisms to manage traffic flows of various granularities (Flow Management) Is independent of Layer-2 and Layer-3 protocols Maps IP-addresses to fixed length labels Interfaces to existing routing protocols (RSVP, OSPF) Trafffic Engineering 2015/16 15

16 Labels Labels are a fundamental concept in MPLS operation Labels are the elements that provide routing decisions at the core of an MPLS network Trafffic Engineering 2015/16 16

17 Label position Trafffic Engineering 2015/16 17

18 Label distribution MPLS does not specify a single method for label distribution LDP, Label Distribution Protocol, is an IETF defined protocol described in RFC 5036, by which LSRs (Label Switching Eouters) distribute labels to support MPLS forwarding along normally routed paths. OSPF, IS-IS, BGP are needed in the netwok to provide reachability Trafffic Engineering 2015/16 18

19 MPLS routers Label Edge Router - LER Resides at the edge of an MPLS network and assigns and removes the labels from the packets. Support multiple ports connected to several client networks (usually IP, but can be ethernet, ATM...) Label Switching Router - LSR Is a high speed router in the core on an MPLS network. Trafffic Engineering 2015/16 19

20 LER and LSR router position LSP - Label-switched path Edge routers (LER) insert / remove MPLS labels Core routers (LSR) just switch labels and forward packets Trafffic Engineering 2015/16 20

21 MPLS overall diagram Source: Cisco Goal: Create new services via flexible classification Provide the ability to setup bandwidth guaranteed paths Trafffic Engineering 2015/16 21

22 MPLS basic operation Source: Cisco Trafffic Engineering 2015/16 22

23 FEC and LSP Forwarding Equivalence Class (FEC) Is a representation of a group of packets that share the same requirements for their transport. The assignment of a particular packet to a particular FEC is done just once (when the packet enters the network). Label-Switched Path (LSP) A path is established before the data transmission starts. A path is a representation of a FEC Trafffic Engineering 2015/16 23

24 LSP details MPLS provides two options to set up an LSP Hop-by-hop routing: Each LSR independently selects the next hop for a given FEC. LSRs support any available routing protocols (OSPF, ATM?). Explicit routing Is similar to source routing. The ingress LSR specifies the list of nodes through which the packet traverses. The LSP setup for an FEC is unidirectional. The return traffic must take another LSP / may use a different route. Trafffic Engineering 2015/16 24

25 Label Distribution Protocol An application layer protocol for the distribution of label binding information to LSRs. It is used to map FECs to labels, which, in turn, create LSPs. LDP sessions are established between LDP peers in the MPLS network (not necessarily adjacent). Sometimes employs OSPF or BGP. Trafffic Engineering 2015/16 25

26 LDP messages LDP message types: discovery messages - announce and maintain the presence of an LSR in a network session messages - establish, maintain, and terminate sessions between LDP peers advertisement messages - create, change, and delete label mappings for FECs notification ages - provide advisory information and signal error information Trafffic Engineering 2015/16 26

27 Traffic Engimeering with MPLS In MPLS, traffic engineering is inherently provided using explicitly routed paths. The LSPs are created independently, specifying different paths that are based on user-defined policies. However, this may require extensive operator intervention. RSVP-TE and CR-LDP are two possible approaches to supply dynamic traffic engineering and QoS in MPLS. Trafffic Engineering 2015/16 27

28 RSVP-TE and CR-LDP Resource Reservation Protocol - Traffic Engineering Request bandwidth and traffic conditions on a defined path. Drawback: Requires regular refreshes, Scalability Constraint-based Routing Label Distribution Protocol Deprecated Trafffic Engineering 2015/16 28

29 MPLS operation The following steps must be taken for a data packet to travel through an MPLS domain label creation and distribution table creation at each router label-switched path creation label insertion/table lookup packet forwarding Trafffic Engineering 2015/16 29

30 Label création & distribution Before any traffic begins the routers make the decision to bind a label to a specific FEC and build their tables. In LDP, downstream routers initiate the distribution of labels and the label/fec binding. In addition, traffic-related characteristics and MPLS capabilities are negotiated using LDP. A reliable and ordered transport protocol should be used for the signaling protocol Trafffic Engineering 2015/16 30

31 Table creation On receipt of label bindings, each LSR creates entries in the label information base (LIB). The contents of the table will specify the mapping between a label and an FEC. mapping between the input port and input label table to the output port and output label table. The entries are updated whenever renegotiation of the label bindings occurs. Trafffic Engineering 2015/16 31

32 Example of LIB Table Input port Incoming Port Label Output Port Outgoing Port Label Trafffic Engineering 2015/16 32

33 MPLS: Routing Information Trafffic Engineering 2015/16 33

34 MPLS: Assigning Labels Trafffic Engineering 2015/16 34

35 MPLS: forwarding Trafffic Engineering 2015/16 35

36 MPLS VPNs Layer 2 VPNs Customer endpoints (CPE) connected via Layer 2 If it connects IP routers then peering or routing relationship is between the endpoints Multiple logical connections (one with each endpoint) Layer 3 VPNs Customer end points peer with provider routers Single peering relationship No mesh of connections Provider network responsible for Distributing routing information to VPN sites Separation of routing tables from one VPN to another Trafffic Engineering 2015/16 36

37 Service provider benefits: isolating clients Trafffic Engineering 2015/16 37

38 Using labels to Build an IP VPN Trafffic Engineering 2015/16 38

39 Example: Label switching Trafffic Engineering 2015/16 39

40 Example: Label switching (description) 1. IP Echo Request packets leave A1 with the destination A2. 2. The node E2 classifies the incoming packets and maps them to an equivalence class; then it adds label 1000 and forwards the packets to E3. 3. E3 does label switching, from 1000 to 1001 and forwards the packet to E4. 4. E4 discards label 1001 and routes the packet to A2. 5. A2 replies with an IP Echo Reply 6. The node E4 is now an ingress node and classifies the packet, and then adds label The node E3 does label switching, from 2000 to 2001 and forwards the packet to E2. 8. The node E2 discards the label and routes the packet to A1. Trafffic Engineering 2015/16 40

41 Per-interface labelspace Trafffic Engineering 2015/16 41

42 Per-interface labelspace (description) 1. IP Echo Request packets leave A1 with the destination A2. 2. The node E2 classifies the incoming packets and maps them to an equivalence class; then it adds label 1000 and forwards the packets to E3. 3. E3 does label switching, from 1000 to 1000 and forwards the packet to E4. This also shows that the input label can be the same as the output label. 4. E4 discards label 1000 and routes the packet to A2. 5. A2 replies with an IP Echo Reply 6. The node E4 is now an ingress node and classifies the packet, and then adds label The node E3 does label switching, from 1000 to 1000 and forwards the packet to E2. E3 can distinguish between the two identical labels (label 1000 and the label 1000 switched in step 3) because the two labels belong to two different labelspaces. 8. The node E2 discards the label and routes the packet to A1. Trafffic Engineering 2015/16 42

43 Tunnels Trafffic Engineering 2015/16 43

44 Tunnels (description) 1. IP Echo Request packets leave A1 with the destination A3. 2. The node E2 classifies the incoming packets and maps them to an equivalence class; then it adds label 100 and forwards the packets to E5. 3. E5 switches the label to 200 and then adds another label (2000). This way E5 creates a tunnel ending to communicate directly with the other end (E3). This tunnel can be quite long and can contain other tunnels. Administrativelly speaking, E5 is directly connected to E3, although the connection is done through a MPLS tunnel. 4. E4 switches the top label without touching the other label (this can be seen by examining TTL values in the MPLS packet). 5. E3 pops the top label and switches the remaining label. 6. E1 pops the last label and routes the packet to the destination. 7. The destination A3 replies with an Echo Reply 8. E1 adds a MPLS label and forwards the packet to a different path. This suggest that the LSP are one-way and can go through different nodes. This idea is verry important when studying Traffic Engineering with MPLS. 9. E2 pops the last label and routes the packet Fernando to itsm. destination Silva (A1). Trafffic Engineering 2015/16 44

45 Label merging Merge 2 incoming labels into the same outgoing label Trafffic Engineering 2015/16 45

46 Label Merging (description) 1. IP Echo Request packets leave A1 and A2 with the destination A3. 2. Node E2 adds label 1001 and forwards the packet to E3. Node E4 adds label 1002 and forwards the packet to E3. 3. Node E3 does label switching by merging the incoming labels into the same outgoing label because both labels have the same destination. Packets from both IP flows will have the same label (2000). 4. E1 pops label 2000 and routes the packets to A3. 5. A3 replies with IP Echo Reply packets to both sources. 6. Node E1 is an ingress node and classifies the packets, adding labels 3001 and 3002 (in this case, the destinations are different). 7. Node E3 does label switching, separating the two return flows. 8. Egress nodes pop the label and route the packets to A1 and A2. Trafffic Engineering 2015/16 46

47 QoS QoS can be provided in the MPLS network by the label or Traffic Class field (old EXP field) (3 bits, 8 classes) Diffserv can result from DSCP to Label mapping or DSCP to Traffic Class field mapping Since IP Diffserve (DSCP field) has 6 bits (64 classes), Cisco and other on vendors usually map the most significant bits off the DSCP field on the Traffic Class field On the following, Traffic Class will be named as EXP. Trafffic Engineering 2015/16 47

48 QoS Trafffic Engineering 2015/16 48

49 QoS (description) 1. A1 sends two video flows over UDP to A2, using two different ports. The flows are marked with DSCP for AF31 and EF. 2. Node E2 classifies the packets into equivallence classes. Then, it adds the output label and maps DSCP to Traffic Class, by copying the most segnificant 3 bits to Traffic Class. This way, AF31 packets will receive EXP=3 and EF packets will receive EXP=5. The MPLS nodes will give a higher priority to EXP=5 traffic, but will not starve EXP=3 traffic 3. Node E3 switches labels and discards excess traffic (although in this case, E2 discards excess traffic, because there is the bottleneck). The excess traffic is mostly marked with EXP=3. 4. Node E4 pops the label and routes the packets to their destination. Trafffic Engineering 2015/16 49

50 Fast Reroute Trafffic Engineering 2015/16 50

51 Fast Reroute (description) 1. IP Echo Request packets leave from A2 with the destination A3. 2. Node E4 classifies the incoming packets and maps them to a FEC; then it adds label 100 and forwards them to E5. Node E4 has detected that Link6 is down and has deleted the LSP going through Link6, replacing it with the LSP through E5. 3. Node E5 receives label 100 and adds another label, with the value E2 pops the top label (with the value 10000) and forwards the packet to E3. 5. E3 switches label 100 to 200 (even if the packet arrives on eth0 instead of eth1) and forwards the packet to E1. Using the labels in this way simplifies the management of labels in the core nodes. 6. E1 routes the packet to A3 after popping the label. 7. A3 responds with an IP Echo Reply. Trafffic Engineering 2015/16 51

52 Fast Reroute (description - cont) 8. E1 is the ingress node and adds label E3 switches 500 to 600 and forwards the packet to E2 because it has detected that Link6 is still down. 10. E2 adds another label onto the label stack, with the value E5 pops the top label and forwards the packet with the label E4 receives the label 600 and pops it, and then routes the packet to A2. In this case, you can see that the TTL has the value 59. Trafffic Engineering 2015/16 52

53 Load Balancing Trafffic Engineering 2015/16 53

54 Load Balancing (description) 1. UDP packets leave from A1 to A2 marked with the DSCP value Node E2 classifies the incoming packets intro FECs based on DSCP value and adds label 1000, forwarding them to E3. 3. Node E3 receives label 1000 and switches it to 1001, forwarding the packet to E4. 4. E4 pops the label and routes the packet to A2. 5. UDP packets leave from A1 to A2 marked with DSCP value Node E2 is an ingress node and classifies the packet based on DSCP, adding label Node E5 receives the packet with label 2000 and switches it to 2001, forwarding the packet to E4. 8. Node E4 pops the label and routes the packet to A2. Trafffic Engineering 2015/16 54

55 Avoid congestion control by path diversity Trafffic Engineering 2015/16 55

56 Congestion control (description) 1. A3 sends two video flows marked with DSCP=0x1A (AF31) and DSCP=0x1E (AF33) to host A2. 2. Because together, the two flows exceed the maximum bandwidth available, they are split by E1. One flow (marked with AF31) will continue to use the path E1-E3-E4 and the second one will take the path E1-E2-E5-E4. By travelling separatelly, they have enough bandwidth. 3. At the destination, the two flows have a combined bandwidth greater than the maximum allowed bandwidth. Trafffic Engineering 2015/16 56

57 Layer 2 VPN Trafffic Engineering 2015/16 57

58 Layer 2 VPN (description) 1. A1 sends an ICMP Echo Request packet to A3 in the Red VPN. A2 sends an ICMP Echo Request to A4 in the Blue VPN. 2. The ingress nodes (E2 and E4) classify the packets and add a label to identify the destination VPN (100 for VPN Red and 200 for VPN Blue). Then, another label is added, to be used only for switching. Note that these labels are added without stripping the layer 2 information. 3. Node E3 does label switching, and aggregates the two flows, because they go to the same destination (E1). 4. E1 pops the top label and reads the second label. If this label is 100, then the packet will be forwarded through eth1, but if the label is 200, the packet will be forwarded through eth0. E1 does not do a routing table lookup, because the MPLS payload is no longer IP, but is layer The destinations respond with Echo Reply packets Trafffic Engineering 2015/16 58

59 Layer 2 VPN (description 2) 6. E1 knows that if it receives packet coming through eth1, they belong to VPN Red and will receive label 100 plus a switching label. The same is true for the Blue VPN. The switching labels in this case are different, because the packets have different destinations. 7. Node E3 switches the top label without analizing other information. 8. The output nodes remove the top label, and based on the bottom label decide what interface to use for forwarding the packet. Trafffic Engineering 2015/16 59

60 Layer 3 VPN Trafffic Engineering 2015/16 60

61 Layer 3 VPN (description) 1. A1 sends an ICMP Echo Request packet to A3 in the Red VPN. A2 sends an ICMP Echo Request to A4 in the Blue VPN. 2. The ingress nodes (E2 and E4) classify the packets and add a label to identify the destination VPN (100 for VPN Red and 200 for VPN Blue). Then, another label is added, to be used only for switching. 3. Node E3 does label switching, and aggregates the two flows, because they go to the same destination (E1). 4. E1 pops the top label and reads the second label. If this label is 100, then the routing table 1 will be consulted, but if the label is 200 then routing table 2 will be consulted. 5. The destinations respond with Echo Reply packets 6. E1 knows that if it receives packets coming through eth1, it will need to consult routing table 1 to see what to do with them. The same is true for the Blue VPN. The switching labels in this case are different, because the packets have different destinations. 7. Node E3 switches the top label without analizing other information. 8. The output nodes remove the top label, and based on the bottom label decide what routing table to consult, to choose a specific next hop and output interface. Trafffic Engineering 2015/16 61

62 Layer 3 VPN with overlapping address space Trafffic Engineering 2015/16 62

63 Layer 3 VPN with overlapping address space (description) 1. A1 sends an ICMP Echo Request packet to A3 in the Red VPN. A2 sends an ICMP Echo Request to A4 in the Blue VPN. 2. The ingress nodes (E2 and E4) classify the packets and add a label to identify the destination VPN (100 for VPN Red and 200 for VPN Blue). Then, another label is added, to be used only for switching. 3. Node E3 does label switching, and aggregates the two flows, because they go to the same destination (E1). 4. E1 pops the top label and reads the second label. If this label is 100, then the routing table 1 will be consulted, but if the label is 200 then routing table 2 will be consulted. 5. The destinations respond with Echo Reply packets. 6. E1 knows that if it receives packets coming through eth1, it will need to consult routing table 1 to see what to do with them. The same is true for the Blue VPN. The switching labels in this case are different, because the packets have different destinations. 7. Node E3 switches the top label without analizing other information. 8. The output nodes remove the top label, and based on the bottom label decide what routing table to consult, to choose a specific next hop and output interface. Trafffic Engineering 2015/16 63