International Telecommunication Union   ITU
Site Map Contact us Print Version
 Monday, 14 March 2011
With ITU’s recent announcement on an OAM standard for MPLS in transport networks generating claims from the Internet Society that it will jeopardize the Internet, counter claims and much press coverage it seems the right time to set the record straight.

The technology at the heart of the debate is operations and management (OAM) for Transport MPLS. MPLS-TP refers to an adaptation of the Internet Engineering Task Force (IETF)'s MPLS protocol for telecom networks. MPLS can carry packets of different types, allowing telecom operators to offer private connections as well as IP services.

ITU-T Study Group 15 working on MPLS-TP voted 25, February 2011, to proceed with its own OAM solution, rather than only working with the IETF on the development its preferred OAM solution. This step was taken since, despite the agreement between the two organizations to work together, the OAM solution being developed by the IETF does not satisfy the requirements of some members of the ITU.

The text below charts a history of the work T-MPLS/MPLS-TP work in ITU to address a management protocol for telecom-operator networks and seeks to explain the divergence.

History of MPLS-TP

In 2006/2007 the ITU-T developed Recommendations on T-MPLS, a sub-set of MPLS that was targeted specifically for application in the transport network (to offer a more flexible interconnection between routers than SDH or OTN). By January 2008 the ITU-T had 5 approved Recommendation on T-MPLS and one on OAM ready for approval. However, in late 2007 the IETF indicated that T-MPLS may be in conflict with IP/MPLS. The ITU suspended work on T-MPLS and in 2008 agreed to work in cooperation with the IETF on the evolution of MPLS to meet the needs of the transport network. It was anticipated that the five existing Recommendations on MPLS-TP would be replaced by mid 2009 with a Recommendation on OAM following within a year. The IETF RFCs that are necessary to allow replacement of this initial set of Recommendations are not yet available.

One particularly contentious issue has been OAM. A significant segment of the operator community views that the IETF has given insufficient consideration to their needs, concerns, and proposals (documented in Internet drafts). The IETF state that the protocols currently under development will meet the requirements. After over a year of discussion, there has been no quantitative analysis to demonstrate that they satisfy the operational behaviour and procedures utilized in transport networks of these network operators.

One important initial step in the joint work was for the IETF and ITU-T agree on a mechanism to detect OAM packets that conforms to the MPLS architecture. The agreed mechanism uses a new reserved label (13) and a “Protocol Identifier” know as the G-ACh code point to identify specific functions and protocols. More than 64,000 of these code points are available.

The ITU proposed that the OAM for MPLS-TP should be based on Y.1731 (carrier grade Ethernet) which had already been proven to meet the requirements of the transport network. Instead in July 2009 the IETF insisted that the OAM should be based on existing IETF tools to support backwards compatibility. This included developing extensions to an existing tool, Bidirectional Forwarding Detection (BFD) for continuity check and connectivity verification (CC/CV).

In October 2009 the IETF disbanded the MPLS interop design team (the MEAD team) claiming that its work had been completed. The MEAD team was established in response to one of the proposals in the JWT report. See below for the relevant text from the JWT report.

Another proposal in the JWT report is that experts from the ITU should directly participate in the work of the IETF. However, since this group of experts are viewed as “newcomers” when considering rough consensus the opinions of these experts are given less weight than the opinions of “long term” IETF participants. This is allowed by the IETF guidelines when judging what it calls “rough consensus”. However, it does not meet the intent of the collaboration between the ITU and the IETF. Since the MEAD team was disbanded the IETF has continued to take decisions on the direction of the work without consulting the ITU, without informing the ITU of these decisions, or requesting confirmation from ITU that the resultant solutions produced by the IETF will meet the needs of all of the membership of the ITU. Several RFCs on MPLS-TP have been approved without receiving consensus support from the ITU.

