• 05/30/2014
    8:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

MPLS Traffic Engineering Guide: Success & Alternatives

MPLS traffic engineering can improve network performance by routing data to alternate paths. When should you use this technology? We explain the pros and cons.

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?


How about for those of us new to MPLS?

Is MPLS something that one should ask about when speaking to potential service providers and CoLos?  If so, how might one ask for information without getting too invovled in the details?

Re: How about for those of us new to MPLS?

Hi AbeG,

This answer normaly deserves separate post but still I will try to give an answer here. Yes If you will choose an MPLS service, there are a lot of questions to ask to provider. Without going too much detail, I could tell that you should ask following:

- Is the MPLS service Layer 2 or Layer 3. If it is layer 2, then you need to handle your routing. It gives you more control compare to Layer3 MPLS VPN service but also you need to have trained network operators.

Layer 2 VPN since you have full control ( at least logically, transport network still belong to service provider ), you can tune your protocol timers, fast failure detection so on.
So convergence of your network might be faster since Service Provider may not want to tune aggresivelly or they may ask money for that.

On the other hand, if service is layer 3, and if you run a routing protocol or even static route , you interact with the service provider. One end of the routing protocol adjaceny is service provider anymore.

But in this case, since you do not need to control your own backbone, it is much simpler. You throw the complexity to service provider.

Which one might fit to where ?

At the edge of your network Layer 3 VPN might be choosen. Yet again, if you have skilled engineers, if you want total control of your backbone, if you don't trust entirely what service provider might do then almost in any case Layer 2 VPN should be choosen IMO.

Also you should check whether Service Provider SLAs match your need. If your network require end to end latency or tight high availability or QoS for certain traffic class , you should ask service provider SLAs for both service.

Hope to help since there might be more considerations but I tried to keep it simple and short.

Orhan Ergun

Re: How about for those of us new to MPLS?

Thanks for the follow-up.  Given the level of inhouse expertise required, it sounds like choosing between options may be a matter of organization size as well as its approach to technology. 

I assume that if their approach is to outsource, then perhaps the decision would be made for them.  This topic is complex enough that I can't imagine a given client disagreeing their IT service provider's recommendation, whatever it may be.