OAM functions in MPLS based transport network
draft-ietf-mpls-tp-oam-analysis-03.txt

Abstract

This document describes the outcome of the discussions on the necessary OAM functionality for the first release of MPLS based transport networks. The discussion is based on the set of requirements for Operations, Administration, and Maintenance (OAM) for MPLS based transport networks as defined in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.). An important aspect was to evaluate whether existing OAM tools from the current MPLS protocol suite can be used to fulfill these requirements. Eventually, the purpose of the document is to map the set of functions to a set of tools based on the existing OAM tool-set.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on July 6, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
    1.1.  Scope
    1.2.  Organization of the document
    1.3.  Contributing Authors
    1.4.  Acronyms
2.  Basic OAM infrastructure functionality
3.  MPLS-TP OAM Functions
    3.1.  Continuity Check and Connectivity Verification
        3.1.1.  Documents for CC-V tools
    3.2.  Remote Defect Indication
        3.2.1.  Documents for RDI
    3.3.  Route Tracing
        3.3.1.  Documents for Route Tracing
    3.4.  Alarm Reporting
        3.4.1.  Documents for Alarm Reporting
    3.5.  Lock Reporting
        3.5.1.  Documents for Lock Reporting
    3.6.  Lock Instruct
        3.6.1.  Documents for Lock Instruct
    3.7.  Client Failure Indication
        3.7.1.  Documents for CFI
    3.8.  Packet Loss Measurement
        3.8.1.  Documents for Packet Loss Measurement
    3.9.  Packet Delay Measurement
        3.9.1.  Documents for Delay Measurement
4.  MPLS-TP OAM documents guide
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  Normative References
§  Authors' Addresses

1.  Introduction

1.1.  Scope

OAM (Operations, Administration, and Maintenance) plays a significant role in carrier networks, providing methods for fault management and performance monitoring in both the transport and the service layers in order to improve their ability to support services with guaranteed and strict Service Level Agreements (SLAs) while reducing their operational costs.

[MPLS‑TP Reqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) in general, and [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) in particular define a set of requirements for OAM functionality in MPLS-Transport Profile (MPLS-TP) for MPLS-TP Segments, Label Switched Paths (LSPs) (network infrastructure) and Pseudowires (PWs) (services).

The OAM solution developed by the joint IETF and ITU-T MPLS-TP project has three objectives:

• The OAM tool-set should be developed based on existing MPLS architecture, technology, and tool-sets.
• It should be verified that the OAM tool-set for MPLS transport networks should be aligned with the comparable tool-set in legacy transport networks as much as possible.
• The OAM tool-set developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.).

The discussion on the needed OAM tool-set took place, mainly, in the MPLS Interoperability Design Team (the MEAD). A tool-set was agreed upon and was reported to the MPLS working group in Stockholm (July 2009) during the IETF meetings. This was also judged to be the working group consensus.

This document outlines these recommendations for the tool-set that should be defined to fulfill the OAM functionality requirements as documented in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) and [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.). Based on the objectives cited above, it was determined to base the MPLS-TP OAM tool-set on the following existing MPLS tools:

• LSP-Ping as defined in [LSP Ping] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.).
• Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD] (Katz, D. and D. Ward, “Bidirectional Forwarding Detection,” February 2009.) and refined in [MPLS BFD] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs,” June 2008.).
• ITU-T OAM for Ethernet tool-set as defined in [Y.1731] (International Telecommunications Union - Standardization, “OAM functions and mechanisms for Ethernet based networks,” May 2006.) this will be used for functionality guidelines for the performance measurement tools that are not currently supported in MPLS.

It should be noted that certain extensions and adjustments may be made to the existing MPLS tools, in order to conform to the transport environment and the requirements of MPLS based transport networks.

1.2.  Organization of the document

Section 2 of the document reviews the requirements for MPLS-TP OAM and shows how they are addressed by the top-level architectural RFCs

Section 3 outlines the different functional tools that are required for MPLS-TP OAM and references the documents that define the appropriate tools based on the principles outlined above.

Section 4 provides the user with a cross-reference, pointing out which tools are addressed by each of the OAM solutions RFCs.

1.3.  Contributing Authors

Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi (Alcatel Lucent), Huub van Helvoort (Huawei)

1.4.  Acronyms

This draft uses the following acronyms:

2.  Basic OAM infrastructure functionality

[MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) defines a set of requirements on OAM architecture and general principles of operations which are evaluated below:

[MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) requires that

• OAM mechanisms in MPLS-TP are independent of the transmission media and of the client service being emulated by the PW.
• the MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM tool-set should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing.
• all OAM protocols support identification information, at least in the form of IP addressing structure and be extensible to support additional identification schemes.
• OAM packets and the user traffic are congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality.
• a single OAM technology and consistent OAM capabilities for LSPs, PWs, and Sections.
• OAM packets may be directed to an intermediate point of a LSP/PW.

