1. Internet Traffic Engineering Using Multi-Protocol Label Switching (MPLS)D.O. Awduche and B. JabbariGeneralized Multi-Protocol Label Switching: An Overview of Signaling Enhancements and Recovery TechniquesA. Banerjee et. al. Internet Traffic Engineering Joachim Seilfaldet (joachse) Jonas Sæther Markussen (jonassm)

2. Multiprotocol Label Switching Jonas Sæther Markussen

3. Agenda Multi-Protocol Label Switching Overview Labels Label assignment Forward equivalence classes (FECs) Label switched forwarding (LSP) Control and data separation Generalized Multi-Protocol Label Switching Traffic Engineering Traffic Engineering using MPLS

4. Overview (1) Multiprotocol Label Switching Architecture (RFC3031) Overlay link network (OSI layer “2.5”) Eliminates the dependence on a specific link layer technology (e.g. ATM, SONET, etc.) Eliminates the need for multiple layer 2 networks to support multiple protocols MPLS can carry many different kinds of traffic: IP, ATM, SONET, Ethernet frames, etc. Constraint-based forwarding (Optional) assignment of labels prefixing packet headers Forwarding no longer constricted to packet destination only

5. Overview (2) Introduces connection-oriented routing to legacy IP routers Does this by establishing “virtual links” using label switched paths (LSPs) Provides means for traffic engineering (TE) Can manipulate link-state advertisements (LSAs) An easy-to-maintain virtual topology With TE, MPLS can establish alternative paths to avoid congested areas Enables fault tolerance if a link goes down

6. Labels MPLS introduces labels Originally called “tags” in earlier works by Cisco and others Fixed-size header 20-bit Label Value 3-bit Traffic Class (QoS priority and ECN) 1-bit Bottom-of-Stack flag 8-bit Time-to-Live Unlike ATM and frame relay, labels can be stacked Allowing hierarchical arrangement of frames Labels are prefixed to IP headers and to each other Enables fast look-ups (more on this later)

7. Label assignment (1) Packets enter a MPLS domain through an ingress node and leaves through an egress node These are typically label edge routers (LERs) Ingress nodes assigns (pushes) to and egress nodes removes (pops) labels from packets coming in Entry node Exit node LER LER MPLS domain

8. Label assignment (2) Three label operations: Push (impose, assign) Encapsulates the packet in a new MPLS layer Allows hierarchical routing Used by e.g. MPLS VPN (L3VPN) Pop (dispose, remove) Remove uppermost label When the last label is popped, the packet “leaves” the MPLS tunnel/domain Usually done by the egress router (exit node) Can be done by the preceding LSR for offloading the egress router  penultimate hop popping (PHP) Swap Simply replaces the label and forwards packet along the path associated with the new label

9. Forward equivalence classes Label assignment is based on forward equivalence classes (FECs) Packets belonging to the same FEC has the same labels FECs can be defined differently: Based on enter (ingress) nodes and exit (egress) nodes Based on service class, requiring similar QoS or packet treatment across the MPLS domain Packets belonging to the same flow Combinations of those above FECs are associated according to some policy formulation Packets belonging to the same FEC traverse through the same path (or multi-paths) This is called a label switched path (LSP)

10. Label switched forwarding (1) “Virtual links” presented to above layers in the OSI stack These are called label switched paths (LSPs) From one label edge router (LER) to another Typically the same as ingress and egress nodes Established (and tore down) by a signaling protocol (more on this later) This introduces connection-orientation in networks that originally were based on packet switching (PS)  unified data carrying for both PS and circuit-based Routers in the MPLS domain that forward both labeled packets and conventional IP packets are called label switching routers (LSRs) Label edge routers (LERs) are usually LSRs with label stacking functionality LER Link from IP perspective Phys. links Router LER LSR LSR Router LSP paths

11. Label switched forwarding (2) LSP update policy can vary: Predefined (strategic) Careful planning of the virtual topology Considerations and forecasting to traffic patterns How, when and where to activate new LSPs to address performance issues in the network Ad-hoc (tactical) Establishment and managing of LSPs to divert traffic away from congested network resources to under-utilized alternatives A “hybrid approach”: LSPs control traffic parts in some segments of network while interior gateway routing protocol metrics are used in other

12. Control and data separation (1) MPLS functionality is separated into two “planes” with different purposes The planes are decoupled and independent Clear separation of the control plane from the data plane in network switching elements Even further separation in Generalized MPLS (GMPLS) Protocol Transactions Bearer Channels From the article, Fig. 3

13. Control and data separation (2) Control plane Control protocols are software processes that communicate across node boundaries Distribute and manage: Network topology Resource availability Establish and tear down LSPs Signaling protocol Label distribution protocol (LDP) for best-effort hop-to-hop paths RSVP-TE (or CR-LDP) for traffic engineering purposes and end-to-end virtual circuits

15. Generalized Multi-Protocol Label Switching Joachim Seilfaldet