In May 2010 the MPLS working group adopted the BFD based draft by rough consensus. The WG chair suspended the poll for making this a WG draft since “we are not reaching consensus” (see, a few days later he decided to adopt the document as a WG draft anyway (see In an attempt to meet some of the requirements of the transport network the BFD draft has evolved. It is no longer backwards compatible with the existing BFD based tools or with any of the existing PW OAM tools. It uses a complex state machine to negotiate the repetition rate of the messages. This state machine is only required to allow routers (that have been optimized for other applications) to negotiate a lower repetition rate for OAM messages since they are unable to sustain the rates required for transport network applications. One of the key requirements of the transport network is that the repetition rate must be set by the network operator and remain fixed at this value. Adding a state machine to negotiate the rate significantly increases the complexity and impacts the scalability of the network. For applications in the transport network, a solution that does not use rate negotiation is technically superior and less complex (and therefore offers a lower cost solution).

The IETF have continually refused to consider the Y.1731 based solution (in draft-bhh-mpls-tp-oam-y1731 and G.tpoam) despite the extensive deployment experience, successful multi vendor interoperability tests and strong support from multiple network operators.

The current approach is dissipating significant resources from both standards organizations without producing tangible results. It is unlikely that these views will be reconciled by further discussion (as shown by the discussions in SG15 meeting in February 2011).

In an attempt to break this deadlock, in July 2010 at the request of several Member States, the ITU-T proposed an enhancement to the model for the interaction with the IETF on OAM. This proposal was based on the model that was used with great success when the IEEE and ITU collaborated on the development of OAM for carrier grade Ethernet. This approach allows both organizations to develop solutions that meet the needs of their constituents within a common architecture and would significantly reduce the amount of time spent by both standards bodies. However, so far the IETF have chosen not to explore this approach.

Due to this lack of progress, and to meet the needs of its members, ITU-T decided to move ahead and document an OAM solution that can co-exist, both in the network and in the Recommendations, with an IETF defined solution. The solution being proposed by the ITU conforms to the MPLS-TP architecture as defined by the IETF. It uses an IETF defined mechanism (the allocation of a unique ACh code point) to ensure that it will not interfere with any IETF defined mechanisms. Further, in the case where networks that run the IETF defined solution must be interconnected with a network that runs the ITU solution, then the IETF solution must be used.

The prime objective at the start of the joint work was to ensure that the extensions required to make MPLS fit for use in a transport network are within the MPLS architecture. The proposals from the ITU conform to the MPLS architecture and complement (rather than contradicts) solutions under definition in IETF to meet the needs for the global industry (including those operators that are not satisfied with the IETF solution). It is the IETF who have chosen to characterize the ITU actions as breaking the agreement despite the fact that they have already ignored the proposals in the JWT report.

JWT report proposal on Future inter-SDO organizational structure (slide 5 of the JWT report):

The JWT report indicates that the inter-SDO structure is intended to support collaborative work:

•  It is proposed that the MPLS interop design team, JWT and ad hoc T-MPLS groups continue as described in SG15     
   TD515/PLEN with the following roles:

      –    Facilitate the rapid exchange of information between the IETF and ITU-T
      –    Ensure that the work is progressing with a consistent set of priorities
      –    Identify gaps/inconsistencies in the solutions under development
      –    Propose solutions for consideration by the appropriate WG/Question
      –    Provide guidance when work on a topic is stalled or technical decision must be mediated

The work of these inter-SDO groups was not completed when the MEAD team was disbanded as the ongoing debate on the OAM solution demonstrates. The IETF did not consult the ITU or even inform the ITU on several critical decisions, for example. The unilateral decision by the IETF to adopt the BFD draft as the solution for CC/CV; the refusal to consider draft-bhh-mpls-tp-oam-y1731; to consider the input from the ITU that two solutions should be standardized; all of these decisions were taken by “rough consensus” over strong objections. This is clearly contrary to the collaborative mode of operation described in the JWT report.

History of MPLS OAM:

Y.1711 defined the first OAM tools for MPLS, this made use of a reserved label (14) as defined in RFC3429: Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions. That was published by the IETF in November 2002 as an Informational RFC.

Subsequently the IETF developed some alternative OAM tools for MPLS LSP, they also developed several different tools for use in PWs.
     It should be noted that in these cases the IETF did not declare that this multiplicity of OAM tools is harmful to the integrity of the Internet.

In 2007 the ITU developed draft Recommendation G.8114 documenting OAM tools for T-MPLS, this toolset was backwards compatible with Y.1711. This draft Recommendation was ready for approval in January 2008 G.8114. However, the IETF stated that the method used to detect the OAM packets “violated the MPLS architecture” and claimed that it would be harmful to the Internet. On the basis of these statements the ITU did not approved G.8114 and agreed to work in cooperation with the IETF to develop a solution that conformed to the MPLS architecture.

Note:  More than 40,000 nodes running draft G.8114 OAM have been deployed without any reports of harm to the Internet.

After waiting three years for the IETF to deliver a solution that will meet the needs of its membership SG15 has now voted in favour of solution which conforms to the MPLS architecture and meets the needs of its membership.

Despite all this effort on the part of ITU to collaborate with IETF it is now falsely claiming that ITU reneged on the JWT agreement.

Comparison of MPLS-TP OAM and Ethernet OAM

The figure below illustrates the OAM frame formats for Ethernet and MPLS-TP

In the case of Ethernet the IEEE and ITU mutually agree on the assignment of the OAM OpCode values to differentiate between OAM PDUs defined by the ITU and IEEE. This allows the ITU-T to develop OAM functions targeted at the transport network without any possibility of a clash with IEEE developed protocols.

The Channel Type could offer the same degree of separation if the IETF assigned a channel type for use by the ITU-T for OAM targeted for application in transport networks.


and Share