The following comprise the document-set that addresses the basic requirements listed above:

• The [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.) document describes the architectural framework for conformance to the basic requirements listed above. It also defines the basic relationships between the MPLS structures, e.g. LSP, PW, and the structures necessary for OAM functionality, i.e. the Managed Entity Group, its End-points, and Intermediate Points.
• The [MPLS G‑ACH] (Bocci, M., Bryant, S., and M. Vigoureux, “MPLS Generic Associated Channel,” June 2009.) document specifies the use of the MPLS-TP in- band control channel. This is modeled after the VCCV channel described in [PW ACH] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.) and allows transporting the OAM messages congruently with the data traffic while allowing the required identification of the packets. It is expected that all of the OAM protocols will be used in conjunction with this Generic Associated Channel.
• The [MPLS TP Idents] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” March 2010.) document addresses the need of MPLS-TP to support different addressing spaces. This document describes different formats for addresses that could be used to identify the transport entities in the network and referenced by the different OAM protocols.

3.  MPLS-TP OAM Functions

The following sections discuss the OAM functions that are required in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) and expanded upon in [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.).

3.1.  Continuity Check and Connectivity Verification

Continuity Check and Connectivity Verification (CC-V) are OAM operations generally used in tandem, and compliment each other. These functions are generally run pro-actively, but may also be used on-demand, either due to bandwidth considerations or for diagnoses of a specific condition. Pro-actively [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) states that the function should allow the MEPs to monitor the liveness and connectivity of a transport path. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP.

The [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.) highlights the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The function, both pro-actively and in on-demand mode, needs to be transmitted at regular transmission rates pre-configured by the operator.

3.1.1.  Documents for CC-V tools

[Pro CC‑V] (Allan, D. and G. Swallow, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” June 2010.) defines the BFD extensions that will be used for proactive CC-V applications. While [Demand CV] (Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, “MPLS on-demand Connectivity Verification, Route Tracing and Adjacency Verification,” June 2010.) provides the LSP-Ping extensions that will be used to implement on-demand Connectivity Verification. Both of these tools will be used together with the basic tools mentioned above in section 2.

3.2.  Remote Defect Indication

Remote Defect Indication (RDI) is used by a path end-point to report to its peer end-point that a defect is detected on a bi-directional connection between them. [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) points out that this function may be applied to a unidirectional LSP only if there a return path exists. [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.) points out that this function is associated with the proactive CC-V function.

3.2.1.  Documents for RDI

The [Pro CC‑V] (Allan, D. and G. Swallow, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” June 2010.) document includes an extension for BFD that would include the RDI indication in the BFD format, and a specification of how this indication is to be used.

3.3.  Route Tracing

[MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) defines that there is a need for functionality that would allow a path end-point to identify the intermediate and end-points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists.

3.3.1.  Documents for Route Tracing

The [Demand CV] (Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, “MPLS on-demand Connectivity Verification, Route Tracing and Adjacency Verification,” June 2010.) document that specifies the LSP-Ping enhancements for MPLS-TP on-demand Connectivity Verification includes information on the use of LSP-Ping for route tracing of a MPLS-TP transport path.

3.4.  Alarm Reporting

Alarm Reporting is a function used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the end-points of the path. [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.) states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. The consequent action of this function is detailed in [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.).

3.4.1.  Documents for Alarm Reporting

MPLS-TP defines a new protocol to address this functionality that is documented in [Fault Mng] (Swallow, G., Fulignoli, A., and M. Vigoureux, “MPLS Fault Management OAM,” March 2010.). This protocol uses all of the basic mechanisms detailed in Section 2.

3.5.  Lock Reporting

Lock reporting, defined in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.), is similar to the Alarm Reporting function described above. It is used by an intermediate point to notify the end points of a transport path that an administrative lock condition exists for this transport path.

3.5.1.  Documents for Lock Reporting

MPLS-TP defines a new protocol to address this functionality that is documented in [Fault Mng] (Swallow, G., Fulignoli, A., and M. Vigoureux, “MPLS Fault Management OAM,” March 2010.). This protocol uses all of the basic mechanisms detailed in Section 2.

3.6.  Lock Instruct

The Lock Instruct function is an administrative control tool that allows a path end-point to instruct its peer end-point to lock the path. The tool is necessary to support single-side provisioning for administrative locking, according to [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.). This function is used on-demand.

3.6.1.  Documents for Lock Instruct

The [LiLoopback] (Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, “MPLS Transport Profile Lock Instruct and Loopback Functions,” September 2010.) document describes the details of a new ACH based protocol format for this functionality.