16. Agenda Multi-Protocol Label Switching Generalized Multi-Protocol Label Switching What is GMPLS? Implemented interfaces to support Enhancements to Signaling Hierarchical LSP Setup GMPLS Protection and Restoration Techniques Path Switching Line Switching Protection Mechanisms Restoration Mechanisms Traffic Engineering Traffic Engineering using MPLS

18. Control plane is logically separated from data plane.

20. Extends to support a wide range of LSP for different network devices.

21. Extensions made to IP router protocols (OSPF and IS-IS)

23. A label represent a short tag attached to packet

24. Time-Division Multiplexing Networks

25. A label represent a time slot

26. Wavelength-Switched Networks

27. A label represent a wavelength

28. Fiber-switched Networks

30. If a node recives data over this interface, it will be able to switch the recived data on a packet-by-packet basis based on the label attached.

31. Time-Division Multiplexing (TDM)

32. Will be able to multiplex or de-multiplex channels within an payload.

33. Lambda Switch Capable Interface (LSC)

34. Will be able to recognize and switch individual lambdas within the interface.

35. Fiber Switch Capable Interface (FSC)Will be able to switch the entire contents to another interface (without distinguishing lambdas, channels or packets), such as optical cross-connects (OXCs) .

37. For example, SONET TDM.

38. Necessitates a separate control plane transport network.

39. GMPLS is extended to allow control plane to be physically diverse from the associated data plan.Enhancements have been made to the label distribution protocol RSVP-TE to support GMPLS.

41. Serves as a link through other LSP

43. Hierarchical LSP Setup Timeline R0 R1 S2 O3 P4 P5 P6 O7 S8 R9 R10 Path 1 Path 2 Path 3 Path 4 Resv 4 LSP4 completes Resv 3 LSP3 completes Resv 2 LSP2 completes Resv 1 LSP1 completes

46. Localization

47. Notification

49. Protection bandwidth

50. Protection capabilities

51. Establish secondary paths through network

57. Receiver discards packets from protection path

58. On failure in working path will switch to protection path A Working Path Protection Path B

60. Backup channel has been computedLink Management Protocol will localize failure. RSVP refresh message will indicate a path switchover. Both nodes make switch to backup channel. A (3) (3) Working Path Backup path (2) (1) B

64. Pre-computed paths and cached at head and end nodes.

65. May reuse nodes in original path.BOOM

67. May brake TE requirements

68. Constraints must be forwarded, for intermediate nodes to be able to do line restorationBOOM

69. Traffic Engineering Jonas Sæther Markussen

70. Agenda Multi-Protocol Label Switching Generalized Multi-Protocol Label Switching Traffic Engineering Limitations of legacy IP networks Traffic engineering in general Traffic engineering process Overlay traffic engineering Traffic Engineering using MPLS

71. Limitations of legacy IP networks (1) Routing Conventional shortest path routing protocols Packet-switching Usually link-state (OSPF or IS-IS) or distance-vector Simple and distributed Link layer dependant May even be so crude as 1:1 mapping of physical links! Routing based on simple hop-to-hop metrics Mainly calculated from bandwidth “Best effort” environment Initially, this was why it was so successful Not reliable with today’s QoS and performance demands

72. Limitations of legacy IP networks (2) Poor resource allocation Under/over-utilized paths due to shortest paths algorithms using link state metrics (usually bandwidth) as the only link weight May result in congestion even when excess capacity exists in alternative paths! Virtually no traffic measurement methods Absence of reliable data Lack of ability to produce traffic matrix

73. Traffic engineering in general (1) Aims to improve the unreliable and limited behavior of IP networks Link-metric based shortest path route computation Distributed shortest path first algorithms, e.g. Dijkstra’s Resource availability and traffic characteristics are not taken into considerations when routing traffic Not feasible to estimate traffic matrices from router interface statistics due to distributed nature of IP When congestion occurs, hard to determine which source-destination pairs contributes

74. Traffic engineering in general (2) Goal is to address issues concerning: Traffic control Resource control Measurements Different types of traffic engineering methodologies and TE classifications From the article, Fig. 5

75. Traffic engineering process Traffic engineering is an continuous process Policy formulation Guidelines for traffic management, traffic control and operation of the network Data acquisition Empirical statistics are gathered through measurement Traffic patterns, link utilization, traffic trends, packet drop statistics Mathematical models can be used where statistics are unavailable and/or in supplement Analysis and characterization Based on the workload derived from the measurement phase Performance optimization Continual and iterative process Traffic control: Manage inflow to the network and mapping of traffic to network resources Altering network topology: Adding links, increase or decrease link capacity, etc. Controlling local packet treatment: Queuing, scheduling, dropping policy, etc. Traffic engineering work cycle Policy Formulation Data Acquisition Analysis & Char. Performance Opt. From the article, Fig. 4, simplified

76. Overlay traffic engineering (1) Early works revealed that virtual connection-based abstractions with originating connection control compensated for legacy IP routing issues in dense topologies ISPs introduced virtual circuit (VC) switching technologies, i.e. ATM and frame relay, into IP infrastructure

