IEEE Communications Magazine • April 201178 0163-6804/11/$25.00 © 2011 IEEE

INTRODUCTION

During the 74th Internet Engineering Task Force(IETF) meeting in 2009, the 12th birthday ofmultiprotocol label switching (MPLS) [1] was cel-ebrated (counting from the formation of theIETF working group). Still in its teens, MPLShas found its way into many networks where itenables virtual private networks (VPNs), BorderGateway Protocol (BGP)-free core networks,traffic engineering, and other applications thathave made it very popular among Internet ser-vice providers (ISPs). According to Request ForComments (RFC) 5218 [3], which defines metricsand criteria for assessing the success of a proto-col or the lack thereof, MPLS can be officiallydeclared a success. The two basic metrics thatdefine success are wide deployment and the factthat a protocol meets its original design goals.According to RFC 5218, MPLS can even becalled a “wild” success as it has exceeded its orig-inal design goals and is used in places that werenot conceived when MPLS was being designed.

The foundation of the success of MPLS is itssimplicity and flexibility. The only informationMPLS adds to a packet are 20 bits worth of labelinformation, a time-to-live (TTL) field, threebits to mark a packet’s service class, and a bot-tom of stack delimiter bit.

The label, similar to an IP address, is used forforwarding a packet. Unlike an IP address,though, the label does not have any structure orformat. Also unlike an IP address, a label onlyhas local significance and changes at every hop

in the network. Relabeling a labeled packet iscalled label swapping, adding a label is calledlabel pushing, and removing a label is called labelpopping. These operations are familiar expres-sions when talking about stacks, and indeedlabels can be stacked. This is the MPLS way ofbuilding hierarchies. Together, these are theessential operations of the MPLS data plane.

Forwarding based on labels rather than IPaddresses gives little extra benefit on its own.Much of its power, and difference from IP forthat matter, stems from the way traffic is for-warded. IP follows the destination-based for-warding paradigm, which essentially means allforwarding is done based on the destinationaddress in the IP header. MPLS, however,groups IP packets into so-called forwardingequivalence classes (FECs) at the boundary ofthe MPLS domain, which means all packets thatare part of the same FEC receive the same for-warding treatment (i.e., are forwarded along thesame label switched path, LSP). Conceptually,an FEC could be anything and is not limited toinformation in the IP header, which enablesmany of the applications mentioned before.

As for the control plane, MPLS does notmandate a single control protocol — another ofMPLS’ strengths, as this translates into flexibili-ty. The choice of the control plane protocol,such as Label Distribution Protocol (LDP) [4] orResource Reservation Protocol — Traffic Engi-neering (RSVP-TE) [5], depends on many fac-tors. Some of these are network size, theparticular role MPLS is supposed to play in thenetwork, and the capabilities and applicationsthat need to be supported, just to name a few.

This is MPLS in a nutshell; and, as alreadysaid, MPLS can doubtlessly be called a success,and a good indicator of its success is that MPLShas been used for applications and in ways thatwere not foreseen when MPLS was first designed.Another good indicator of MPLS’s success is theway it has been extended to be used in otherdomains. Generalized MPLS (GMPLS) is a goodexample of this where the MPLS control plane isequipped with the means to enable forwardingbased on time slots or wavelength, something notconsidered when MPLS was designed initially.Over time MPLS has also been extended to addimportant features that make it more robust,such as fast reroute. Another success story involv-ing MPLS is the Pseudowire technology, which isused, for example, as a network convergence andmigration technology where layer 2 frames (e.g.,Ethernet) are carried over an MPLS network.And this list goes on.

ABSTRACT

Large operators have embraced multiprotocollabel switching, deploying it in their backbone net-works to enable a number of services and applica-tions such as virtual private networks to just nameone. Since the inception of the respective IETFworking group, MPLS has accumulated a numberof features and has been extended to be applicablein new contexts such as optical networks in theform of generalized MPLS. Currently, MPLS isbeing further extended to finally mature into atechnology from which to build a full-fledged pack-et transport network that fulfills a large number oftraditional transport network requirements. Havingcelebrated the early teens of MPLS in 2009, theIETF might well find itself celebrating MPLS’scoming of age with the completion of the MPLSTransport Profile (MPLS-TP). This article is ashort tutorial on what MPLS-TP is, how it cameabout, and what it promises to deliver in the future.

