MPLS traffic engineering essentials

MPLS (Multi-protocol Label Switching) traffic engineering basics are presented in this tip.

This Content Component encountered an error

MPLS (Multi-protocol Label Switching) is the end result of the efforts to integrate Layer 3 switching, better known as routing, with Layer 2 WAN backbones, primarily ATM.. Even though the IP+ATM paradigm is mostly gone today because of the drastic shift to IP-only networks in the last few years, MPLS retains a number of useful features from Layer 2 technologies. One of the most notable is the ability to send packets across the network...

through a virtual circuit called Label Switched Path, or LSP, in MPLS terminology.

NOTE: While the Layer 2 virtual circuits are almost always bidirectional (although the traffic contracts in each direction can be different), the LSPs are always unidirectional. If you need bidirectional connectivity between a pair of routers, you have to establish two LSPs.

The LSPs in MPLS networks are usually established based on the contents of IP routing tables in core routers. However, there is nothing that would prevent LSPs being established and used through other means, provided that:

  • All the routers along the path agree on a common signaling protocol.
  • The router where the LSP starts (head-end router) and the router where the LSP ends (tail-end router) agree on what's traveling across the LSP.

NOTE: The other routers along the LSP do not inspect the packets traversing the LSP and are thus oblivious to their content; they just need to understand the signaling protocol that is used to establish the LSP.

With the necessary infrastructure in place, it was only a matter of time before someone would get the idea to use LSPs to implement MPLS-based traffic engineering -- and the first implementation in Cisco IOS closely followed the introduction of base MPLS (which at that time was called tag switching). The MPLS traffic engineering technology has evolved and matured significantly since then, but the concepts have not changed much since its introduction:

  • The network operator configures an MPLS traffic engineering path on the head-end router. (In Cisco's and Juniper's devices, the configuration mechanism involves a tunnel interface that represents the unidirectional MPLS TE LSP.)
  • The head-end router computes the best hop-by-hop path across the network, based on resource availability advertised by other routers. Extensions to link-state routing protocols (OSPF or IS-IS) are used to advertise resource availability.

NOTE: The first MPLS TE implementations supported only static hop-by-hop definitions. These can still be used in situations where you need a very tight hop-by-hop control over the path the MPLS TE LSP will take or in networks using a routing protocol that does not have MPLS TE extensions.

  • The head-end router requests LSP establishment using a dedicated signaling protocol. As is often the case, two protocols were designed to provide the same functionality, with Cisco and Juniper implementing RSVP-TE (RSVP extensions for traffic engineering) and Nortel/Nokia favoring CR-LDP (constraint-based routing using label distribution protocol).
  • The routers along the path accept (or reject) the MPLS TE LSP establishment request and set up the necessary internal MPLS switching infrastructure.
  • When all the routers in the path accept the LSP signaling request, the MPLS TE LSP is operational.
  • The head-end router can use MPLS TE LSP to handle special data (initial implementations only supported static routing into MPLS traffic engineering tunnels) or seamlessly integrate the new path into the link-state routing protocol.

The tight integration of MPLS traffic engineering with the IP routing protocols provides an important advantage over the traditional Layer 2 WAN networks. In the Layer 2 backbones, the operator had to establish all the virtual circuits across the backbone (using a network management platform or by configuring switched virtual circuits on edge devices), whereas the MPLS TE can automatically augment and enhance the mesh of LSPs already established based on network topology discovered by IP routing protocols. You can thus use MPLS traffic engineering as a short-term measure to relieve the temporary network congestion or as a network core optimization tool without involving the edge routers.

In recent years, MPLS traffic engineering technology (and its implementation) has grown well beyond features offered by traditional WAN networks. For example:

  • Fast reroute provides temporary bypass of network failure (be it link or node failure) comparable to SONET/SDH reroute capabilities.
  • Re-optimization allows the head-end routers to utilize resources that became available after the LSP was established.
  • Make-before-break signaling enables the head-end router to provision the optimized LSP before tearing down the already established LSP.

NOTE: Thanks to RSVP-TE functionality, the reservations on the path segments common to old and new LSP are not counted twice.

  • Automatic bandwidth adjustments measure the actual traffic sent across an MPLS TE LSP and adjust its reservations to match the actual usage.

About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting, and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html.
 

This was first published in July 2007

Dig deeper on Telecom Resources

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchDataCenter

SearchCloudComputing

SearchCloudProvider

Close