MPLS Traffic Engineering Guide: Success & Alternatives

This page provides a wrap-up of my series on MPLS traffic engineering. Multi-Protocol Label Switching (MPLS) was created to improve packet performance in the core of networks, and it is widely used for that purpose. It has also been adapted for other use cases, and one of the most important is traffic engineering.

Success with MPLS TE
MPLS allows network engineers to optimize network resources by sending traffic across a less congested physical path, rather than the default shortest path designated by the routing protocol. This is achieved by adding a short label to each packet with specific routing instructions that direct packets from router to router, rather than allowing the routers to forward them based on next-hop lookups. The new paths can be created manually or via signaling protocols, and they help to speed traffic.

Part 1: MPLS Tunnel Set-Up
Traffic engineering can greatly improve performance in MPLS networks.  If you already have MPLS deployed in your network -- perhaps for a VPN -- MPLS traffic engineering can be very beneficial. I discuss how specific traffic paths are defined and calculated using routing attributes and protocols, the design criteria, and other design-centric questions to consider.

Part 2: MPLS Path Selection For Bandwidth Optimization
MPLS traffic engineering has three major uses. These are to optimize bandwidth by selecting an alternate path, to support a service-level agreement (SLA), or to enable fast reroute. This article discusses using label-switched paths for bandwidth optimization.

Part 3: Meeting SLAs With MPLS Traffic Routing
MPLS traffic engineering can be used to meet an SLA. Not all traffic is the same, and not all customers can get the same service. Voice and video traffic were traditionally carried over circuit-based TDM links. These applications are very delay and loss sensitive, so we must ensure that they are adequately supported on the packet-switched network.

Part 4: MPLS Fast Reroute
The most common use for MPLS traffic engineering is fast reroute. Here I explain the basics of fast reroute and how to use it to create backup and pre-configured paths in MPLS traffic engineering.

MPLS TE alternatives
MPLS traffic engineering has been around for more than a decade. Perhaps you are debating whether to use it and in which cases you should consider an alternative.

If your network is pure IP but not MPLS enabled, bringing many new control plane features into your network might be too complex. Troubleshooting, management, user training, control plane state, and data plane state can all be concerns. In addition, if your equipment doesn't support Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), and Resource Reservation Protocol (RSVP), you may need to change hardware or software.

If you already have an IP-enabled network, you may want to consider the IP fast reroute (FRR) feature. Two flavors of IP FRR include loop-free alternate (LFA) and remote LFA. You can find more information about these concepts in my article, Fast Reroute Mechanisms. Based on the topology, LFA could provide enough fast reroute capability for your primary path, and you wouldn't need MPLS. Some topologies might require remote LFA to cover failures -- the difference is, you will need to send the traffic to a node that will not send it back, resulting in a microloop.

Although you don't need Label Distribution Protocol (LDP) for MPLS traffic engineering, if you are using MPLS for a Layer 2 or Layer 3 VPN, it is better to enable it. Then if traffic engineering errors occur, LDP can also be used as backup for forwarding traffic.

Service providers may not need MPLS traffic engineering where it will only be used to protect primary paths. For example, they may have protected dense wavelength-division multiplexing (DWDM) to enable automatic protection switching in their transport systems. This provides them with sub-50-ms backup paths in the case of failure. MPLS may not be needed under these circumstances.

Another scenario is when Enhanced Interior Gateway Routing Protocol (EIGRP) is built using a mechanism similar to fast reroute, called EIGRP feasible successor (FS). In this system, all loop-free alternate paths can be either kept in the EIGRP topology database, or might be used unequally. (EIGRP is like MPLS traffic engineering in supporting unequal cost multipath.) If unequal cost multipath is not used, but a loop-free alternate path exists in the topology database, when a primary path fails, EIGRP will not send a query. It will only run a diffusing update algorithm (DUAL) to select a successor among the feasible successors and install the best path into the routing and forwarding information databases.

EIGRP FS is different from MPLS traffic engineering and other fast reroute mechanisms. The alternate topology information still must be calculated, because prefixes are not in the control or data planes. You don't need to use the IP FRR feature for EIGRP, but EIGRP FS still is slower than FRR.

Lastly, software-defined networking (SDN) and the use of OpenFlow can give us the ability to calculate topology information, because the controller has a centralized view and can download the forwarding information directly into the forwarding table. MPLS traffic engineering is hard to enable, due to lack of full topology visibility, but with SDN traffic redirection it can be easier if not necessarily faster.

Tell us about your experiences with MPLS traffic engineering. Have you had success using it? Would you recommend alternatives?