IETF STANDARDS UPDATE

Rolf Winter, NEC Labs Europe

The Coming of Age of MPLS

WINTER LAYOUT 3/22/11 10:42 AM Page 78

IEEE Communications Magazine • April 2011 79

With this wealth of features and its wideapplicability, one might think that MPLS isabout to go into maintenance mode in terms ofstandardization. But this is far from the truth.Currently, MPLS is further extending its reachand applicability in the form of the MPLS Trans-port Profile (MPLS-TP) [6] which is about totransform MPLS into a true packet transportnetwork (PTN) technology.

THE MPLS TRANSPORT PROFILE

The MPLS Transport Profile is a very specialIETF effort. It all started as T(ransport)-MPLSwithin the International TelecommunicationUnion — Telecommunication StandardizationSector (ITU-T) as a connection-oriented packetswitched technology for transport networks. Onlylater did it moved to the IETF, where it was rela-beled — pun intended — to MPLS-TP. The rea-son was that T-MPLS was not fully compatiblewith the currently specified IP/MPLS (in this doc-ument, we refer to the set of pre-MPLS-TP speci-fications as IP/MPLS where this distinction isrelevant; otherwise, we just use the term MPLS),and when the IETF realized this was ongoing, itcoordinated with the ITU-T and evaluated theoptions to continue this effort — either continuein the ITU-T as something that is not MPLS orbring it to the IETF, which has the design author-ity over MPLS, and develop it there. The latteroption was chosen, and it was agreed that theITU-T will reflect the changes made by the RFCs-to-be in their existing Recommendations.

Both ITU-T and IETF are quite differentworlds or schools of thought where packet-switched meets circuit-switched and quality ofservice (QoS) meets best effort, but for MPLS-TP the participants of both standards bodieswork together on its specification. This turns outto not always be easy, as sometimes these differ-ent worlds collide. Just to be able to talk to eachother requires a document that translates thetechnical terms both communities use. Whilethere are still a few lingering problems, the spec-ifications are progressing. Specific solutions arestill under discussion, but the requirements andsome of the architecture and framework docu-ments have already become RFCs.

That leaves the question of what MPLS-TPactually is. Broadly speaking, MPLS-TP is theeffort to make MPLS a technology that can beused to create a PTN as defined by the ITU-T.It is the attempt to evolve traditional transportnetwork technology (e.g., based on synchronousoptical network/synchronous digital hierarchy[SONET/SDH]) to be more packet-friendlywhile retaining the characteristics of traditionaltransport technology such as high degree ofavailability, QoS support, the operational lookand feel, among others.

The above is achieved by reusing MPLS andPseudowire mechanisms as much as possible,where necessary extending MPLS and Pseu-dowires, and, if really necessary, designing newmechanisms to meet ITU-T’s PTN requirements.This list of PTN requirements is indeed long, anda number of RFCs [7–9] specify them in differentareas such as operations, administration, and

maintenance (OAM), security, and QoS. Thisdoes not always translate to new functionality thatneeds to be added to the MPLS toolkit. As Fig. 1depicts, MPLS-TP does not even make use of thefull set of MPLS functions. It is rather a necessaryand sufficient subset of MPLS with added func-tionality where current MPLS is not up to the job(note that the figure is not complete; nor are theproportions to be interpreted as a representationof the actual amount of functionality).

In the following sections we take a closerlook at what MPLS-TP does not use or requirefrom the existing IP/MPLS toolkit, what theintersection of IP/MPLS and MPLS-TP consistsof, and finally, the new tools MPLS-TP adds tothe overall MPLS machinery.

IP/MPLS BUT NOT MPLS-TPAs already said, MPLS-TP uses only a subset ofthe currently specified IP/MPLS functionality.There are various reasons for excluding certainfunctionality. For example, penultimate hop pop-ping (PHP) is not supported as part of the trans-port profile because it would conflict with someof the OAM tools being specified. Basically, theremoval of the label at the penultimate hopremoves important information that is neededfor certain OAM mechanisms to work. For simi-lar reasons LSP merging is not permissible. Also,equal cost multipath (ECMP) is not supported asthere is a strong requirement that OAM packetsshare their fate with data packets. When ECMPis employed, this can no longer be guaranteed.

