10 MPLS traffic engineering myths and half truths

Ivan Pepelnjak
10 Jun 2008

As with any complex novel technology network engineers designers and consultants tend to misunderstand some nuances of MPLS traffic engineering (MPLS TE) resulting in myths and half-truths that are propagated throughout the industry. In this article I will address some of the more common ones. The analysis is based on MPLS TE technology as described in various Internet Engineering Task Force (IETF) documents as well as the current implementation available in Cisco IOS releases 12.4T and 12.2S.

1. Myth: MPLS TE is a quality-of-service feature. While MPLS TE can be used to shift traffic from overloaded paths to alternate paths with free bandwidth it contains no inherent quality-of-service (QoS) features like guaranteed bandwidth policing or shaping. The quality-of-service features have to be designed and deployed separately on top of the MPLS TE infrastructure. The deployment of MPLS TE in a network does not (by itself) improve the quality of its services.

2. Half-truth: MPLS TE improves network convergence. The MPLS Fast Reroute functionality provides a temporary fix to a link or node failure by shifting the MPLS TE-encapsulated traffic to a preconfigured bypass (no rerouting is provided for regular IP traffic). The convergence and subsequent network topology re-optimization is still performed by the IP routing protocols.

3. Myth: MPLS TE has to be deployed throughout the network. You can use MPLS TE in tactical situations for example between a pair of routers to shift the traffic away from a congested link or to provide a fast reroute protection of a critical link in your network.

4. Half-truth: MPLS TE can solve the network congestion issues. MPLS TE does not create new bandwidth; it only allows you to use the existing bandwidth more efficiently. You can use the MPLS TE tunnels to shift the traffic from the lowest-cost path computed by IP routing protocols to an alternate less-utilized path temporarily relieving the congested link. But that action might cause the congestion of the alternate path resulting in a domino effect throughout the network.

5. Myth: Bandwidth reserved by an MPLS TE tunnel will be available to the tunneled traffic. Although the MPLS TE technology uses extensions to the Resource Reservation Protocol (RSVP) which was originally designed to provide end-to-end QoS in IP networks the MPLS TE RSVP reservations serve solely as an accounting mechanism in the MPLS TE module. This prevents link oversubscription by MPLS TE paths. MPLS TE reservations do not result in any QoS actions on the intermediate nodes. Lacking manual configuration on intermediate nodes MPLS TE traffic is treated indistinguishably from the regular IP or MPLS traffic.

6. Myth: To use MPLS TE you have to deploy MPLS in your network. MPLS TE can work without network-wide MPLS deployment. Traffic can be sent across MPLS TE tunnels without a label distribution protocol (LDP or TDP).
Note: If you're running MPLS-based Virtual Private Networks (VPNs) you have to run LDP over an MPLS TE tunnel unless it terminates at the edge of your network on a Provider Edge (PE) router.

7. Half-truth: MPLS TE only works with OSPF and IS-IS routing protocols. MPLS TE paths can be configured manually (specifying all hops in the path) and independently of the IP routing protocol deployed in the network. However if you want to have automatic path calculations and automatic rerouting of IP traffic onto MPLS TE paths you have to use OSPF or IS-IS.

8. If you use the MPLS TE Fast Reroute the quality of service will not degrade following a network failure. The MPLS TE Fast Reroute shifts MPLS TE tunnels established across a failed link or node onto preconfigured backup tunnels. The overall quality-of-service will not degrade only if:

  • These tunnels have adequate bandwidth;
  • There is enough free capacity on the backup paths
  • The quality-of-service mechanisms guarantee the bandwidth to the backup tunnels.
In all other cases either the rerouted traffic or the traffic traversing the backup path prior to node or link failure will encounter degraded quality-of-service.


No Comments Yet! Be the first to share what you think!