MPLS-TP: Why Can't We All Just Get Along?
At a recent ITU-T meeting some vendors are trying to bring back T-MPLS by proposing Y.1731 for MPLS OAM. Our take: this is bad for the industry. We talked to many customers who are hearing from the v ....
Blogs » Packet Optical Transport
MPLS-TP: Why Can't We All Just Get Along?, Total Views :1429
Published on Jul 16 2010 6:58PM

What the heck is going on?

Let me start with a disclaimer: I am not a standards expert, far from it. In fact, my one trip to an IETF conference was frankly, kind of painful.  So while my coverage of IP and optics occasionally involves protocol discussions and standards efforts, I rarely get too deep into either one.  But I feel this time I just have to say, "why can't we all just get along," the stakes are simply too high.

It seems as if the ITU-T and the IETF joint objective of defining a standards-based Transport Profile for MPLS has hit a political bump in the road.  Over the last two years the industry has converged on MPLS-TP as the standard as it preserves MPLS forwarding paradigm and OAM. The industry agreed to retire T-MPLS proposition because it did not interoperate with MPLS and its deployment as a “MPLS” technology was a wolf in sheep’s clothing that  would lead to parallel investment by vendors and surprise interoperability issues for service providers. We thought this one was put to bed.

However, at a recent ITU-T meeting some vendors are trying to bring back T-MPLS by proposing Y.1731 for MPLS OAM.  Our take: this is bad for the industry. We talked to many customers who are hearing from the very same vendors that using Y.1731 for their OAM equals MPLS-TP and is, therefore, compatible with MPLS. Unfortunately, this is not true and has us concerned.

The History:  A Simple Version
The IETF and ITU-T have been working together to standardize and develop a Transport Profile for MPLS called MPLS-TP.  MPLS-TP extends MPLS to include OAM (Operations, Administration and Maintenance) features that are inherent in SONET/SDH or OTN networks today.  The entire purpose is to continually add extensions where necessary to meet transport requirements to handle the growing video, LTE, triple play IP requirements, which are increasingly added to the network with little payback for the provider (but that's a separate issue, isn't it?).

T-MPLS was originally undertaken by the ITU-T and approved in 2006.  By 2008 it was tested in a couple of operator networks in China and one in Italy.  At the same time the IETF was working on PWE3 standards for packet switched networks, and, consequently, a joint working group was formed between the IETF and ITU-T to align the requirements and protocols. The working group’s goal was simple: to protect existing investments and provide interoperability on the new transport  extensions to MPLS that the original proposition didn’t necessarily consider. So far, so good? 

Well, issues do arise like the control plane; the ITU-T supports ASON and the IETF supports GMPLS.  And we have to agree on synchronization for the packet network, right now there are multiple approaches, and the encapsulation approaches must be the same for all the potential technologies.  There also has to be interoperability and backward compatibility on legacy SONET/SDH networks.  Ok, so no easy feat to agree on all of this within one group, let alone two different groups.  And, we've only started with OAM features!

But folks, the reason for writing about this at all is that the optical networking market dropped from a $14 billion market to slightly over $12 billion in the last couple of years.  We simply cannot afford to be arguing like this.  Optical vendors have been beaten up on system pricing, and demanding that components come down in price is simply not working.  It has only driven the optical component market to consolidate and slow innovation.  We're all here to make money, maybe not get rich, but stay in business. 

What the OIF has done this past year provides us an example of leadership in the industry.  The OIF suggested that portions of hardware implementations become standardized in order to increase volume for the component vendors, resulting in reduced cost for system vendors. You can still add your "special sauce."  In general, most vendors are falling in line with this efficient approach to the tough market conditions we're under right now.

What is the real story here? 

Four operators, China Mobile, China Telecom, China Unicom and Telecom Italia are in the process  of deploying the earlier T-MPLS OAM approach, which was terminated in 2008 in lieu of the ITU-T and IETF working together to standardize MPLS-TP.  And because this prestandard has been deployed regionally in China, the operators are pushing for the terminated standard to arise from the dead and become the standard of today.  Well, T-MPLS was terminated for many good reasons, and it is a terrible idea to resurrect it now. Doing so would fragment the premise of industry-wide network interoperability. While one set of vendors may want to reignite the earlier proposition for obvious reasons, others may not.

The Result
Anyway, the suggestion (from the Chinese operators) on the table at the joint ITU-T and IETF working group is to now take two separate paths to the standard, I do it my way, you do it your way kind of thing.  That would be terrible for the industry, and I am urging the vendors (you know who you are if you are helping, and you know who you are if you are creating this chaos) and the providers involved to come together and get along.  The industry simply cannot afford to stall over this right now, and service providers should put their money where their mouths are and assist in this effort for many reasons:  we don't want commodity hardware to be the composite of our telecom infrastructure 10 years from  now. 

So, I apologize for not having more technical reasons behind all of this mess, but clearly some vendors must make a change in their approach, and operators have to alert other operators in the industry that it's time to move forward efficiently, not separately.

Home|About us|Products & Services|News|Events|Analyst|Blogs
© Copyright 2010. ACG Research. All right reserved.