Cisco Asks for MPLS Unity

Cisco Systems Inc. (Nasdaq: CSCO) has chimed in on the MPLS controversy, preaching the message that a single standard would be best for the industry.

It's Cisco's rebuttal to the recent International Telecommunication Union, Standardization Sector (ITU-T) vote to pursue an operations, administration and management (OAM) standard based on the ITU's Y.1731 standard. That effort would diverge from the Internet Engineering Task Force (IETF) 's work on MPLS-TP -- the side that Cisco favors. (See MPLS Argument Leads to Split Standard.)

In a blog entry dated Tuesday, March 1, Cisco first points out that the ITU-T has only approved the first stage of what could be a years-long standards process, so Y.1731 for MPLS can't be called a standard yet. Fair enough.

Cisco's main point, though, is that the industry shouldn't be developing a second standard. Some carriers have already picked or even deployed Y.1731, and they'd like to stick with it, but Cisco argues that wouldn't be the best option.

"Operators who select another method that is perceived to meet their short term needs now [may] ultimately learn that it fails to provide everything they had expected, and that having multiple OAM methods (one for Ethernet and another for MPLS) is not cost effective," writes Mike Capuano, Cisco's senior director of service provider marketing.

It doesn't seem likely that the Y.1731 camp will be easily swayed, considering the direction of the debate so far. (See MPLS-TP Could Be Headed for a Split, Rumor: T-MPLS Group Gets Shouted Down and MPLS-TP Delays Keep T-MPLS Alive.)

As you can see on our message boards, the debate goes beyond technology and into the procedures of the standards bodies. The ITU-T and IETF had been working together on MPLS standards, but the ITU, in a press release Monday, says the joint working team wasn't addressing ITU members' concerns. (See ITU Picks an MPLS Standard.)

— Craig Matsumoto, West Coast Editor, Light Reading

Page 1 / 2   >   >>
yike 12/5/2012 | 5:11:13 PM
re: Cisco Asks for MPLS Unity

The one-only stardard is the favorite one, but if the JWT can not solve all issues that ITU concern, it is no harm to have a second standard for the OAM. It is a waste and is useless to just say "it is not the best option", list you proposals and solutions, we need to solve problems....

Pete Baldwin 12/5/2012 | 5:11:11 PM
re: Cisco Asks for MPLS Unity

I know this is easy to say from the outside, but: I'm having trouble understanding why having two options is so disasterous. 

