Addressing the MPLS-TP OAM Divide

As the name indicates, one of the primary drivers of the MPLS Transport Profile (MPLS-TP) is the adaptation of certain transport features/functions to MPLS-based networks. OAM is one of these essential transport attributes and unfortunately there is a divide between the IETF and some OEMs (and carriers) on selection of a common OAM technology. The ramifications are significant as the opposing methods are not interoperable and carriers have already begun deployments.

While some OEMs (and carriers) have already selected their OAM method of choice, there are signs that the opposing implementations will co-exist. Either way, Metaswitch customers of MPLS-TP can rest assured that we support both implementations – greatly reducing project risk.

Quick Backgrounder: MPLS-TP OAM

The ITU-T standardized Y.1731 OAM for Ethernet and planned to use the same for T-MPLS before it was deprecated for MPLS-TP. The IETF, which provides the standards for MPLS-TP, have decided against using Y.1731 for OAM in MPLS-TP. They have instead selected BFD (bidirectional forwarding detection) to provide continuity check (CC), connectivity verification (CV) and remote defect indication (RDI), and are creating more protocols for other OAM applications. While many are planning for IETF compliance, some vendors and carriers have already implemented Y.1731 and their attempts to re-submit to the IETF have been thwarted. Given the investments and momentum by both sides, it is likely that dual implementation will co-exist in some fashion

Metaswitch MPLS-TP OAM Support

GMPLS control plane protocol extensions and APIs are required to deliver fully integrated OAM solutions. Metaswitch supports the following, for both IETF-compliant and Y.1731 OAM methods:

• A new DC-OAM product
• Management Interface to enable an operator to request (pro-actively or on-demand) OAM to be used on a given LSP or Pseudowire
• Instructions sent to the OAM layer (which could be DC-OAM or vendor-specific) to indicate which OAM applications to use on a given LSP
• Interfaces to allow the OAM layer to report conditions that may trigger control plane actions
• Extensions to RSVP-TE to signal to peers which OAM applications are enabled/disabled on a given LSP

The net result is that Metaswitch offers a flexible MPLS-TP and OAM solution that allows OEMs to implement all OAM protocols. This helps reduce overall project risk and reinforces Metaswitch’s commitment to providing technology you can trust.