x
Optical/IP

MPLS-TP Could Be Headed for a Split

Analysts' hunch is that the fracas over MPLS-TP may cause the standard to split in two, just as Sonet and SDH did.

"I do think they have gotten to a point where we may end up like Sonet and SDH, where each country area settles on one type, and vendors will have to support both types," says Eve Griliches, an analyst with ACG Research .

The Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU) are working jointly on an MPLS-TP standard. But given the rancor at the standards meetings earlier this month, it doesn't look like the argument over operations, administration, and maintenance (OAM) will get settled easily. (See Rumor: T-MPLS Group Gets Shouted Down and MPLS-TP Delays Keep T-MPLS Alive.)

The IETF meeting briefly became a shouting match as supporters of Y.1731 -- an ITU standard created as part of the old T-MPLS concept -- demanded a chance to present what's called the BHH draft, which describes the use of Y.1731 for OAM in MPLS-TP.

Many at the IETF had considered the Y.1731 matter to be closed. The working group had instead favored the BFD approach, partly because of its interoperability with Multiprotocol Label Switching (MPLS). But China Mobile Communications Corp. has deployed Y.1731 already, and Telecom Italia (TIM) seems prepared to do the same.

It's the weight of those names -- along with Alcatel-Lucent (NYSE: ALU) and Huawei Technologies Co. Ltd. , whose representatives are the BHH draft's principal authors -- that make it unlikely Y.1731 will just go away, says Heavy Reading analyst Sterling Perrin.

"To me, the best outcome would be just to have two variants," Perrin says. "The group leadership just seems dead set against it. They could just all move to one standard, but that seems unlikely" and would probably result in the Y.1731 camp continuing to implement their technology even without the backing of the standard.

Separately, carriers are putting pressure on vendors to settle on a standard, so that officially standards-based equipment can be fruitful and get deployed.

"The feeling I got from Berlin [site of November's ITU meeting] is that the vendors are going to have to settle things," Griliches says.

— Craig Matsumoto, West Coast Editor, Light Reading

paolo.franzoi 12/5/2012 | 4:16:56 PM
re: MPLS-TP Could Be Headed for a Split

obaut,


Given that you are trying to talk about ethernet these are nits but I think symptomaic of the issue.


Your STS/VC cross-connects could NOT actually be done because they are going to be in separate clocking domains.  So, you would end up with a long term BER due to clock drift.  What you could do is transport VTs.


The one thing that you left out was the very low level base OAM that was available independent of SONET/SDH.  By this, I mean Yellow and Blue in repsonse to Red.


seven


 

obaut 12/5/2012 | 4:16:56 PM
re: MPLS-TP Could Be Headed for a Split

Lets recall the main point of MPLS-TP is to simplify MPLS for transport (trunking) network applications, ie to provide pure L2 label switched connectivity between endpoints of such L2 trunks, eg between IP/MPLS LERs, through a number of MPLS-TP LSRs. As such, through MPLS-TP OAM, mainly the label-switching L2 crossconnect maps and associated resource (bandwidth) reservations need to be configured for the LSRs.


Regarding the comparison of IETF vs ITU-T MPLS-TP with Belcore SONET and ITU-T SDH, note that in both SONET and SDH the L1 x-connect and resource (timeslot) management are done in some manner through management plane, allowing the data plane (ie the revenue generating actual services!) at L1 to inter-operate irrespective of different providers OAM. You can technically interconnect SONET DS3/STS-1 with SDH VC-3 between different OAM domains, and similarly for STS-3c and VC-4, STS-12c and VC-4-4c etc.


The key to this L1 inter-op, for any client traffic (ie whether L1 connections carried PDH TDM signals, ATM/FR/ETH/HDLC packets etc) is that the OAM of the L1 doesnt rely on any specific client layer protocol (eg for control plane). But (L2.5) MPLS (w/o -TP) relies on a client layer (L3) IP based signaling protocols for its OAM.


As long as L2 MPLS-TP is done in a manner that doesnt depend on any upper layer (eg control plane) protocol for its OAM, then whatever the OAM techniques used and whatever they are called, there should be a way to configure L2 MPLS-TP LSPs (again, the actual services!!!) between the end points of such L2 connection, even through heterogeneous OAM domains.


It looks like the hidden agenda among IETF's controlling vendors is to make standard MPLS-TP OAM to include their de-facto proprietary L3 IP based mechanisms for L2 MPLS label etc. configuration as mandatory features for any 'standard' MPLS-TP implementations.