It's not ideal, to be sure.  I completely understand why vendors don't want it that way. But some of the arguments against it ... interoperability, for instance.  Was there interoperability testing needed between Sonet and SDH? (Honestly asking; I wasn't around in those days.)

Malcolm_B 12/5/2012 | 5:11:10 PM
re: Cisco Asks for MPLS Unity


Having two standards is far from disastrous (see below for my rational). Given the current situation it is probably the best option. We have a significant number of Network Operators who are not satisfied with the solution being developed in the IETF and are large enough to demand that a different solution. If we do not standardize a solution that satisfies these requirements we face the real risk of having multiple different non standard solutions deployed in the network.

A few points to consider:

The ITU-T had an OAM solution for T-MPLS ready for approval in January 2008 when the ITU-T agreed to suspend work on T-MPLS and work jointly with the IETF to develop what became known as MPLS-TP. It's not surprising that in the intervening 3 years some network operators have undertaken substantial pre-standard deployments to accommodate network growth. They have gained significant operational experience which has been incorporated into the draft Recommendation from the ITU. It's strange to see a vendor suggesting that these network operator do not understand the needs of their networks.

The objective of these network operators for MPLS-TP is to run a multi technology (MPLS-TP, carrier grade Ethernet, OTN, SDH) connection oriented network that is consistent from the perspective with the existing Transport Network (SDH/OTN) operational behaviour, operational functionality and operational process.

The solution being developed in the IETF, an extension to BFD for CC/CV to maintain compatibility with existing IP/MPLS networks. However, as the draft has evolved it is no longer backwards compatible with the existing implementations of BFD. To maintain the ability to upgrade existing deployed equipment the BFD draft still uses a complex state machine to negotiate the repetition rate of the OAM messages.

In a transport network the repetition rate is configured by the network operator based on the SLA of the service being carried. Therefore, the ITU solution is not encumbered with the state machine.

It appears that we have two distinct communities of interest, one concerned with compatibility with existing IP/MPLS and the other, that has been waiting for 3 years for a solution that is concerned with compatibility with transport networks.

The ITU have stated that they will include the appropriate applicability statements and if these two types of network are interconnected then the IETF solution must be used. I am having difficulty understanding why the approach being proposed by the ITU in support of the requirements of a significant number of network operators cannot be adopted.

chechaco 12/5/2012 | 5:11:08 PM
re: Cisco Asks for MPLS Unity

Dear Craig,

multi-standard environment creates or adds challenges to interoperability problem. Even if different OAM tool sets limited to control domains they will make end-to-end monitoring of multi-segment connections more difficult.

tmmarvel 12/5/2012 | 5:11:05 PM
re: Cisco Asks for MPLS Unity

What is most urgently needed, to improve the cost efficiencies of L2 services, is multi-vendor data plane interoperability based on MPLS-TP, in particular between L3 IP/MPLS LERs and L2 MPLS-TP LSRs.

It will be quite unlikely that SPs would in practice insist on having their management/control planes inter-worked for MPLS-TP L2 services in the first phases of bringing MPLS-TP services to the market. Most SPs will almost certainly start with offering the L2 MPLS services (based on MPLS-TP data plane standard -- and equipment and management systems that actually support MPLS-TP both on LERs and LSRs) over their own L3/2 network domains.

The MPLS-TP OAM standard dispute seems not much more than a cover operation for delaying L2 MPLS-TP interface support on the major IP/MPLS LER equipment, and this articial delaying of support for L2 MPLS-TP LSP support by L3 LERs seems to be real gating factor for progress of this widely needed unified, and simplified, L2 packet transport protocol.

chechaco 12/5/2012 | 5:11:04 PM
re: Cisco Asks for MPLS Unity

While I agree on cost efficiency/price per port I'm confused by your reference to implied dataplane interoperability problem. I don't know of any market available L2 MPLS-TP compliant LSR (who certified them as such?). MPLS-TP, whether we like it or not, is a subset of MPLS. It clearly excludes IP/MPLS and is more aligned with MPLS-TE. I think that attempts to put MPLS-TP network on a peer level with IP/MPLS networks will prove frutille.

At the same time, OAM tool set(s) developed for MPLS-TP could and will be applied to existing and future non-TP MPLS networks. It's likely that IETF tools set will fit that bill better.

wyaacov 12/5/2012 | 5:11:01 PM
re: Cisco Asks for MPLS Unity

Malcolm, hi

Not sure that your rationale is really rational as you presented it.  I am sure that you are trying to gloss over some of the non-"important" facts of the history while clouding some of the other facts.

1. The reason that the ITU discontinued their work on T-MPLS was not just (out of the goodness of their hearts) in order to work together with the IETF, but rather because the IETF sent a LS with hundreds of comments and warnings concerning the Recommendations that were being developed and technical arguments identifying dangers to the Ineternet from the T-MPLS Recommendations.  This in turn caused the creation of the JWT whose recommnedation was accepted by ITU-T SG15, explicitly stating that any specification work on solutions for MPLS-TP shall be done in the IETF.

2. Your paragraph on the IETF CC-CV-RDI solution is totally confusing.  On the one-hand you say that it is not backward compatible with existing BFD, while on the other hand, you say that it includes rate negotiation because of compatibility!  While the ITU claims that CCM is "stateless" - it in fact maintains a state via a suspension timer.  In addition, during discussion that was held in last week's ITU meetings (slipped under the radar of the SG15 management team) it was pointed out that CCM is very open to different types of denial of service attacks and other security risks.

3. It was stated by several of the operators (from those that insist on the Y.1731 solution) that the IETF tools would satisfy their needs, but their problem is time-to-market (not a valid standards argument IMHO).  However, the current status of the OAM Recommendation is that it was not consented but rather is in a kind of dead-end process that is more political rather than technical.  In fact, according to ITU processes (as I understand them) could be delayed as much as three years before any approval.

Just my two cents (not worth much more than that!)

mvissers 12/5/2012 | 5:11:00 PM
re: Cisco Asks for MPLS Unity

SDH standard includes three different flavors, typically referred to as AU4-SDH, AU3-SDH and SONET. AU4-SDH is able to pass through SONET and AU3-SDH signal, but is typically unable to terminate their signals.

Example: to set up a number of VT1.5 connections between USA and Europe the following was done: SONET VT1.5 SPE connections are multiplexed into an STS1 SPE. STS1 SPE is transported over the transoceanic cable. In Europe the STS1 SPE is continued as a LO VC3 and the STS1 pointer is replaced by a TU3 pointer; this conversion is performed in special "AU3<=>TU3" capable interface port. The LO VC3 is multiplexed into a HO VC4. The resulting stack in the AU4-SDH network is: VT1.5 -> STS1 SPE = LO VC3 -> HO VC4. This LO VC3 passes through the AU4-SDH network and at the end it is passed through another "TU3<=>AU3" capable interface port. OUt of this port comes again a STS1 PSE with a STS1 pointer. This signal is then delivered to a SONET equipment located in the customer premise in Europe.

One of the OAM differences between AU4-SDH and SONET is the "CV" OAM format. In SDH a 16-byte Trail Trace Identifier is used as "CV" OAM, in SONET a 64-byte TTI is used as "CV" OAM.

Another difference between SONET and SDH is the tandem connection monitoring OAM format.

Maarten Vissers

Sprecher 12/5/2012 | 5:10:58 PM
re: Cisco Asks for MPLS Unity

In the past, there were cases where multiple solutions were defined which were both inconsistent and incompatible. As they did not interoperate, they required the development of interworking systems, thus increasing operational and capital expanses. This also created significant confusion in the industry, sometimes with negative effects on the end customer.

The development of two competing solutions can also have undesirable implications for vendors and service providers.

·          If two standard solutions exist, equipment manufacturers (vendors) need to select the option that they intend to manufacture. This creates uncertainty in the communications market, since it is obvious that the sales of one solution will be less than those of the other.  An additional consideration relates to the costs involved in purchasing components for a solution where the market may be limited.   This means that if a manufacturer decides to develop systems for which two standard solutions exist, further investment will be required to ensure interoperability and global deployment.  This presents manufacturers with significant challenges and expenses.

·          When two standard solutions exist for OAM, service providers need to carefully consider which of the solutions suits them. In order to justify their investment, they must analyze development and manufacturing costs as well as forecast the solution’s performance in an evolving industry.  It is obvious that additional overhead will be involved, since the solution will need to interoperate with other solutions, and this needs to be managed and controlled. Moreover, they will have to cope with a reduced number of suppliers of components, since some suppliers are likely to manufacture parts for the alternative solution.

·          The end customer who pays for services will be exposed to a level of uncertainty as the device/component/product he buys may not interoperate with other products on the market. This may affect the quality of service that he receives and involve him in additional expenses.

For these reasons, it is highly desired to ensure the development of a single, global solution for MPLS-TP OAM. 

The solution needs to be defioned in the IETF, using the IETF  processes, according to the agreement between the ITU-T and the IETF (which was accepted by ITU-T SG15 in December 2008 as indicated in TD 7 (WP3/15)). The solution should fit all deployment scenarios.


mvissers 12/5/2012 | 5:10:58 PM
re: Cisco Asks for MPLS Unity

As indicated in my previous post, SDH is an extremely succesful 3-in-1 standard. Now let's look into MPLS standards... is it also a 3-in-1 standard? I believe that it is... we have the traditional MPLS PSN with its mp2p LSPs carrying IP flows and carrying PWs, we have the emerging MPLS-TP PSN with a mix of mp2p LSPs and p2p transport-LSPs, and we have the emerging MPLS-TP PTN with p2p transport-LSPs. Will this 3-in-1 MPLS standard be succesful? It can be if our industry acknowledges the three distinct application areas and quickly completes their standardisation.

Note that some operators have installed their packet transport network about 5 to 6 years ago, and those operators are now planning to complement the PTN by an (E)OTN to address the increased bandwidth demands. The role of the MPLS mp2p LSPs and MPLS-TP transport-LSPs is taken over by OTN ODUs.

A main application area for MPLS-TP PTN is the fixed and mobile broadband backhaul networks. Those networks are often required to provide a wholesale broadband service access. This wholesale broadband access service is based on the support of Ethernet services (MEF's E-Line and E-Tree and in future possibly also E-LAN services).

Multiple service providers encapsulate their IP flows into Ethernet VLANs and offer those VLANs as MEF EVCs to the packet transport network operator. The network operator transports those EVCs through its PTN to the access nodes (e.g. DSLAMs, OLTs, NodeBs, eNodeBs).

There is no MPLS in the handoff between the service providers and the network operator. The network operator may use MPLS-TP as its PTN technology to transport the E-Line EVCs, or may use a combination of MPLS-TP and VPLS (i.e. Ethernet) as its PTN technology to transport the E-Tree EVCs. In a number of cases, an ethernet only edge node is used. In all those cases MPLS-TP technology is deployed in the role of MEF's "Transport Services Layer", and this layer is supporting the "Ethernet Services Layer". In this PTN application, MPLS-TP has no connections with the L3 IP/MPLS (i.e. the "Internet").

Another application of MPLS-TP OAM is in the IP/MPLS core network. Here there are two directions possible; (1) upgrade the OAM capabilities in the existing MPLS PSN with its mp2p LSPs to MPLS-TP OAM, and (2) migrate the MPLS PSN mp2p LSPs to MPLS-TP p2p transport-LSPs with MPLS-TP OAM.

In the first application, the use of MPLS-TP PSN OAM (based on BFDs/LSP-Ping) is the natural choice. In the second application each operator can pick its preferred OAM flavor. As we will see OTN ODU connections (e.g. ODUflex) being used more and more in the near future as replacement for Gbit/s-transport-LSPs, the use of MPLS-TP PTN OAM for sub-Gbit/s-transport-LSPs might be a good first step towards the deployment of OTN ODUs. It will make the transition from LSPs to ODUs painless.

Maarten Vissers

Page 1 / 2   >   >>
Sign In