Ethernet equipment

MPLS-TP Delays Keep T-MPLS Alive

Vendors are lobbying hard to get momentum for the MPLS-TP protocol before T-MPLS, which is supposed to become obsolete, gets too comfortable in its market foothold.

The industry does seem to be agreeing on MPLS-TP as a means of Carrier Ethernet operations, administration, and maintenance (OAM), so it's not like there's a major standards war brewing. But the MPLS-TP standard remains incomplete. In the meantime, carriers including China Mobile Communications Corp. and NTT Communications Corp. (NYSE: NTT) -- not insubstantial names -- have already deployed T-MPLS, because it was closer to standardization.

So, some vendors already know they'll support both protocols for quite a while. And while they're confident the MPLS-TP standard can be completed soon, any further delays could create the chance for T-MPLS's roots to dig deeper.

"Some people are worried that the IETF is going to take a long time. Meantime, the Ethernet deployments in networks continue to get installed, and there's no OAM [operations, administration, and maintenance] effort that's been standardized," says Eve Griliches, an analyst with ACG Research .

MPLS-TP won industry favor partly because it's compatible with Multiprotocol Label Switching (MPLS), while T-MPLS isn't. MPLS-TP is especially favored among vendors that most strongly preach the packet gospel, such as Cisco Systems Inc. (Nasdaq: CSCO).

Even though the T-MPLS standard was near completion, the International Telecommunication Union (ITU) halted that effort in 2008, joining forces with the Internet Engineering Task Force (IETF) to work on MPLS-TP. (See Transport MPLS Gets a Makeover.)

Now, it's a matter of waiting.

"We believe by the middle of next year, MPLS-TP will be standardized," says Rajesh Rajamani, a product marketing manager at Spirent Communications plc . Other vendors, including Ericsson AB (Nasdaq: ERIC), are hoping the standard can be sealed late this year.

The path to a single standard is "not as easy as we thought in the beginning, but the reasons are still there," says Alberto Valsecchi, a vice president of marketing with Alcatel-Lucent.

But AlcaLu, with its Synchronous Digital Hierarchy (SDH) heritage, might be less stressed out about the process, because it's got less to lose if T-MPLS perseveres. AlcaLu has pledged to support MPLS-TP, but it's got many customers that still want to speak TDM's language of determinism and 50-millisecond restoration.

"These types of concepts are in their minds as things to take into account when building a transport network. Whether we say Cisco or Alcatel-Lucent, they will go for a solution they consider safe for the network," Alberto Valsecchi, a vice president of marketing with Alcatel-Lucent. "There are other people coming from a different background who want an MPLS-based network."

There's been evidence that Asian carriers in the T-MPLS camp are open-minded toward MPLS-TP. Rajamani cites NTT as an example: "They deployed [T-MPLS] because it was the only standard at the time. But even they are moving to MPLS-TP," he says. (See Asia/Pacific Warms to MPLS-TP.)

Other vendors, such as Cisco, talk about MPLS-TP as if it's already vanquished T-MPLS. "We've talked for a long time about the migration of TDM to packet. Architectural decisions are now being truly taken to do that," says Mike Capuano, director of service provider marketing at Cisco.

By the way, Provider Backbone Bridging - Traffic Engineering (PBB-TE) still exists as an option, but it's fallen out of the debate. AlcaLu's take, probably shared by many, is that there's nothing wrong with PBB-TE, but few, if any, carriers are really asking for it.

MPLS-TP will be the subject of its own panel session at Ethernet Expo Americas 2010 at noon on Wednesday, Nov. 3.

— Craig Matsumoto, West Coast Editor, Light Reading

Interested in learning more on this topic? Then come to Ethernet Expo Americas 2010, Light Reading's eleventh Ethernet event, designed to meet the information needs of service providers and enterprises that are working out what next-generation services and applications to deploy, and what infrastructures will help them do this in the most cost-effective and productive manner. To be staged in New York, Nov. 2 & 3, admission is free for attendees meeting our prequalification criteria. For more information, or to register, click here.

Page 1 / 2   >   >>
Pete Baldwin 12/5/2012 | 4:19:49 PM
re: MPLS-TP Delays Keep T-MPLS Alive

The MPLS-TP camp makes a strong case that the carriers are ready to move to MPLS-TP.  But the standard has been so slow (Wasn't it supposed to be done in 2009? Or am I misremembering that part?)

I don't think there's a real danger of T-MPLS becoming the de facto standard. My point here is that the T-MPLS that exists could get more "permanent" as the MPLS-TP wait drags on.

As for PBB-TE -- For the places it's been deployed, it won't be going away, will it? I've heard anecdotally that a couple of carriers really love it.

Sterling Perrin 12/5/2012 | 4:19:49 PM
re: MPLS-TP Delays Keep T-MPLS Alive


One idea I heard surface at BBWF last week is that there may end up being an MPLS-TP standard with two different options for OAM to choose from. That means that there would actually be two MPLS-TP standards, but i think there are precedents for a standard that has multiple options within it. This may be the best solution to the problem, because trying to get full industry consensus on a single OAM approach may not be possible. And the alternative, as you point out, is that operators turn elsewhere instead.


Pete Baldwin 12/5/2012 | 4:19:47 PM
re: MPLS-TP Delays Keep T-MPLS Alive

Thanks Sterling - Two options might be the way to go, then.

Is that what's actually holding up MPLS-TP?  Or is it attributable to just the normally deliberate pace of a standards effort?

Pete Baldwin 12/5/2012 | 4:19:46 PM
re: MPLS-TP Delays Keep T-MPLS Alive

Interesting snippet from Ericsson, about MPLS-TP .... they say they're envisioning the need for a new element, a Transport Border Node for "stitching MPLS-TP and MPLS," if I have it right. (That's from Matthew Smith, Ericsson director of marketing for IP and broadband.)