3.7.  Client Failure Indication

Client Failure Indication (CFI) is defined in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification.

3.7.1.  Documents for CFI

A new ACH-based protocol is described in [MPLS‑TP CSF] (He, J., LI, H., and E. Bellagamba, “Indication of Client Failure in MPLS-TP,” July 2010.) that addresses the functionality defined for client failure indication.

3.8.  Packet Loss Measurement

Packet Loss Measurement is required, by [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.) to provide a quantification of the packet loss ratio on a transport path. This is the ratio of the number of user packets lost to the total number of user packets during a defined time interval. To employ this function, [MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.) defines that the two end-points of the transport path should exchange counters of messages transmitted and received within a time period bounded by loss-measurement messages. The framework warns that there may be small errors in the computation that result from various issues.

3.8.1.  Documents for Packet Loss Measurement

The [Loss‑Delay] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” April 2010.) document describes the protocol formats and procedures for using the tool. The tool logic is based on the behavior of the parallel function described in [Y.1731] (International Telecommunications Union - Standardization, “OAM functions and mechanisms for Ethernet based networks,” May 2006.).

3.9.  Packet Delay Measurement

Packet Delay Measurement is a function that is used to measure one-way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section), as described in [MPLS‑TP OAM Reqs] (Vigoureux, M., Betts, M., and D. Ward, “Requirements for OAM in MPLS Transport Networks,” April 2009.). Where:

• One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node.
• Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node.

[MPLS‑TP OAM Frwk] (Busi, I., Niven-Jenkins, B., and D. Allan, “MPLS-TP OAM Framework and Overview,” July 2010.) describes how the tool could be performed (both in proactive and on-demand modes) for either one-way or two-way measurement. However, it warns that the one-way delay option requires precise time synchronization between the end-points.

3.9.1.  Documents for Delay Measurement

The [Loss‑Delay] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” April 2010.) document describes the protocol formats and procedures for using the tool. The tool logic is based on the behavior of the parallel function described in [Y.1731] (International Telecommunications Union - Standardization, “OAM functions and mechanisms for Ethernet based networks,” May 2006.).

4.  MPLS-TP OAM documents guide

The complete MPLS-TP OAM protocol suite is covered by a small set of existing IETF documents. This set of documents may be expanded in the future to cover additional OAM functionality. in order, to allow the reader to understand this set of documents a cross-reference of the existing documents for the initial phase of the specification of MPLS based transport networks is provided.

[MPLS G‑ACH] (Bocci, M., Bryant, S., and M. Vigoureux, “MPLS Generic Associated Channel,” June 2009.) provides a specification of the basic structure of protocol messages for in-band data plane OAM in an MPLS environment.

[MPLS TP Idents] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” March 2010.) provides definitions of different formats that may be used within OAM protocol messages to identify the network elements of a MPLS based transport network.

[Pro CC‑V] (Allan, D. and G. Swallow, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” June 2010.) addresses the requirements for proactive use of Continuity Check, Connectivity Verification, and Remote Defect Indication functionality for MPLS transport networks.

[Demand CV] (Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, “MPLS on-demand Connectivity Verification, Route Tracing and Adjacency Verification,” June 2010.) addresses the requirements for activation of the Connectivity Verification functionality between endpoints or between an endpoint and intermediate point of a monitored domain of a transport path.

[Fault Mng] (Swallow, G., Fulignoli, A., and M. Vigoureux, “MPLS Fault Management OAM,” March 2010.) specifies protocol messages that support the functionality required to support Alarm Indication Signal and Lock Reporting required for MPLS transport networks.

[MPLS‑TP CSF] (He, J., LI, H., and E. Bellagamba, “Indication of Client Failure in MPLS-TP,” July 2010.) addresses the requirements to support a Client Signal Fail indication by clients that are being emulated by the MPLS transport services.

[LiLoopback] (Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, “MPLS Transport Profile Lock Instruct and Loopback Functions,” September 2010.) specifies protocol messages that support the functionality required for the Lock Instruct command and activation of the Loopback functionality for transport paths in MPLS networks.

[Loss‑Delay] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” April 2010.) addresses the requirements for performance measurement functionality for MPLS transport networks. The protocol defined supports both loss and delay measurement functions for the transport paths.

5.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

6.  Security Considerations

This document does not by itself raise any particular security considerations. Security considerations for each function in the OAM tool-set need to be documented in the document that specifies the particular functionality.

7.  Acknowledgements

The editors wish to thank the MPLS-TP Design Team members, from both the IETF and ITU-T leadership teams, in formulating the recommendations documented here. In particular, we would like to thank Loa Andersson, Huub van Helvoort, and the Area Directors for their suggestions and enhancements to the text.

8. Normative References

Authors' Addresses