Probably the biggest difference from IP/MPLS is that the support of IP is optional for thetransport profile. In other words, even in theabsence of IP, MPLS-TP needs to be able to workproperly and provide its full functionality as speci-fied. As IP/MPLS does rely on IP in various places,this is indeed a consideration with significantimpact. But a typical transport network environ-ment indeed does not rely on the presence of IP.

The same holds for a dynamic control plane.A transport network consists of long lasting con-nections, often managed via an operation sup-port system (OSS) used to establish andconfigure paths. To retain the operational lookand feel of transport networks, this way of run-ning an MPLS-TP network must be supported.More advanced methods such as a dynamic con-

Figure 1. The “new” MPLS.

IP/MPLS

MPL

S-TP

BFD

PHP

OAM

Survivability

ECMP

LSPping

Labelmerge

Dataplane

IETF

ITU-T

Requirements

Design

WINTER LAYOUT 3/22/11 10:42 AM Page 79

IEEE Communications Magazine • April 201180

trol plane are therefore purely optional. Theserestrictions often require the extension of exist-ing mechanisms, as seen in the next section.

BOTH IP/MPLS AND MPLS-TPProbably the most important element of theintersection between IP/MPLS and MPLS-TP isthe compatibility requirement of the data plane.MPLS cannot make any modifications to theIP/MPLS data plane that would render the twoincompatible. As mentioned before, certainfunctions such as PHP were excluded from thetransport profile; however, this does not impactcompatibility with the IP/MPLS data plane. Asmentioned before, MPLS-TP is first and fore-most a necessary and sufficient subset of MPLS.

Generally, the IETF is attempting to reuse asmuch as possible from IP/MPLS and other existingtechnology for the transport profile, which is reflect-ed in the way a number of existing mechanisms areextended to fulfill the transport role. A good exam-ple is bidirectional forwarding detection (BFD).BFD is a simple failure and liveliness detection pro-tocol that is used between routers; for example,BFD is designed to detect failures much faster thannative routing mechanisms, which often operate ona timescale of seconds. The transport networkrequirements demand functions such as connectivi-ty check (CC), connectivity verification (CV), andremote defect indication (RDI), or, in other words,functions to check liveliness, verify that one end-point is connected to the expected endpoint(s), anda function to report defects to the other end. BFDis in principle capable of doing this, albeit smallmodifications are needed, and some options forBFD are not available in the transport profile. Sothe IETF decided to go with BFD to fulfill theseMPLS-TP requirements. Similarly, LSP-Ping canfulfill similar tasks and more, such as route tracing,with some tweaking. While BFD is the proactiveway of realizing these functions (i.e., in a preconfig-ured continuous way), LSP-Ping is the on-demandversion of implementing them.

Another requirement on MPLS-TP is thatOAM packets need to share their fate with regularuser traffic. That means OAM packets need totravel in-band on the forwarding path, that is, inthe data plane of the transport path (or a subpartof the transport path) to which the OAM opera-tion applies. These OAM functions also need tooperate in environments without IP and dynamiccontrol plane, as these are optional in MPLS-TP,as mentioned before. All of the requirements

above can be met by the Pseudowire associatedchannel. Unfortunately, it has only been specifiedfor Pseudowires, so the IETF generalized thismechanism to also be applicable to LSPs. ForMPLS-TP, this generic associated channel (G-ACh) [10] is a central mechanism that enablesOAM (and other control mechanisms) in transportnetwork environments. In order to make nodesaware that a packet belongs to an associated chan-nel, RFC 5586 also reserves a special label (the G-ACh label, GAL) as an exception mechanism thatidentifies packets as part of a control channel atthe bottom of the label stack. To address a node insuch an environment TTL expiry can be used:when the TTL expires, a node checks the bottomof stack label. In case it finds the GAL it willinspect the associated channel header to see whattype of OAM function needs to be performed.This process is illustrated in Fig. 2. The four nodesA, B, C and D in the figure are part of an LSP,where A and D are the Label Edge Routers. Ainserts a labeled packet into the LSP with a TTLof 2, thereby addressing the node that is two hopsaway on that LSP (node C). At node C the TTLexpires and since the GAL is present, the packet isprocessed further to examine and react on theOAM message that the packet contains.

