OAM is developed for the following packet technologies: Ethernet OAM and MPLS OAM
International Telecommunication Union (ITU-T)
This Recommendation specifies mechanisms required to operate and maintain the network and service aspects of the ETH layer. It also specifies the Ethernet OAM frame formats, and syntax and semantics of OAM frame fields. The OAM mechanisms as described in this Recommendation apply to both point-to-point ETH connections and multipoint ETH connectivity. The OAM mechanisms as described in this Recommendation are applicable to any environment independently of how the ETH layer is managed (e.g., using network management systems and/or operational support systems).
This Recommendation includes the OpCodes CCM, LBM, LBR, LTM and LTR defined in IEEE 802.1ag. It contains additional OpCodes for Performance Monitoring: LMM, LMR, DMM, DMR and 1DM, Diagnostics: TST, Protection: APS, Admnistration: AIS and LCK, Management: MCC, and Miscellaneous: EXM, EXR, VSM and VSR.
Institute of Electrical and Electronic Engineers
This amendment specifies protocols, procedures, and managed objects to support connectivity fault management. These allow discovery and verification of the path, through bridges and LANs, taken for frames addressed to and from specified network users. Connectivity faults can be detected and isolated to an individual bridge or LAN.
ITU-T Y.1731 includes a number of OpCodes in addition to the CCM, LBM, LBR, LTM, and LTR defined in this standard.
International Telecommunication Union (ITU-T) Recommendations.
Internet Engineering Task Force (IETF) RFCs.
A little more background from someone who has been involved since day 1:
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 an OAM synergy between routers and SDH / OTN equipment). By January 2008 the ITU-T had five 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. Within the IETF, there has been insufficient consideration given to the needs, concerns, and proposals (documented in Internet drafts) from a significant segment of the operator community. The IETF states 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.
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 ITU-T SG15 plenary meeting February 14-26, 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 develop 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 protocol identifier) 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 network that runs the ITU solution then the
IETF solution must be used.
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 they are large enough to demand a different solution. If we do not standardize a solution that satisfies the requirements of these operators 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 (see above:
It is not surprising that in the intervening 3 years some network operators have undertaken substantial pre-standard deployments to accommodate their network growth. They have gained significant operational experience which has been incorporated into the draft Recommendation from the ITU.
It is 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 with the existing Transport Network (SDH/OTN) from the perspective operational behaviour, operational functionality and operational process.
The solution being developed in the IETF is 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 their Recommendations will include the appropriate applicability statements and if these two types of network are interconnected then the IETF solution must be used.
Ii is very difficult to understand why the approach being proposed by the ITU in support of the requirements of a significant number of network operators cannot be adopted.
ITU-T Recommendation Y.1711 "Operation & Maintenance mechanism for MPLS networks" defined the first OAM tools for MPLS. These tools made use of a reserved alert label  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 LSPs, and they also developed several different tools for use in PWs.
Note: The IETF have never declared that this multiplicity of OAM tools is harmful to the Internet.
In 2007 the ITU developed draft Recommendation G.8114 describing the T-MPLS OAM tools; this toolset was backwards compatible with Y.1711. The draft Recommendation G.8114 was ready for approval in January 2008. However, during the ITU-T plenary meeting 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 approve 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 T-MPLS OAM have been deployed without any reports of harm to the Internet.
One important initial step in the joint work was for the IETF and the ITU-T to agree on a mechanism to detect OAM packets that conforms to the MPLS architecture. The agreed mechanism uses a new reserved Alert Label  and a G-ACh Protocol Identifier to identify specific OAM functions and protocols.
Note: More than 64,000 of these code points are available.
The ITU proposed that the OAM for MPLS-TP should be based on Recommendation Y.1731 "OAM functions and mechanisms for Ethernet based networks" (carrier class 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. These included developing extensions to BFD for continuity check and connectivity verification (CC/CV).
In January 2011 the IETF MPLS working group adopted the BFD based draft by rough consensus. The WG chair started a poll for making this a WG draft, the poll was suspended by the WG chair since “we are not reaching consensus”. However, a few days later he declared that the draft had been adopted by “rough consensus”.
The IETF have refused to consider the Y.1731 based solution (described in draft-bhh-mpls-tp-oam-y1731 and G.tpoam) despite the existing running code, the implementation by multiple vendors and the extensive deployment experience. Such deployment experiences are described in draft-fang-mpls-tp-oam-considerations.
More to come....
Write me an email: To write me an email click on:
Just in case you are lost return to my homepage.