Tip

MPLS and MPLS Transport Profile (MPLS-TP): The technology differences

If you were configuring routers in the early 1990s, you remember that they had to support about 10 different internetworking protocols. Most of them have gone the way of the dinosaur, and almost all data communications now

    Requires Free Membership to View

use the Internet Protocol (IP), which significantly reduces cost and complexity.

A decade ago, Multiprotocol Label Switching (MPLS) emerged as another unifying technology. Forwarding most packets at Layer 2, MPLS allowed service providers to build large-scale IP-based networks that supported traffic engineering, connection-oriented packet transport and virtual private networks (VPNs), features that were hard or impossible to implement with native IP. The widespread deployment of MPLS and Carrier Ethernet caused transmission price-per-bit to drop by orders of magnitude and put frame relay and asynchronous transfer mode (ATM) on the endangered technologies list.

Encouraged by the rapid uptake and enormous success of MPLS in the IP world, vendors tried to apply the same principles to transport and optical networksoptical networks. They tried to unify Synchronous Digital Hierarchy(SDH), optical transport network (OTN), and dense wave division multiplexing (DWDM), and developed Generic MPLS (GMPLS), which so far has been a failure. The mentality of transport network operators is obviously incompatible with the connectionless unpredictable self-adjusting world of IP.

Standards groups to bring Layer 2 features to MPLS-TP

In 2006, the International Telecommunication Union standardization sector (ITU-T) decided to merge the same architectural principles used in transport network technologies like SDH, SONET and OTN with MPLS. The ITU tried to recycle GMPLS into its own MPLS-like technology called Transport-MPLS (T-MPLS).

Fortunately, the ITU's development efforts were quickly stopped, and the development of MPLS Transport Profile (MPLS-TP) continues as a joint Internet Engineering Task Force (IETF)/ITU effort.

The first result of the joint effort had a list of 115 requirements that identified MPLS-TP-specific requirements in six major areas. Some of these requirements specify the mandatory or recommended use of existing MPLS technologies or components, but many require new functionality and significant reworking of existing MPLS control and management protocols (see below).

Even though MPLS-TP requires significant deviation from the traditional MPLS model and a lot of standardization work, the first requests for comments (RFCs) have just started to emerge. The expected payoffs, which include unified technology, reduced transport network complexity and associated cost reductions, have clearly excited service providers. If successful, MPLS-TP will give service providers unified network management and provisioning, and single packet switching technology they will be able to use across numerous transport networks, thus reducing the total cost of ownership.

Breaking down the differences between MPLS and MPLS-TP

When it comes to the major differences between MPLS and MPLS-TP, here's what you need to know.

  • Bidirectional Label Switched Paths (LSPs). MPLS is based on the traditional IP routing paradigm -- traffic from A to B can flow over different paths than traffic from B to A. But transport networks commonly use bidirectional circuits, and MPLS-TP also mandates the support of bidirectional LSPs (a path through an MPLS network). In addition, MPLS-TP must support point-to-multipoint paths.
  • Management plane LSP setup. Paths across MPLS networks are set up with control-plane protocols (IP routing protocols or Resource Reservation Protocol (RSVP) for MPLS Traffic Engineering (MPLS-TE). MPLS-TP could use the same path setup mechanisms as MPLS (control plane-based LSP setup) or the traditional transport network approach where the paths are configured from the central network management system (management plane LSP setup).
  • Control plane is not mandatory. Going a step farther, MPLS-TP nodes should be able to work with no control plane, with paths across the network computed solely by the network management system and downloaded into the network elements.
  • Out-of-band management. MPLS nodes usually use in-band management or at least in-band exchange of control-plane messages. MPLS-TP network elements have to support out-of-band management over a dedicated management network (similar to the way some transport networks are managed today).
  • Total separation of management/control and data plane. Data forwarding within an MPLS-TP network element must continue even if its management or control plane fails. High-end routers provide similar functionality with non-stop forwarding, but this kind of functionality was never mandatory in traditional MPLS.
  • No IP in the forwarding plane. MPLS nodes usually run IP on all interfaces because they have to support the in-band exchange of control-plane messages. MPLS-TP network elements must be able to run without IP in the forwarding plane.
  • Explicit support of ring topologies. Many transport networks use ring topologies to reduce complexity. MPLS-TP thus includes mandatory support for numerous ring-specific mechanisms.

Summing it up: The jury is out on MPLS-TP advantages

Given the attention that MPLS-TP is getting in some service provider environments and the amount of time invested in the standard development process, we will see products based on MPLS-TP in a few years. Whether MPLS-TP is a good idea is another story, however. Some of its features are definitely needed in transport networks (for example, there is currently no IP in the forwarding plane). Some MPLS-TP features are desirable, like bidirectional LSP, but others, like LSP configuration from the network management station, look like someone trying to fit a square peg in a round hole. I've heard comments that once you implement all SONET-like features in Ethernet line cards, Ethernet ports become almost as expensive as SONET ports are. MPLS-TP might face a similar fate, which would defeat the purpose, or at least part of it.

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. Check out his IOS Hints blog, and feel free to ask him your networking questions.

This was first published in November 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.