MPLS-TP: What’s the Big Deal?
by Robin Zak Armstrong
With as much hype as there has been recently around MPLS-TP, you would think this is some wild new thing. While I was at the MPLS2009 conference, I would have to say that at least 40% of the speaking sessions were dedicated to this topic. If you’re a “net-head”, you might be wondering – what is so special about this technology? If you are a “circuit-head”, you might see something new and innovative. This article is the first in a series on MPLS-TP which will focus on what it is, why it might be useful. Upcoming articles will focus on OAM aspects and how it works.
Why MPLS-TP?
One of the main driving forces behind MPLS-TP is the bandwidth growth from new applications and services like IPTV, Mobile data, and triple play. As providers struggle to beef up their bandwidth in the access and aggregation networks to support these applications, they are also trying to optimize and converge their networks to provide flexible data rates and lower cost through statistical multiplexing.
“Multi-Protocol Label Switching (MPLS) is a maturing packet technology and it is already playing an important role in transport networks and services. However, not all of MPLS’s capabilities and mechanisms are needed and/or consistent with transport network operations. There are also transport technology characteristics that are not currently reflected in MPLS. Therefore, there is the need to define an MPLS Transport Profile (MPLS-TP) that supports the capabilities and functionalities needed for packet-transport network services and operations through combining the packet experience of MPLS with the operational experience and practices of existing transport networks.” (RFC 5654)
If you look at a typical transport network such as SONET or OTN, most if not all connections are manually provisioned via a centralized management system. But recognizing the inflexibility of SONET, the focus is now on providing a packet-based transport mechanism over the optical network while retaining all the benefits of the circuit-based network.
The discussion of the circuit vs. packet network has been going on for decades. Circuits are great when you have applications that are point-to-point with a fixed bandwidth and strict delay/jitter requirements. I don’t know the latest numbers, but the vast majority of traffic these days is bursty, time insensitive traffic which is best suited for a packet technology that can provide bandwidth-on-demand. So the next question is: what kind of packets?
Some say Ethernet is the way to go, since it is prolific in the customer, access, and aggregation networks. The problem with Ethernet is that it doesn’t operate in a connection-oriented way. There is work being done to make Ethernet connection-oriented and PBB-TE is the primary technology in this area. When Nortel was still in existence, this approach gained some traction amongst service providers, but now the momentum behind this approach seems to have slowed dramatically.
The other approach is to extend MPLS out from the packet core into the Aggregation and Access networks. Since MPLS is already in the core, there is no need to change packet formats or technologies when going from the access/aggregation networks. However, the transport functions need to be addressed. MPLS-TP addresses the need for high-bandwidth packet services, along with in-band OAM, NMS-based provisioning, deterministic path protection with fast recovery time, and best of all it is standard based on joint work between ITU-T and IETF.
What is MPLS-TP?
MPLS Transport Profile is a subset of traditional MPLS capabilities that is geared toward providing typical transport-type functions such as:
Connection-oriented technology with traffic-engineering capabilities that allow deterministic control of the use of network resources. (nothing new here)
Unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths. (something new here)
Physical separation of the control and management planes from the data plane. That is, it must be possible to operate the control and management planes out-of-band. (definitely something new here)
Static provisioning of transport paths via the management plane. (not so new in concept, but a different way to implement)
The basic idea is to “dumb down” MPLS so that it doesn’t have to use a control plane and is not based on IP, and so it looks/behaves a lot more like a TDM network without the limitations of TDM. But we need to add a few things in the way of OAM, resilience, and provisioning.
If you look at RFC 5654, it lists 115 requirements to date in various categories such as:
General/Layering (1-35)
Data Plane (36-46)
Control Plane (47-55)
Recovery (56-109)
QoS (110-115)
It is evident that the bulk of the RFC is spent in identifying recovery requirements for the data plane and control plane. It identifies 1+1, 1:n protection in the dataplane for unidirectional and bidirectional traffic, and for P2P and P2MP LSPs. There are a few requirements for recovery of a control plane (which is optional), and a bunch of requirements for recovery based on topology. These types of features will enable MPLS-TP to behave more like a circuit network.
So in a nutshell, MPLS-TP looks alot like regular MPLS in the data plane: same 32 bit header, same 20 bit label. The differences are mainly in the control plane, management, and OAM.
Conclusion
With the transport evolution migrating toward packets, MPLS-TP is in a key position to enable bandwidth growth and optimization while meeting the strict requirements of the traditional transport network in terms of resiliency, management, provisioning and quality of service. All this while providing common functionality with the core network. This one looks like a winner! Stay tuned for the next article covering MPLS-TP OAM.
Copyright 2009 Exzaktec – All Rights Reserved