But SPs should insist on the standard to allow non-L3/IP-dependent MPLS-TP OAM, to enable the realization of a market for pure L2 MPLS-TP LSRs, which can be much more cost-efficient than any boxes that have to be compatible with the dominating IP routing vendors' IP based MPLS control plane. The pure L2 MPLS-TP LSRs will also naturally allow much more cost-efficient and secure L2 MPLS services, eg wholesale or enterprise VPNs.

zauberberg 12/5/2012 | 4:16:54 PM
re: MPLS-TP Could Be Headed for a Split

Ha!  In your FACE obaut!  

photon2 12/5/2012 | 4:16:54 PM
re: MPLS-TP Could Be Headed for a Split

The issue was clear in Berlin that service providers (not vendors) are fed up with waiting on this.  Clearly frustrated with the lack of progress, something either needs to break thru or go in different directions.


P2

Huub_van_Helvoort 12/5/2012 | 4:16:53 PM
re: MPLS-TP Could Be Headed for a Split

Hello Craig,


First let me correct you on your statement "Y.1731 -- an ITU standard created as part of the old T-MPLS concept". ITU-T recommendation Y.1731 is developed to provide OAM functionality for Carrier class Etherenet. It contains OAM for Fault management, Performance monitoring and Diagnostics. Y.1731 existed before work on T-MPLS started, the OAM functionality of Y.1731 was re-used for T-MPLS OAm and now for MPLS-TP OAM andd is mainly designed for application in Packet Transport Networks (PTN).



Secondly, there may indeed be a split of the tools in the toolbox, one set for application in Packet Transport Networks (PTN) and a set for application in Packet Switched Network (PSN). The sets may even contain some common tools. And looking at the location of the  supporters  this can indeed be compared to what happened with SONET and SDH: SONET/PSN in North Amarica and SDH/PTN in the rest of the world. This split also alignes with the way OAM is used in these areas.


Huub_van_Helvoort 12/5/2012 | 4:16:52 PM
re: MPLS-TP Could Be Headed for a Split

Hi P2,


At least in Berlin the service providers were allowed to voice their opinion. In the IETF78 meeting they did not get the opportunity to present their considerations; they were shouted down. One opponent even called it a "Denial of Service" attack...


I the ITU-T SG15 june 2010 plenary meeting State Members China, Japan, Korea, Italy, Iran and Syria also voiced the same opinion.

Huub_van_Helvoort 12/5/2012 | 4:16:48 PM
re: MPLS-TP Could Be Headed for a Split

More information about the current situation can be found on the ITU-T SG15 website where you will find a presention titled "MPLS-TP Joint Development Process".


 

chechaco 12/5/2012 | 4:16:48 PM
re: MPLS-TP Could Be Headed for a Split

Dear Craig and All,


I feel that community have missed one very important change in positioning of MPLS-TP that have happened around last Spring. The change is in positioning of MPLS-TP in regard to what is foundation, profile of Packet Transport Network. The fact and agreement between SDOs (IETF and ITU) is that MPLS-TP, as specified by IETF, defines packet networks. The packet transport networks will be defined by ITU. I think that this point often missed when we discuss standardization of MPLS-TP and MPLS-TP OAM in particular. I don't think that what would be finally defined as Packet Transport requires new MPLS-based acronym but it would help if SDOs and we keep above mentioned change in perspective. Thus, in a sense, the split already happened and has been agreed by SDOs. But, at the same time, what happened is not a split but, in my view, but clarification of scope of MPLS-TP and subset(s) of functionalities.

Elton2010 12/5/2012 | 4:16:28 PM
re: MPLS-TP Could Be Headed for a Split

Dear Craig Matsumoto,


  You state that "Many at the IETF had considered the Y.1731 matter to be closed. The working group had instead favored the BFD approach, partly because of its interoperability with Multiprotocol Label Switching (MPLS)."


 If you read draft-ietf-mpls-tp-cc-cv-rdi carefully , CC and CV interleave are newly invented, it is too different with old BFD, how to interoperate with old BFD?


Many experts in IETF  stated "only one solution for MPLS-TP OAM", if you looked solutions about PW OAM in IETF, you will found there are already 3 solutions! In fact, different solution for different application.


MPLS-TP OAM based on Draft-bhh can be interoperated with BFD with an overlay mode, such as IP/MPLS over SDH, you can image that MPLS-TP based PTN as the same with SDH.


B.R.


Elton

HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE