Keywords

1 Introduction

OAM is a very efficient set of tools which is used to monitor network operations. OAM consists of various functions that empower discovery of network failure and monitoring of network performance. OAM can also localize the defect and may trigger functionalities like raising alarms or initiating rerouting.

OAM mechanism assures that service provider adhere to QoS guarantees, discover faults before they intensify, and localize network defects. The network which does not support OAM functionality, requires additional resources in order to detect faults and measure performance of the network manually, as a result non-OAM networks have longer down period, inferior availability and are very expensive to maintain. Many standard bodies like ITU SG 13, IEEE 802.1, IETF, MEF 17, and IEEE 802.3 are actively working on enhancement of OAM.

The remaining of the paper is structured as follows: Section 2 gives brief description of OAM mechanism for Ethernet networks. Section 3 describes OAM for MPLS and MPLS-TP. Section 4 describes IP OAM. Section 5 points out the scatteredness of OAM tools, problem faced by service providers and customers, need of convergence of OAM, and proposes a new IP OAM standard based on ITU Y.1731 OAMPDU. Section 6 gives implementation proposal for new IP OAM.

2 OAM for Ethernet

Ethernet introduced as LAN technology earlier consisted of countable stations and was handled by an individual entity. Since performance was not considered as an important parameter, fault detection was carried out manually. But as Metro Ethernet and Carrier Ethernet technologies evolved, it became essential to reinforce automated failure discovery and performance monitoring in order to promise SLAs.

Necessity has been raised to incorporate OAM mechanism on the Ethernet layer, in order to provide automated fault detection and performance monitoring. To support OAM mechanism on legacy non-OAM capable devices, OAM should be compatible with legacy Ethernet protocols. As a result two Ethernet OAM standards were introduced, one for single link operation and other for end-to-end service monitoring.

IEEE 802.3 working group introduced link-layer OAM [1] in the form of 802.3ah standard for “Ethernet in the first mile” (EFM) applications. ITU-T Y.1731 and IEEE 802.1ag are the two standards for Ethernet Service OAM introduced by combined efforts of IEEE 802.1 and ITU Study Group- 13. Same OAM PDU format and protocol functions supported by these two standards lead to simple implementation of Ethernet OAM for service provider. IEEE 802.1ag [2] gives the procedure to implement Ethernet OAM in IEEE 802.1 bridge and on top of that ITU standard provides some supplementary tools like Performance Monitoring which includes one-way, two-way delay and packet loss measurement and tools for alarm suppression [3, 4].

In Ethernet network, OAM packets are differentiated from data with the help of Ethertype value (0×8902 for Service OAM and 0×8809 for EFM OAM) and type of OAM PDU is identified by OpCode field present in OAM PDU. In Service layer OAM, OAM packets are addressed to MEPs (Maintenance End Points) and MIPs (Maintenance Intermediate Points) using specific value configured in Maintenance Entity Level (MEL) field in OAM PDU [4]. From Ethernet OAM toolset, service provider or customer can proactively run Continuity Check tool to detect any failure in network, upon failure detection Loopback messages can be used to verify it and upon verification Link Trace tool is used to isolate the failure. Delay Measurement (DM), Loss Measurement (LM), or Synthetic Loss Measurement can be used for performance monitoring. Table 1 gives brief about various tools present in Service layer Ethernet OAM toolset [4].

Table 1 Ethernet OAM toolset overview

3 OAM for MPLS

To support circuit switched IP networks, IETF introduced MPLS (Multiprotocol Label Switching) technology, which is also called as layer 2.5 network. In order to have OAM functionality for MPLS, IETF introduced MPLS OAM standard which has a considerable IP component. The MPLS OAM PDUs are basically IP packets.

IETF introduced LSP Ping [5], Bidirectional Forwarding Detection (BFD) for LSPs [6, 7] and BFD for VCCV [8] to check connectivity of LSPs. For MPLS loss and delay measurement, IETF introduced a Loss Measurement (LM) and Delay Measurement (DM) [9] protocol which operates over the MPLS Generic Associated Channel (G-ACh) for LSPs, Pseudowires (PWs), and MPLS sections. Table 2 gives brief of IETF defined MPLS OAM toolset.

Table 2 IETF MPLS OAM toolset overview

To support MPLS applications, ITU introduced new OAM standard (ITU-T Y.1711) known as “Operation and Maintenance mechanism for MPLS networks” with more functionality which was not supported by IETF MPLS OAM such as Forward Defect Indication (FDI), Backward Defect Indication (BDI) alarms [10]. ITU MPLS OAM uses MPLS only OAM PDU unlike IETF MPLS OAM which uses IP UDP packet. All OAM packets are identified within LSP traffic by the use of OAM Alert Label (Label 14). Brief of ITU defined MPLS OAM toolset is given in Table 3.

Table 3 ITU MPLS OAM toolset overview

