Internet Traffic Engineering


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Internet Traffic Engineering

  1. 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.<br />Internet Traffic Engineering<br />Joachim Seilfaldet (joachse)<br />Jonas Sæther Markussen (jonassm)<br />
  2. 2. Multiprotocol Label Switching<br />Jonas Sæther Markussen<br />
  3. 3. Agenda<br />Multi-Protocol Label Switching<br />Overview<br />Labels<br />Label assignment<br />Forward equivalence classes (FECs)<br />Label switched forwarding (LSP)<br />Control and data separation<br />Generalized Multi-Protocol Label Switching<br />Traffic Engineering<br />Traffic Engineering using MPLS<br />
  4. 4. Overview (1)<br />Multiprotocol Label Switching Architecture (RFC3031)<br />Overlay link network (OSI layer “2.5”)<br />Eliminates the dependence on a specific link layer technology (e.g. ATM, SONET, etc.)<br />Eliminates the need for multiple layer 2 networks to support multiple protocols<br />MPLS can carry many different kinds of traffic: IP, ATM, SONET, Ethernet frames, etc.<br />Constraint-based forwarding<br />(Optional) assignment of labels prefixing packet headers<br />Forwarding no longer constricted to packet destination only<br />
  5. 5. Overview (2)<br />Introduces connection-oriented routing to legacy IP routers<br />Does this by establishing “virtual links” using label switched paths (LSPs)<br />Provides means for traffic engineering (TE)<br />Can manipulate link-state advertisements (LSAs)<br />An easy-to-maintain virtual topology<br />With TE, MPLS can establish alternative paths to avoid congested areas<br />Enables fault tolerance if a link goes down<br />
  6. 6. Labels<br />MPLS introduces labels<br />Originally called “tags” in earlier works by Cisco and others<br />Fixed-size header<br />20-bit Label Value<br />3-bit Traffic Class (QoS priority and ECN)<br />1-bit Bottom-of-Stack flag<br />8-bit Time-to-Live<br />Unlike ATM and frame relay, labels can be stacked<br />Allowing hierarchical arrangement of frames<br />Labels are prefixed to IP headers and to each other<br />Enables fast look-ups (more on this later)<br />
  7. 7. Label assignment (1)<br />Packets enter a MPLS domain through an ingress node and leaves through an egress node<br />These are typically label edge routers (LERs)<br />Ingress nodes assigns (pushes) to and egress nodes removes (pops) labels from packets coming in<br />Entry node<br />Exit node<br />LER<br />LER<br />MPLS domain<br />
  8. 8. Label assignment (2)<br />Three label operations:<br />Push (impose, assign)<br />Encapsulates the packet in a new MPLS layer<br />Allows hierarchical routing<br />Used by e.g. MPLS VPN (L3VPN)<br />Pop (dispose, remove)<br />Remove uppermost label<br />When the last label is popped, the packet “leaves” the MPLS tunnel/domain<br />Usually done by the egress router (exit node)<br />Can be done by the preceding LSR for offloading the egress router  penultimate hop popping (PHP)<br />Swap<br />Simply replaces the label and forwards packet along the path associated with the new label<br />
  9. 9. Forward equivalence classes<br />Label assignment is based on forward equivalence classes (FECs)<br />Packets belonging to the same FEC has the same labels<br />FECs can be defined differently:<br />Based on enter (ingress) nodes and exit (egress) nodes<br />Based on service class, requiring similar QoS or packet treatment across the MPLS domain<br />Packets belonging to the same flow<br />Combinations of those above<br />FECs are associated according to some policy formulation<br />Packets belonging to the same FEC traverse through the same path (or multi-paths)<br />This is called a label switched path (LSP)<br />
  10. 10. Label switched forwarding (1)<br />“Virtual links” presented to above layers in the OSI stack<br />These are called label switched paths (LSPs)<br />From one label edge router (LER) to another<br />Typically the same as ingress and egress nodes<br />Established (and tore down) by a signaling protocol (more on this later)<br />This introduces connection-orientation in networks that originally were based on packet switching (PS)  unified data carrying for both PS and circuit-based<br />Routers in the MPLS domain that forward both labeled packets and conventional IP packets are called label switching routers (LSRs)<br />Label edge routers (LERs) are usually LSRs with label stacking functionality<br />LER<br />Link from IP perspective<br />Phys. links<br />Router<br />LER<br />LSR<br />LSR<br />Router<br />LSP paths<br />
  11. 11. Label switched forwarding (2)<br />LSP update policy can vary:<br />Predefined (strategic)<br />Careful planning of the virtual topology<br />Considerations and forecasting to traffic patterns<br />How, when and where to activate new LSPs to address performance issues in the network<br />Ad-hoc (tactical)<br />Establishment and managing of LSPs to divert traffic away from congested network resources to under-utilized alternatives<br />A “hybrid approach”: LSPs control traffic parts in some segments of network while interior gateway routing protocol metrics are used in other<br />
  12. 12. Control and data separation (1)<br />MPLS functionality is separated into two “planes” with different purposes<br />The planes are decoupled and independent<br />Clear separation of the control plane from the data plane in network switching elements<br />Even further separation in Generalized MPLS (GMPLS)<br />Protocol Transactions<br />Bearer Channels<br />From the article, Fig. 3<br />
  13. 13. Control and data separation (2)<br />Control plane<br />Control protocols are software processes that communicate across node boundaries<br />Distribute and manage:<br />Network topology<br />Resource availability<br />Establish and tear down LSPs<br />Signaling protocol<br />Label distribution protocol (LDP) for best-effort hop-to-hop paths<br />RSVP-TE (or CR-LDP) for traffic engineering purposes and end-to-end virtual circuits<br />
  14. 14. Control and data separation (3)<br /><ul><li>Forwarding plane</li></ul>Label swapping operations<br />Look-up tables<br />Packet treatment functions<br />Scheduling<br />Queue management<br />Rate shaping<br />Policing<br />Usually implemented in hardware<br />High speed operations<br />
  15. 15. Generalized Multi-Protocol Label Switching<br />Joachim Seilfaldet<br />
  16. 16. Agenda<br />Multi-Protocol Label Switching<br />Generalized Multi-Protocol Label Switching<br />What is GMPLS?<br />Implemented interfaces to support<br />Enhancements to Signaling<br />Hierarchical LSP Setup<br />GMPLS Protection and Restoration Techniques<br />Path Switching<br />Line Switching<br />Protection Mechanisms<br />Restoration Mechanisms<br />Traffic Engineering<br />Traffic Engineering using MPLS<br />
  17. 17. What is GMPLS?<br />Multi-Protocol Label Switching Recap<br /><ul><li>Works as an extension of IP
  18. 18. Control plane is logically separated from data plane.
  19. 19. Referred as a “Layer 2.5” protocol. Layer 2 (Data Link Layer) and Layer 3 (Network Layer).</li></ul>Generalized Multi-Protocol Label Switching<br /><ul><li>Next generation implementation of Multi-Protocol Label Switching
  20. 20. Extends to support a wide range of LSP for different network devices.
  21. 21. Extensions made to IP router protocols (OSPF and IS-IS)
  22. 22. New Link Management Protocol</li></li></ul><li>What is GMPLS?<br />Control plane concepts can be used in other switched transport technologies<br /><ul><li>Packet Switched Networks
  23. 23. A label represent a short tag attached to packet
  24. 24. Time-Division Multiplexing Networks
  25. 25. A label represent a time slot
  26. 26. Wavelength-Switched Networks
  27. 27. A label represent a wavelength
  28. 28. Fiber-switched Networks
  29. 29. A label represent a fiber</li></li></ul><li>Implemented interfaces to support<br /><ul><li>Packet Switch Capable Interfaces (PSC)
  30. 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. 31. Time-Division Multiplexing (TDM)
  32. 32. Will be able to multiplex or de-multiplex channels within an payload.
  33. 33. Lambda Switch Capable Interface (LSC)
  34. 34. Will be able to recognize and switch individual lambdas within the interface.
  35. 35. Fiber Switch Capable Interface (FSC)</li></ul>Will be able to switch the entire contents to another interface (without distinguishing lambdas, channels or packets), such as optical cross-connects (OXCs) .<br />
  36. 36. Enhancements to Signaling<br /><ul><li>GMPLS require LSP start and end on similar device
  37. 37. For example, SONET TDM.
  38. 38. Necessitates a separate control plane transport network.
  39. 39. GMPLS is extended to allow control plane to be physically diverse from the associated data plan.</li></ul>Enhancements have been made to the label distribution protocol RSVP-TE to support GMPLS.<br />
  40. 40. Hierarchical LSP Setup<br /><ul><li>Occurs when a new LSP is tunneled inside an existing higher-order LSP
  41. 41. Serves as a link through other LSP
  42. 42. Nodes at border of regions are responsible for forming higher-order LSP and aggregating lower-order LSPs.</li></li></ul><li>Hierarchical LSP Setup<br />Figure shows how hierarchical LSP setup is performed over different types of network types.<br />
  43. 43. Hierarchical LSP Setup<br />Timeline<br />R0<br />R1<br />S2<br />O3<br />P4<br />P5<br />P6<br />O7<br />S8<br />R9<br />R10<br />Path 1<br />Path 2<br />Path 3<br />Path 4<br />Resv 4<br />LSP4 completes<br />Resv 3<br />LSP3 completes<br />Resv 2<br />LSP2 completes<br />Resv 1<br />LSP1 completes<br />
  44. 44. GMPLS Protection and Restoration Techniques<br />Protection and restoration is addressed using two techniques<br /><ul><li>Path Switching
  45. 45. Line Switching</li></ul>Fault management consist of<br /><ul><li>Detection
  46. 46. Localization
  47. 47. Notification
  48. 48. Mitigation (Done with protection and restoration)</li></li></ul><li>Protection Mechanisms<br />Efficient use of protection requires<br /><ul><li>Distribution of relevant link properties
  49. 49. Protection bandwidth
  50. 50. Protection capabilities
  51. 51. Establish secondary paths through network
  52. 52. Signal switch from primary path to backup </li></li></ul><li>Path Switching<br />Failure is addressed at path endpoints.<br />Path protection<br /><ul><li>Protection path is pre-allocated.
  53. 53. Resources for protection path is reserved, specifically to handle traffic from path that is protected.</li></ul>Path restoration<br /><ul><li>Restoration of path needs to happen “on-the-fly” or to be pre-computed and cached at endpoints.
  54. 54. No resources are reserved in case of a failure.</li></li></ul><li>Line Switching<br />Failure is addressed at transit node, where failure is detected.<br />Span Protection<br /><ul><li>Traffic is switched to an alternate parallel channel or link connecting same two nodes.</li></ul>Line Restoration<br /><ul><li>Traffic is switched to an alternate route between two failing nodes. Passing through additional intermediate nodes.</li></li></ul><li>Protection Mechanisms<br />1+1 protection<br /><ul><li>Data transmitted simultaneously over two paths.
  55. 55. Will receive on backup path, in case of errors on working path.</li></ul>M:N protection<br /><ul><li>M pre-allocated backup paths shared between N primary path.</li></li></ul><li>Protection Mechanisms<br />1:N protection<br /><ul><li>1 pre-allocated backup path shared between N primary paths</li></ul>1:1 protection<br /><ul><li>1 dedicated backup path is assigned for each primary path</li></ul>Note: 1:N and 1:1 are just special cases of M:N<br />
  56. 56. 1+1 span protection<br /><ul><li> Transmitted simultaneously over two disjoint channels
  57. 57. Receiver discards packets from protection path
  58. 58. On failure in working path will switch to protection path </li></ul>A<br />Working Path<br />Protection Path<br />B<br />
  59. 59. 1:1 span protection<br /><ul><li>Transmitted only over primary channel
  60. 60. Backup channel has been computed</li></ul>Link Management Protocol will localize failure.<br />RSVP refresh message will indicate a path switchover.<br />Both nodes make switch to backup channel.<br />A<br />(3)<br />(3)<br />Working Path<br />Backup path<br />(2)<br />(1)<br />B<br />
  61. 61. Restoration Mechanisms<br /> Designed to..<br /><ul><li> React to failures quickly
  62. 62. Use bandwidth efficiently</li></ul>Slower than protection mechanisms<br /><ul><li>Dynamic resource establishment
  63. 63. Route calculation</li></li></ul><li>Restoration Mechanisms<br />Path restoration<br /><ul><li>Optimization can be done to speed up process.
  64. 64. Pre-computed paths and cached at head and end nodes.
  65. 65. May reuse nodes in original path.</li></ul>BOOM<br />
  66. 66. Restoration Mechanisms<br />Line restoration<br /><ul><li>Beneficial for connections that span multiple hops
  67. 67. May brake TE requirements
  68. 68. Constraints must be forwarded, for intermediate nodes to be able to do line restoration</li></ul>BOOM<br />
  69. 69. Traffic Engineering<br />Jonas Sæther Markussen<br />
  70. 70. Agenda<br />Multi-Protocol Label Switching<br />Generalized Multi-Protocol Label Switching<br />Traffic Engineering<br />Limitations of legacy IP networks<br />Traffic engineering in general<br />Traffic engineering process<br />Overlay traffic engineering<br />Traffic Engineering using MPLS<br />
  71. 71. Limitations of legacy IP networks (1) <br />Routing<br />Conventional shortest path routing protocols<br />Packet-switching<br />Usually link-state (OSPF or IS-IS) or distance-vector<br />Simple and distributed<br />Link layer dependant<br />May even be so crude as 1:1 mapping of physical links!<br />Routing based on simple hop-to-hop metrics<br />Mainly calculated from bandwidth<br />“Best effort” environment<br />Initially, this was why it was so successful<br />Not reliable with today’s QoS and performance demands<br />
  72. 72. Limitations of legacy IP networks (2) <br />Poor resource allocation<br />Under/over-utilized paths due to shortest paths algorithms using link state metrics (usually bandwidth) as the only link weight<br />May result in congestion even when excess capacity exists in alternative paths!<br />Virtually no traffic measurement methods<br />Absence of reliable data<br />Lack of ability to produce traffic matrix<br />
  73. 73. Traffic engineering in general (1)<br />Aims to improve the unreliable and limited behavior of IP networks<br />Link-metric based shortest path route computation<br />Distributed shortest path first algorithms, e.g. Dijkstra’s<br />Resource availability and traffic characteristics are not taken into considerations when routing traffic<br />Not feasible to estimate traffic matrices from router interface statistics due to distributed nature of IP<br />When congestion occurs, hard to determine which source-destination pairs contributes<br />
  74. 74. Traffic engineering in general (2)<br />Goal is to address issues concerning:<br />Traffic control<br />Resource control<br />Measurements<br />Different types of traffic engineering methodologies and TE classifications<br />From the article, Fig. 5<br />
  75. 75. Traffic engineering process<br />Traffic engineering is an continuous process<br />Policy formulation<br />Guidelines for traffic management, traffic control and operation of the network<br />Data acquisition<br />Empirical statistics are gathered through measurement<br />Traffic patterns, link utilization, traffic trends, packet drop statistics<br />Mathematical models can be used where statistics are unavailable and/or in supplement<br />Analysis and characterization<br />Based on the workload derived from the measurement phase<br />Performance optimization<br />Continual and iterative process<br />Traffic control: Manage inflow to the network and mapping of traffic to network resources<br />Altering network topology: Adding links, increase or decrease link capacity, etc.<br />Controlling local packet treatment: Queuing, scheduling, dropping policy, etc.<br />Traffic engineering work cycle<br />Policy Formulation<br />Data Acquisition<br />Analysis & Char.<br />Performance Opt.<br />From the article, Fig. 4, simplified<br />
  76. 76. Overlay traffic engineering (1)<br />Early works revealed that virtual connection-based abstractions with originating connection control compensated for legacy IP routing issues in dense topologies<br />ISPs introduced virtual circuit (VC) switching technologies, i.e. ATM and frame relay, into IP infrastructure<br />
  77. 77. Overlay traffic engineering (2)<br />VC introduced with an overlay configuration<br />Elements of the VC technology are placed at the core and are surrounded by regular IP routers<br />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<br />IP Router<br />ATM switch<br />ATM switch<br />Physical links<br />IP Router<br />ATM switch<br />ATM switch<br />Links as seen from IP perspective<br />ATM network<br />IP Router<br />
  78. 78. Overlay traffic engineering (3)<br />Many advantages of an overlay structure<br />Decoupling of control planes for the virtual-circuit-based network and control plane of the IP network<br />Can use conventional IETF IP protocols (OSPF, BGP, etc)<br />Virtual circuits can be rerouted to move traffic away from congested resources onto under-utilized alternatives<br />Allows the service provider to derive estimates for a traffic matrix by monitoring traffic flow over virtual circuits<br />
  79. 79. Overlay traffic engineering (4)<br />Disadvantages with IP over ATM and IP over frame relay<br />Added cost of building and managing two independent networks with dissimilar technologies and different semantics<br />The so-called O(N2) scaling problem<br />The number of VCs grows as a function of the square of the number of routers in the network<br />…and so does the number of adjacencies between routers<br />
  80. 80. TRAFFIC ENGINEERING USING MPLS<br />Jonas Sæther Markussen<br />
  81. 81. Agenda<br />Multi-Protocol Label Switching<br />Generalized Multi-Protocol Label Switching<br />Traffic Engineering<br />Traffic Engineering using MPLS<br />Comparison to the overlay model<br />Protocol extensions<br />LSP-tunnels<br />Traffic engineering using MPLS<br />
  82. 82. Comparison to the overlay model<br />MPLS introduces constraint-based routing, which makes it very useful for traffic engineering (TE)<br />Provides an overlay model in an integrated fashion on a single network element<br />Advantages of MPLS for TE relative to the overlay model<br />Fewer network elements<br />Lower operating costs<br />Greater reliability due to fewer network elements exist along the routed path<br />Potentially less latency<br />Simplified network architectures<br />MPLS also supports the overlay model, giving service providers the option to deploy overlay or integrated solutions<br />
  83. 83. Protocol extensions<br />Requirements to MPLS in IETF RFC-2702<br />Effective means for MPLS to deploy and implement various TE policies<br />Resulted in extension of legacy IP routing protocols and signaling protocols<br />BGP (version 4, RFC4271)<br />ISIS-TE, OSPF-TE (RFC-3630)<br />Extended to advertise new types of capabilities and constraints associated with links<br />RSVP-TE (RFC-3209, RFC-5151)<br />Earlier CR-LDP was used, but was deprecated (Feb. 2003) and replaced by RSVP-TE<br />New objects added to RSVP to support establishment & teardown of LSPs w/ behavioral attributes<br />Can establish parameterized explicit LSPs and assign network resources to them<br />The extensions make out the MPLS-TE control plane<br />Requirements expanded to encompass capabilities to support Diffserv-aware traffic engineering<br />
  84. 84. LSP-tunnels<br />“Traffic trunks”<br />Traffic belonging to the same class that are routed through a common path or multipath (LSP-tunnel)<br />“LSP-tunnel” refer to both the “traffic trunk” and to the LSP it traverses<br />TE extensions to MPLS support assignment of attributes to LSP-tunnels<br />Bandwidth characteristics, resource affinities, resilience attributes, priority attributes, preemptive capabilities, with more<br />Simplified establishment of LSP-tunnels<br />Establishment is done by configuring endpoints plus desired performance and behavioral attributes at an originating LSR<br />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<br />
  85. 85. Diffserv and MPLS (1)<br />Two important components of resource allocation in IP networks<br />MPLS: Global resource allocation within a given domain, constraint-based routing with bandwidth resource allocation<br />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<br />
  86. 86. Diffserv and MPLS (2)<br />MPLS has basic support for Diffserv<br />Diffserv behavior aggregates can be mapped onto LSPs<br />Two types of LSPs support this capability, EXP-inferred-LSPs (E-LSPs) and Label-inferred-LSPs (L-LSPs)<br />MPLS support Diffserv aware traffic engineering<br />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<br />
  87. 87. Traffic engineering using MPLS (1)<br />Considerations<br />Global/prevailing network constraints<br />LSR interface attributes<br />Local packet treatment<br />LSP parameters and LSP paths from originating LSRs<br />Strategic (predefined) vs. tactical (ad-hoc)<br />LSP topology<br />Maintainability vs. loss of efficiency<br />Large vs. small number of LSP-tunnels<br />Load balancing<br />Multiple parallel LSPs with common endpoints<br />Dynamic vs. static, open loop vs. closed loop etc<br />
  88. 88. Traffic engineering using MPLS (2)<br />Network survivability<br />MPLS offers enhanced survivability capabilities<br />Different types of protection, restoration and local repair schemes<br />Backup LSP-tunnels and explicit LSP routes<br />Measurement considerations<br />Monitor<br />Routes traversed by each LSP in the network<br />Bandwidth requirements of each LSP<br />Dynamics of LSPs in the network<br />In Diffserv environments, it is desirable to measure the dealy along an LSP under different conditions<br />