The message from all this is clear, IP/MPLStools are not that far away from fulfilling theelaborate MPLS-TP requirements and the IETFis working busily to make them applicable forthe transport profile.

MPLS-TP BUT NOT IP/MPLSThe features IP/MPLS is missing in order tobuild a PTN that fulfills the ITU-T requirementsare mainly in the areas of OAM, network man-agement and survivability mechanisms.

When it comes to OAM, the ITU-T has a veryspecific OAM model or framework that wasbrought to the IETF [1]. This model introduces ter-minology, constructs, and a few limitations into theMPLS-TP OAM world. The most basic OAM func-tional component in this model is a maintenanceentity (ME), which is the relationship between twopoints on a transport path. OAM operations alwaysapply to an ME. The endpoints of an ME arereferred to as maintenance entity group (MEG)endpoints (MEPs), and elements located betweenthose endpoints are called MEG intermediatepoints (MIPs); the latter might or might not exist.

Although the above summary of the OAMframework is far from complete, the overall modelis rather generic, and from the above it seems tosimply introduce terminology — naming the func-tional components that participate in a certainOAM operation. But this framework comes withcertain restrictions that impact how OAM canactually be implemented. As an example, MIPs arenot allowed to initiate OAM packets on their ownwithout external triggers. This functionality isreserved for MEPs, and MIPs can only react toOAM messages that have been sent to them orsimply forward OAM messages. This seems like anartificial restriction, but it has been applied intransport networks for some time. MPLS-TP OAMsolutions need to operate within this framework.

Loss and delay measurements are examples ofmissing OAM functions in IP/MPLS, and a cur-rent draft specifies two simple protocols that

Figure 2. OAM operation using the generic alert label mechanism.

IsGAL?

A

MEP

B

MIP

C

TTL–

Process

Expires

DropNo

Yes

LSP label TTL=2GAL TTL=x

OAM message

LSP label TTL=1GAL TTL=x

OAM message

MIP

D

MEPLSP

WINTER LAYOUT 3/22/11 10:42 AM Page 80

IEEE Communications Magazine • April 2011 81

enable these measurements which are carried overthe G-ACh. As mentioned before, apart fromOAM, survivability mechanisms also need to beadded, that is, mechanisms that recover the net-work’s ability to deliver packets correctly after afailure or the severe degradation of the network’sperformance. Optical transport network equip-ment has traditionally delivered a high benchmarkin terms of reliability and the ability to recoverfrom failure and MPLS-TP needs to play in thatleague. Therefore, e.g., linear protection and ringprotection solutions for MPLS-TP are beingactively worked on. However, for many survivabili-ty solutions there are currently multiple drafts thatpropose different mechanisms and many of thesespecifications are still moving targets.

While the new additions to MPLS as part ofthe MPLS-TP effort are enabling MPLS to playa transport network role, there is nothing thatprevents many of these to be applied in anIP/MPLS environment; and one should not for-get that everything that is added as part ofMPLS-TP is still core MPLS, not a parallel tech-nology. Whatever is being standardized underthe label MPLS-TP together with IP/MPLS isthe new MPLS.

WHY MPLS-TPIn the previous sections, we have broadly coveredwhat MPLS-TP is and how it fulfills transportnetwork requirements. Before that we summa-rized how it came about. This really leaves thequestion of why one actually wants MPLS-TP.

The wish to introduce packet-oriented technol-ogy into transport networks comes from the factthat the traffic in today’s network is predominantlyIP traffic (i.e., packets). MPLS-TP promises tohandle packet-based services more efficiently thantraditional circuit-switched transport network tech-nology. As MPLS is already deployed in manycore networks today and is a connection-orientedpacket-switched technology, MPLS was the bestcandidate as a starting point for a PTN. UsingMPLS as the basis will also make interworkingwith the core network of large providers easier,and some operators are already thinking out loudabout deploying MPLS not just in their core net-work but also in the aggregation and access net-work, some of which just might be MPLS-TP.

As you go all the way up from lambdas to IProuting, at every layer you add not only functionali-ty but also cost. IP/MPLS, with all the features itprovides, is a quite costly technology; however,MPLS-TP is removing many of the costly bits suchas the reliance on IP and, with it, on IP routingprotocols and so forth. These functions are oftensimply not needed in a transport context; as such,MPLS-TP also promises many of the MPLS advan-tages at a lower price. If some of these optionalcapabilities are really needed, there is nothing thatprevents use of them, such as using GMPLS as thecontrol plane — obviously at a cost.