77. Overlay traffic engineering (2) VC introduced with an overlay configuration Elements of the VC technology are placed at the core and are surrounded by regular IP routers VCs serve as point-to-point connections between routers, which routing protocols establish adjacencies  routers connected by a VC appears as neighbors in the IP routing layer IP Router ATM switch ATM switch Physical links IP Router ATM switch ATM switch Links as seen from IP perspective ATM network IP Router

78. Overlay traffic engineering (3) Many advantages of an overlay structure Decoupling of control planes for the virtual-circuit-based network and control plane of the IP network Can use conventional IETF IP protocols (OSPF, BGP, etc) Virtual circuits can be rerouted to move traffic away from congested resources onto under-utilized alternatives Allows the service provider to derive estimates for a traffic matrix by monitoring traffic flow over virtual circuits

79. Overlay traffic engineering (4) Disadvantages with IP over ATM and IP over frame relay Added cost of building and managing two independent networks with dissimilar technologies and different semantics The so-called O(N2) scaling problem The number of VCs grows as a function of the square of the number of routers in the network …and so does the number of adjacencies between routers

80. TRAFFIC ENGINEERING USING MPLS Jonas Sæther Markussen

81. Agenda Multi-Protocol Label Switching Generalized Multi-Protocol Label Switching Traffic Engineering Traffic Engineering using MPLS Comparison to the overlay model Protocol extensions LSP-tunnels Traffic engineering using MPLS

82. Comparison to the overlay model MPLS introduces constraint-based routing, which makes it very useful for traffic engineering (TE) Provides an overlay model in an integrated fashion on a single network element Advantages of MPLS for TE relative to the overlay model Fewer network elements Lower operating costs Greater reliability due to fewer network elements exist along the routed path Potentially less latency Simplified network architectures MPLS also supports the overlay model, giving service providers the option to deploy overlay or integrated solutions

83. Protocol extensions Requirements to MPLS in IETF RFC-2702 Effective means for MPLS to deploy and implement various TE policies Resulted in extension of legacy IP routing protocols and signaling protocols BGP (version 4, RFC4271) ISIS-TE, OSPF-TE (RFC-3630) Extended to advertise new types of capabilities and constraints associated with links RSVP-TE (RFC-3209, RFC-5151) Earlier CR-LDP was used, but was deprecated (Feb. 2003) and replaced by RSVP-TE New objects added to RSVP to support establishment & teardown of LSPs w/ behavioral attributes Can establish parameterized explicit LSPs and assign network resources to them The extensions make out the MPLS-TE control plane Requirements expanded to encompass capabilities to support Diffserv-aware traffic engineering

84. LSP-tunnels “Traffic trunks” Traffic belonging to the same class that are routed through a common path or multipath (LSP-tunnel) “LSP-tunnel” refer to both the “traffic trunk” and to the LSP it traverses TE extensions to MPLS support assignment of attributes to LSP-tunnels Bandwidth characteristics, resource affinities, resilience attributes, priority attributes, preemptive capabilities, with more Simplified establishment of LSP-tunnels Establishment is done by configuring endpoints plus desired performance and behavioral attributes at an originating LSR The LSR will employ constraint-based path computation algorithm to compute a path through the network satisfying the LSP-tunnel specifications subject to various constraints that exists within the network

85. Diffserv and MPLS (1) Two important components of resource allocation in IP networks MPLS: Global resource allocation within a given domain, constraint-based routing with bandwidth resource allocation Diffserv: Local resource allocation, “per hop behaviors” (PHB)  buffer and link resources to packets based on the Diffserv code point (DSCP) in the packet headers

86. Diffserv and MPLS (2) MPLS has basic support for Diffserv Diffserv behavior aggregates can be mapped onto LSPs Two types of LSPs support this capability, EXP-inferred-LSPs (E-LSPs) and Label-inferred-LSPs (L-LSPs) MPLS support Diffserv aware traffic engineering Derives from the fact that original MPLS-TE proposals focused on the optimization of aggregated traffic trunks, not taking to consideration the issue of preferential treatment to different types of traffic in a Diffserv environment

87. Traffic engineering using MPLS (1) Considerations Global/prevailing network constraints LSR interface attributes Local packet treatment LSP parameters and LSP paths from originating LSRs Strategic (predefined) vs. tactical (ad-hoc) LSP topology Maintainability vs. loss of efficiency Large vs. small number of LSP-tunnels Load balancing Multiple parallel LSPs with common endpoints Dynamic vs. static, open loop vs. closed loop etc

88. Traffic engineering using MPLS (2) Network survivability MPLS offers enhanced survivability capabilities Different types of protection, restoration and local repair schemes Backup LSP-tunnels and explicit LSP routes Measurement considerations Monitor Routes traversed by each LSP in the network Bandwidth requirements of each LSP Dynamics of LSPs in the network In Diffserv environments, it is desirable to measure the dealy along an LSP under different conditions