For MPLS-TP (Transport Profile) ITU-T suggests to reuse the same OAM PDUs format and mechanism defined in ITU-T Y.1731 [11]. MPLS-TP is based on same architectural perception of layered network which is already used in SONET/SDH and it takes the best from two worlds, OAM functions of TDM (SONET/SDH) and Data/Control plane efficiency from IP/MPLS networks. MPLS-TP does not support LTM/LTR function from ITU-T Y.1731, since it is used to trace a path for specific MAC address. All other functions of ITU-T Y.1731 are supported by MPLS-TP with the help of some additional TLVs.

In MPLS-TP network, OAM packets are differentiated from data with the help of ACH and GAL labels, and are addressed to Maintenance End Points and Maintenance Intermediate Points using MPLS forwarding mechanisms (TTL Expiration, Label Stacking). The existence of OAM PDU is classified by a unique ACH Channel Type and type of OAM PDU is given by OpCode field present within OAM PDU. Table 4 gives an overview of ITU defined OAM toolset for MPLS-TP.

Table 4 ITU MPLS-TP OAM toolset overview

4 OAM for IP

Considering the importance of IP as a backbone network, it is necessary to have separate OAM functionality for IP networks. IETF defines ICMP ping, IP Traceroute [12], and BFD [13] for IPv4 and IPv6 to discover and localize a defect in IP networks and for performance measurement IETF IPPM work group defines protocols for measuring packet loss and delay [14]. One-Way Active Measurement Protocol [15] and Two-Way Active Measurement Protocol [16] are used to measure one-way and two-way performance metrics, with the help of two types of protocols, control plane protocols, and test plane protocols. The control plane protocols are used to initiate and terminate the test sessions. Test protocols are used to create test packets and log statistics of packet arrival. Control protocols and test protocols run over TCP and UDP, respectively. Table 5 gives brief of IP OAM toolset.

Table 5 IETF IP OAM toolset overview

5 Convergence of OAM Toolset

As discussed in the previous sections, ITU and IETF defined their own OAM standards for Ethernet, MPLS, and IP networks. OAM enhancement is still in progress, other standard bodies are also working on enhancement of OAM tools. This leads to multiple OAM tools from different standard bodies which perform the same functionality. For example, ITU and IETF defined their own OAM tools for MPLS networks which offer the same functionality and important part is, they cannot be used in the same network because of their unique PDU format and method of identifying OAM packet. The Scattered OAM toolkit leads to multiple service monitoring and architectural alternatives to the service providers. To deploy Ethernet, MPLS, and IP OAM, service provider needs to maintain different state machines for each tool which results into more complex architecture. So there is a need for convergence of OAM toolkit, to do so we suggest reusing the same PDU format and procedures defined in ITU-T Y.1731 standard for IP OAM, which can be benefited for the service provider and the customer in many ways. Although ITU-T Y.1731 is defined for Ethernet OAM, it is technology independent which allows us to use same toolset in any other packet technologies. Some of the benefits of reusing ITU-T Y.1731 PDU in IP are as follows:

  • ITU-T Y.1731 OAM tool set is very rich in terms of fault management, performance management tools. It also supports other applications like Experimental OAM, Vendor-specific OAM, and APS.

  • Usage of same OAM toolkit in all networks will allow us to maintain same state machine cycles.

  • By deploying the same OAM mechanism, there will not be any interoperability issue.

  • Any enhancement in toolset will allow us to adopt same enhancement in all other networks.

  • Can be used to generate individual layer alarms and notifications on detection of defect.

  • Packet processing delay can be reduced.

6 Implementation Proposal

ITU-T Y.1731 OAM PDU can be implemented in IP network in two ways:

  • With UDP header

  • Without UDP header

Y.1731 PDU can be inserted in packet after UDP (User Datagram Protocol) header, where UDP destination port will identify presence of OAM PDU and inside the OAM PDU, OpCode field gives the type of OAM PDU. In case of without UDP header, Y.1731 PDU can be inserted in packet directly after IP header, where protocol field in IPv4 and next header field in IPv6 will help to identify presence of OAM PDU in packet. Figures 1 and 2 show the proposed implementation strategy.

Fig. 1
figure 1

Implementation with UDP header

Fig. 2
figure 2

Implementation without UDP header

7 Conclusion

It is recognized that OAM mechanism is a very important toolkit for network providers and customers. This paper summarizes different OAM toolset supported by Ethernet, MPLS, and IP networks. It is observed that, there are multiple tools present, which perform the same functionality, so there is a need for convergence of OAM toolset.

In this paper, we suggest reusing ITU-T Y.1731 OAM PDU in IP networks, which results into the “Converged OAM” toolset. OAM deployment and architectural issues can be resolved with proposed solution. Future work is to work on detailed analysis of proposed solution to find out pros and cons of new IP OAM implementation.