Sounds interesting. He's saying, though, that the packet-optical equipment will likely be the first to get MPLS-TP (once the standard's done). 

SmartEdges will get MPLS-TP, too; that's the box Ericsson contributed to a recent interop demo with Cisco and others (a wide variety of Cisco gear, apparently, although Cisco wouldn't give us specifics).

tmmarvel 12/5/2012 | 4:19:44 PM
re: MPLS-TP Delays Keep T-MPLS Alive

Standard development unfortunately often is political as much as it is technical.

The perceived threat for the IETF controlling incumbent router vendors from MPLS-TP, in particular its telco management plane driven labeling option, is that this standard--once supported by the incumbent IP router makers--will allow the SPs to engineer their MPLS backbone networks with 'white box' MPLS routers that dont need to support the legacy L3 IP based signaling mechanisms for L2(.5) MPLS label assignment. (Noting here that having to rely on a specific upper layer protocol to manage a more generic lower layer violates good layering principles.)

This means that MPLS-TP LSRs, as below-L3-boxes, dont need to support the dominant IP router vendor specific IP based MPLS label management protocols, and as such dont need to be bug etc compliant with the controlling IP router makers' legacy IP/MPLS implementations; the telcos can manage the MPLS-TP labels for the semi-permanent inter-router LSPs similar to managing e.g. L1 connections through ADMs, ie, through their management plane.

The ability for SPs to use such inexpensive, white box MPLS-TP LSRs for the bulk of their core network upgrades can be seen as a threat by the traditional IP/MPLS router vendors to their dominant position in the SP routing/switching systems market.

Naturally, there needs to be (a preferably standard) way to tie the legacy IP-MPLS nested LSPs to the L2 carrier MPLS-TP LSPs, so there'll be a need for equals of Transport Border Node, though this doesnt need to be a separate hw device; this function could be handled similar to what has been done for eg IP over FR or IP to MAC translation using InARP queries or such.

photon2 12/5/2012 | 4:19:44 PM
re: MPLS-TP Delays Keep T-MPLS Alive

ACG Research seems to be following this as well, looks like they did a service provider survey on it.



Keebler 12/5/2012 | 4:19:40 PM
re: MPLS-TP Delays Keep T-MPLS Alive

Ironically, MPLS 2010 was held just last week, and the issues around MPLS-TP OAM were argued and discussed vigorously. Too bad you missed it.



tmmarvel 12/5/2012 | 4:19:39 PM
re: MPLS-TP Delays Keep T-MPLS Alive

Sure. There's been vigorous argumentation since the beginning of the transport oriented MPLS effort.

But that may exactly be the problem in the sense that what is needed is not more and more complex arguments, but instead, a simplified, layer 2 subset of MPLS, sort of FR with stacking and CoS that is just sufficient for configuring packet switched transport paths, in essence wholesale LSPs that remain statically configured until the service contract would be changed.

Obviously those layer 2 trunking LSPs and their associated service contracts, whether intra or inter organization, do not need to be changed too often, perhaps once in two years on average, and you'd better manage them in a provision once and leave alone manner, as is done for other wholesale network connectivity contracts, incl. PDH, SDH, WDM, fiber.

The complexities of dynamic IP control plane just is not justified for these transport oriented MPLS services.

Of course, the MPLS-TP layer 2 transport LSPs naturally will still transparently pass through any client layer control plane signaling from client edge to client edge, but these dumber, but less costly and more reliable, MPLS-TP trunks should not get involved with any possible client layer signaling transactions.

elzorro 12/5/2012 | 4:19:38 PM
re: MPLS-TP Delays Keep T-MPLS Alive

There was recent interoperability testing of standards-based MPLS-TP according to ISOCORE press release:

Isocore Undertakes First-Ever Public Interoperability Testing of Resilient Standards-based MPLS-TP (MPLS Transport Profile)


Looks pretty comprehensive as it references key OAM components, protection and interworking with IP/MPLS.   Unfortunately, the press release doesn't reveal more details and report doesn't seem to be public.  However, the list of vendors is significant (Cisco, Ericsson, Hitachi, NEC, Ixia).

Keebler 12/5/2012 | 4:19:37 PM
re: MPLS-TP Delays Keep T-MPLS Alive

Yes, this test was part of MPLS2010 and no, the results aren't generally available since no one wants to publicize their level of compliance. However, as suggested by the press release and comment title, implementations are being put into hardware now.

Page 1 / 2   >   >>
Sign In