CONCLUSIONThis article has only scratched the surface of whatMPLS-TP really is and has probably not wellreflected the huge amount of energy behind thestandardization of MPLS-TP. Two communities,

ITU-T and IETF, busily — but not always smoothly— work on the specification of new and extensionof existing mechanisms to create a profile of MPLSthat can be used in a transport network context.While individual solutions that fulfill the long list ofrequirements are still being discussed, the generalframework of MPLS-TP has already been finished.

MPLS-TP uses a subset of the existing MPLStoolkit which represents the minimal amount offunctionality that is needed in a transport networkenvironment. As such, IP and control plane supportis not required for MPLS-TP. Central managementvia an OSS and static configuration is the basicoperational mode of MPLS-TP, which thereforeretains the look and feel of today’s transport net-works. With the features added as part of theMPLS-TP effort, it will deliver the reliability, QoSsupport, and richness of OAM mechanisms that arecharacteristics of transport technology at the sametime as it will support packet-based services moreefficiently than traditional transport networks.

Not even yet fully standardized, other forahave already discovered MPLS-TP and are look-ing into how it can be used for their purposes.For example, the Broadband Forum has startedsome early stage work on it. Also, first interop-erability tests of OAM mechanisms have beenperformed (e.g., at Isocore) by a number ofequipment vendors.

With all this energy, a broad interest in thetechnology and the promises MPLS-TP makes, itappears that MPLS-TP, just like IP/MPLS beforeit, will be a success. Once MPLS has maturedinto a technology that can be used to constructpacket transport networks, the IETF has everyreason to celebrate MPLS’ coming of age.

ACKNOWLEDGMENTRolf Winter is partly funded by Trilogy, a researchproject supported by the European Commissionunder its Seventh Framework Programme.

REFERENCES[1] MPLS Working Group, http://datatracker.ietf.org/wg/mpls/[2] E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol

Label Switching Architecture,” IETF RFC 3031, Jan. 2001.[3] D. Thaler and B. Aboba,” What Makes for a Successful

Protocol?,” IETF RFC 5218, July 2008.[4] L. Andersson, I. Minei, and B. Thomas, “LDP Specifica-

tion,” IETF RFC 5036, Oct. 2007. [5] D. Awduche et al., “RSVP-TE: Extensions to RSVP for

LSP Tunnels,” IETF RFC 3209, Dec. 2001.[6] M. Bocci et al., “A Framework for MPLS in Transport

Networks,” IETF RFC 5921, July 2010.[7] B. Niven-Jenkins et al., “Requirements of an MPLS

Transport Profile,” IETF RFC 5654, Sept. 2009.[8] M. Vigoureux, D. Ward, and M. Betts, “Requirements

for Operations, Administration, and Maintenance(OAM) in MPLS Transport Networks,” IETF RFC 5860,May 2010.

[9] K. Lam, S. Mansfield, and E. Gray, “Network Manage-ment Requirements for MPLS-based Transport Net-works,” IETF RFC 5951, Sept. 2010.

[10] M. Bocci, M. Vigoureux, and S. Bryant, “MPLS GenericAssociated Channel,” IETF RFC 5586, June 2009.

BIOGRAPHYROLF WINTER (rolf.winter@neclab.eu) is a senior researcherat NEC Laboratories Europe where he is involved in net-working research and standardization, the latter mainly inthe context of IETF, where he also chairs the LEDBAT work-ing group. He received his Ph.D. from the Freie UniversityBerlin in 2006. Currently, he is involved in the Trilogy pro-ject, where he is working in the areas of routing, resourcecontrol, and economics of the Internet of the future.

With all this energy,

and broad interest in

the technology and

the promises MPLS-

TP makes, it appears

that MPLS-TP, just

like IP/MPLS before

it, will be a success.

Once MPLS has

matured into a

technology that can

be used to construct

packet transport

networks, the IETF

has every reason to

celebrate MPLS’

coming of age.

WINTER LAYOUT 3/22/11 10:42 AM Page 81