Network Working Group N. Sprecher Internet-Draft Nokia Siemens Networks Intended status: Informational L. Fang Expires: April 14, 2012 Cisco October 12, 2011 An Overview of the OAM Tool Set for MPLS based Transport Networks draft-ietf-mpls-tp-oam-analysis-06.txt Abstract This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in [MPLS-TP OAM Reqs] and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. 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 April 14, 2012. Sprecher & Fang Expires April 14, 2012 [Page 1] Internet-Draft OAM Tool Set October 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. Sprecher & Fang Expires April 14, 2012 [Page 2] Internet-Draft OAM Tool Set October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Basic OAM Infrastructure Functionality . . . . . . . . . . . . 6 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 8 3.1. Continuity Check and Connectivity Verification . . . . . . 8 3.1.1. Documents for CC-V tools . . . . . . . . . . . . . . . 8 3.2. Remote Defect Indication . . . . . . . . . . . . . . . . . 9 3.2.1. Documents for RDI . . . . . . . . . . . . . . . . . . 9 3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 9 3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 9 3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 10 3.5.1. Documents for Lock Instruct . . . . . . . . . . . . . 10 3.6. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 10 3.6.1. Documents for Lock Reporting . . . . . . . . . . . . . 10 3.7. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7.1. Documents for Diagnostic Testing . . . . . . . . . . . 11 3.8. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11 3.8.1. Documents for Packet Loss Measurement . . . . . . . . 11 3.9. Packet Delay Measurement . . . . . . . . . . . . . . . . . 11 3.9.1. Documents for Delay Measurement . . . . . . . . . . . 12 4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 12 5. OAM Toolset Applicability and Utilization . . . . . . . . . . 14 5.1. Connectivity Check and Connectivity Verification . . . . . 14 5.2. Diagnostic Tests and Lock Instruct . . . . . . . . . . . . 15 5.3. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Alarm Reporting and Link Down Indication . . . . . . . . . 16 5.5. Remote Defect Indication . . . . . . . . . . . . . . . . . 16 5.6. Packet Loss and Delay Measurement . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Sprecher & Fang Expires April 14, 2012 [Page 3] Internet-Draft OAM Tool Set October 2011 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], in general, and [MPLS-TP OAM Reqs], in particular, define a set of requirements for OAM functionality for MPLS-Transport Profile (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: o The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets. o The OAM operational experience should be similar to that in other transport networks. o The OAM toolset developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [MPLS-TP OAM Reqs]. The MPLS-TP OAM toolset is based on the following existing tools: o LSP-Ping as defined in [LSP Ping]. o Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD] and refined in [MPLS BFD]. o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has been used for functionality guidelines for the performance measurement tools that were not previously supported in MPLS. It should be noted that certain extensions and adjustments have been specified relative to the existing MPLS tools, in order to conform to the transport environment and the requirements of MPLS-TP. However, compatibility with the existing tools has been maintained. This document provides an overview of the MPLS-TP OAM toolset, which consists of tools for MPLS-TP fault management and performance monitoring. This overview includes a brief recap of MPLS-TP OAM Sprecher & Fang Expires April 14, 2012 [Page 4] Internet-Draft OAM Tool Set October 2011 requirements and functions, and of the generic mechanisms used to support the MPLS-TP OAM operation. The protocol definitions for each individual MPLS-TP OAM tool are specified in separate RFCs (or Working Group documents while this document is work in progress), which are referenced by this document. In addition, the document includes a table that cross-references the solution documents to the OAM functionality supported. Finally, the document presents the applicability and utilization of each tool in the MPLS-TP OAM toolset. 1.2. Contributing Authors Elisa Bellagamba Ericsson Yaacov Weingarten Nokia Siemens Networks Dan Frost Cisco Nabil Bitar Verizon Raymond Zhang Alcatel Lucent Lei Wang Telenor Kam Lee Yap XO Communications John Drake Juniper Yaakov Stein RAD Anamaria Fulignoli Ericsson Italo Busi Alcatel Lucent Huub van Helvoort Huawei Thomas Nadeau Computer Associate Henry Yu TW Telecom Mach Chen Huawei Manuel Paul Deutsche Telekom Sprecher & Fang Expires April 14, 2012 [Page 5] Internet-Draft OAM Tool Set October 2011 1.3. Acronyms This draft uses the following acronyms: ACH Associated Channel Header AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC-V Continuity Check and Connectivity Verification FM Fault Management G-ACh Generic Associated Channel GAL G-ACh Label GMPLS Generalized Multi-Protocol Label Switching IANA Internet Assigned Names Authority LDI Link Down Indication LKR Lock Report LM Loss Measurement LOC Loss of Continuity LSP Label Switched Path MEP Maintenance Entity Group End Point MEG Maintenance Entity Group MIP Maintenance Entity Group Intermediate Point MPLS MultiProtocol Label Switching MPLS-TP Transport Profile for MPLS OAM Operations, Administration, and Maintenance PM Performance Monitoring PW Pseudowire RDI Remote Defect Indication SLA Service Level Agreement TLV Type, Length, Value VCCV Virtual Circuit Connectivity Verification 2. Basic OAM Infrastructure Functionality [MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture and general principles of operations, which are evaluated below: [MPLS-TP OAM Reqs] requires that -- o OAM mechanisms in MPLS-TP are independent of the transmission media and of the client service being emulated by the PW. o 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 toolset 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 independent of IP Sprecher & Fang Expires April 14, 2012 [Page 6] Internet-Draft OAM Tool Set October 2011 forwarding and routing. o all OAM protocols support identification information, at least in the form of IP addressing structure and be extensible to support additional identification schemes. o 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 packets. Inherent in this requirement is the principle that full operation of the MPLS-TP OAM must be possible independently of the control or management plane used to operate the network. o there is a single OAM solution and that OAM capabilities for LSPs, PWs, and Sections are consistent. o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to- point co-routed bidirectional LSPs, point-to-point bidirectional Sections, point-to-point associated bidirectional LSPs, point-to- point unidirectional LSPs, and point-to-multipoint LSPs. In addition, MPLS-TP OAM supports these LSPs and PWs when they span either a single or multiple domains. o OAM packets may be directed to an intermediate point of a LSP/PW. The following document-set addresses the basic requirements listed above: o The [MPLS-TP OAM Frwk] 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. o The [MPLS G-ACH] document specifies the use of the MPLS-TP in-band control channels. It generalizes the applicability of the Pseudowire (PW) Associated Channel Header (ACH) to MPLS LSPs and Sections, by defining a Generic Associated Channel (G-ACh). The G-ACh allows control packets to be multiplexed transparently over LSPs and sections, similar to that of PW VCCV [PW VCCV]. The Generic Association Label (GAL) is defined by assigning a reserved MPLS label value and is used to identify the OAM control packets. The value of the ACH Channel Type field indicates the specific protocol carried on the associated control channel. Each MPLS-TP OAM protocol has an IANA assigned channel type allocated to it. Sprecher & Fang Expires April 14, 2012 [Page 7] Internet-Draft OAM Tool Set October 2011 o The creation of G-ACh and GAL provided the necessary mechanisms to allow OAM packets run in-band and share their fate with data packets. It is expected that all of the OAM protocols will be used in conjunction with this Generic Associated Channel. o The [MPLS TP Idents] document provides an IP-based identifier set for MPLS-TP that can be used to identify the transport entities in the network and referanced by the different OAM protocols. [TP-Loss-Delay-Profile] augments that set of identifiers to include identifier information in a format used by the ITU-T. Other spaces may be deifned as well. 3. MPLS-TP OAM Functions The following sections discuss the OAM functions that are required in [MPLS-TP OAM Reqs] and expanded upon in [MPLS-TP OAM Frwk]. 3.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification (CC-V) are OAM operations generally used in tandem, and complement each other. These functions are generally run proactively, but may also be used on-demand for diagnoses of a specific condition. Proactively [MPLS-TP OAM Reqs] states that the function should allow the MEPs to monitor the liveliness and connectivity of a transport path (LSP, PW or a section) between them. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. Note that as specified in sections 3.3 and 3.4 of [MPLS-TP OAM Frwk], a MEP and a MIP can reside in an unspecified location within a node, or in a particular interface on a specific side of the forwarding engine. The [MPLS-TP OAM Frwk] 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 proactively 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] defines BFD extensions to support proactive CC-V applications. [Demand CV] provides LSP-Ping extensions that are used to implement on-demand Connectivity Verification. Both of these tools will be used within the framework of the basic Sprecher & Fang Expires April 14, 2012 [Page 8] Internet-Draft OAM Tool Set October 2011 tools described above, in section 2. 3.2. Remote Defect Indication Remote Defect Indication (RDI) is used by a path end-point to report that a defect is detected on a bi-directional connection to its peer end-point. [MPLS-TP OAM Reqs] points out that this function may be applied to a unidirectional LSP only if a return path exists. [MPLS-TP OAM Frwk] points out that this function is associated with the proactive CC-V function. 3.2.1. Documents for RDI The [Pro CC-V] 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] defines that there is a need for functionality that would allow a path end-point to identify the intermediate (if any) and end-points of the path (LSP, PW or a section). 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] 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 (LSP or PW), that becomes aware of a fault on the path, to report to the end-points of the path. [MPLS-TP OAM Frwk] states that this may occur as a result of a defect condition discovered at a server layer. The intermediate point 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]. 3.4.1. Documents for Alarm Reporting MPLS-TP defines a new protocol to address this functionality that is documented in [Fault Mng]. This protocol uses all of the basic mechanisms detailed in Section 2. Sprecher & Fang Expires April 14, 2012 [Page 9] Internet-Draft OAM Tool Set October 2011 3.5. 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 (LSP, PW or section). The tool is necessary to support single- side provisioning for administrative locking, according to [MPLS-TP OAM Frwk]. This function is used on-demand. 3.5.1. Documents for Lock Instruct The [LiLoopback] document describes the details of a new ACH based protocol format for this functionality. 3.6. Lock Reporting Lock reporting, defined in [MPLS-TP OAM Reqs], 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 (LSP or PW) that an administrative lock condition exists for this transport path. 3.6.1. Documents for Lock Reporting MPLS-TP defines a new protocol to address this functionality that is documented in [Fault Mng]. This protocol uses all of the basic mechanisms detailed in Section 2. 3.7. Diagnostic The [MPLS-TP OAM Reqs] indicates that there is need to provide a OAM function that would enable conducting different diagnostic tests on a PW, LSP, or Section. The [MPLS-TP OAM Frwk] provides two types of specific tests to be used through this functionality: o Throughput Estimation - allowing the provider to verify the bandwidth/throughput of a transport path. This is an out-of- service tool, that uses special packets of varying sizes to test the actual bandwidth and/or throughput of the path. o Data-plane loopback - this out-of-service tool causes all traffic that reaches the target node, either a MEP or MIP, to be looped back to the originating MEP. For targeting MIPs, a co-routed bi- directional path is required. Sprecher & Fang Expires April 14, 2012 [Page 10] Internet-Draft OAM Tool Set October 2011 3.7.1. Documents for Diagnostic Testing The [LiLoopback] document describes the details of a new ACH based protocol format for the Data-plane loopback functionality. The tool for Throughput Estimation tool is under study. 3.8. Packet Loss Measurement Packet Loss Measurement is required by [MPLS-TP OAM Reqs] 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] 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] document describes the protocol formats and procedures for using the tool and enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [TP-Loss-Delay-Profile] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. Note that the tool logic is based on the behavior of the parallel function described in [Y.1731]. 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]. Where: o 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. o 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] describes how the tool could be performed (both in Sprecher & Fang Expires April 14, 2012 [Page 11] Internet-Draft OAM Tool Set October 2011 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] document describes the protocol formats and procedures for using the tool and enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [TP-Loss-Delay-Profile] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. Note that the tool logic is based on the behavior of the parallel function described in [Y.1731]. 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 (IETF RFCs or Internet drafts while this document is work in progress) for the initial phase of the specification of MPLS based transport networks is provided below. Editor's note: Only RFCs will be referenced in the final version of the document. [MPLS G-ACH] provides a specification of the basic structure of protocol messages for in-band data plane OAM in an MPLS environment. [MPLS TP Idents] provides definitions of different formats that may be used within OAM protocol messages to identify the network elements of a MPLS based transport network. The following table (Table 1) provides the summary of proactive MPLS-TP OAM Fault Management toolset functions, associated tool/ protocol, and the corresponding IETF RFCs or Internet drafts where they are defined. Sprecher & Fang Expires April 14, 2012 [Page 12] Internet-Draft OAM Tool Set October 2011 +------------------------+----------------------------+-------------+ | OAM Functions | OAM Tools/Protocols | RFCs / | | | | Internet | | | | Drafts | +------------------------+----------------------------+-------------+ | Continuity Check and | Bidirectional Forwarding | [Pro CC-V] | | Connectivity | Detection (BFD) | | | Verification | | | +------------------------+----------------------------+-------------+ | Remote Defect | Flag in Bidirectional | [Pro CC-V] | | Indication (RDI) | Forwarding Detection (BFD) | | | | message | | +------------------------+----------------------------+-------------+ | Alarm Indication | G-ACh bases AIS message | [Fault Mng] | | Signal (AIS) | | | +------------------------+----------------------------+-------------+ | Link Down Indication | Flag in AIS message | [Fault Mng] | | (LDI) | | | +------------------------+----------------------------+-------------+ | Lock Reporting (LKR) | G-ACh bases LKR message | [Fault Mng] | +------------------------+----------------------------+-------------+ Proactive Fault Management OAM Toolset Table 1 The following table (Table 2) provides an overview of the on-demand MPLS-TP OAM Fault Management toolset functions, associated tool/ protocol, and the corresponding IETF RFCs or Internet drafts where they are defined. +----------------------+-----------------------------+--------------+ | OAM Functions | OAM Tools/Protocols | RFCs / | | | | Internet | | | | Drafts | +----------------------+-----------------------------+--------------+ | Connectivity | LSP Ping | [Demand CV] | | Verification | | | +----------------------+-----------------------------+--------------+ | Diagnostic: Loopback | (1) G-ACh based Loopback | [LiLoopback] | | and Lock Instruct | and Lock Instruct, (2) LSP | | | | Ping | | +----------------------+-----------------------------+--------------+ | Lock Instruct(LI) | Flag in AIS message | [Fault Mng] | +----------------------+-----------------------------+--------------+ On Demand Fault Management OAM Toolset Sprecher & Fang Expires April 14, 2012 [Page 13] Internet-Draft OAM Tool Set October 2011 Table 2 The following table (Table 3) provides the Performance Monitoring Fuctions, asscociated tool/protocol definitions, and corresponding RFCs or Internet Drafts. +------------------+----------------------+-------------------------+ | OAM Functions | OAM Tools/Protocols | RFCs / Internet Drafts | +------------------+----------------------+-------------------------+ | Packet Loss | G-ACh based LM & DM | [Loss-Delay] | | Measurement (LM) | query messages | [TP-Loss-Delay-Profile] | +------------------+----------------------+-------------------------+ | Packet Delay | G-ACh based LM & DM | [Loss-Delay] | | Measurement (DM) | query messages | [TP-Loss-Delay-Profile] | +------------------+----------------------+-------------------------+ | Throughput | derived from Loss | [Loss-Delay] | | Measurement | Measurement | [TP-Loss-Delay-Profile] | +------------------+----------------------+-------------------------+ | Delay Variation | derived from Delay | [Loss-Delay] | | Measurement | Measurement | [TP-Loss-Delay-Profile] | +------------------+----------------------+-------------------------+ Performance Monitoring OAM Toolset Table 3 5. OAM Toolset Applicability and Utilization The following subsections present the MPLS-TP OAM toolset from the perspective of the specified protocols and identifies which of the required functionality is supported by the particular protocol. 5.1. Connectivity Check and Connectivity Verification Proactive Continuity Check and Connectivity Verification (CC-V) functions are used to detect loss of continuity (LOC), and unintended connectivity between two MEPs. Loss of connectivity, mis-merging, mis-connectivity, or unexpected Maintenance Entity Group End Points (MEPs) can be detected using the CC-V tools. The CC-V tools are used to support MPLS-TP fault management, performance management, and protection switching. Proactive CC-V control packets are sent by the source MEP to sink MEP. The sink MEP monitors the arrival of the CC-V control packets and detects the defect. For bidirectional transport paths, the CC-V protocol is, usually, transmitted simultaneously in both directions. Sprecher & Fang Expires April 14, 2012 [Page 14] Internet-Draft OAM Tool Set October 2011 The transmission interval of CC-V control packet can be configured. For example: o 3.3ms is the default interval for protection switching. o 100ms is the default interval for performance monitoring. o 1s is the default interval for fault management. 5.2. Diagnostic Tests and Lock Instruct [LiLoopback] describes a protocol that provides a mechanism is provided to Lock and unlock traffic (e.g. data and control traffic) or specific OAM traffic at a specific LSR on the path of the MPLS-TP LSP to allow loop back of the traffic to the source. These diagnostic functions apply to associated bidirectional MPLS-TP LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels (which is relevant for MPLS-TP dynamic control plane option with GMPLS), and single segment and multi-segment pseudowires. The Lock operation instruction is carried in an MPLS Loopback request message sent from a MEP to a trail-end MEP of the LSP to request that the LSP be taken out of service. In response, the Lock operation reply is carried in a Loopback response message sent from the trail- end MEP back to the originating MEP to report the result. The loopback operations include: o Lock: take an LSP out of service for maintenance. o Unlock: Restore a previously locked LSP to service. o Set_Full_Loopback and Set_OAM_Loopback o Unset_Full_Loopback and Set_OAM_Loopback Operators can use the loopback mode to test the connectivity or performance (loss, delay, delay variation, and throughput) of given LSP up to a specific node on the path of the LSP. 5.3. Lock Reporting The Lock Report (LKR) function is used to communicate to the client (sub-) layer MEPs the administrative locking of a server (sub-) layer MEP, and consequential interruption of data traffic forwarding in the client (sub-) layer. Sprecher & Fang Expires April 14, 2012 [Page 15] Internet-Draft OAM Tool Set October 2011 When operator is taking the LSP out of service for maintenance or other operational reason, using the LKR function can help to distinguish the condition as administrative locking from defect condition. The Lock Report function would also serve the purpose of alarm suppression in the MPLS-TP network above the level at which the Lock has occurred. The receipt of an LKR message MAY be treated as the equivalent of loss of continuity at the client layer. 5.4. Alarm Reporting and Link Down Indication Alarm Indication Signal (AIS) message serves the purpose of alarm suppression upon the failure detection in the server (-sub) layer. When the Link Down Indication (RDI) is set, the AIS message MAY be used to trigger recovery mechanisms. When a server MEP detects the failure, it asserts Loss of Continuity (LOC) or signal fail which sets the flag up to generate OAM packet with AIS message. The AIS message is forwarded to downstream sink MEP in the client layer. This would enable the client layer to suppress the generation of secondary alarms. A Link Down Indication (LDI) flag is defined in the AIS message. The LDI flag is set in the AIS message in response to detecting a fatal failure in the server layer. Receipt of an AIS message with this flag set MAY be interpreted by a MEP as an indication of signal fail at the client layer. Fault OAM messages are generated by intermediate nodes where an LSP is switched, and propagated to the end points (MEPs). From a practical point of view, when both proactive Continuity Check functions and LDI are used, one may consider running the proactive Continuity Check functions at a slower rate (e.g. longer BFD hello intervals), and reply on LDI to trigger fast protection switch over upon failure detection in a given LSP. 5.5. Remote Defect Indication Remote Defect Indication (RDI) function enables an End Point to report to the other End Point that a fault or defect condition is detected on the PW, LSP, or Section for which they are the End Points. The RDI OAM function is supported by the use of Bidirectional Forwarding Detection (BFD) Control Packets [cc-cv]. RDI is only used for bidirectional connections and is associated with proactive CC-V Sprecher & Fang Expires April 14, 2012 [Page 16] Internet-Draft OAM Tool Set October 2011 activation. When an end point (MEP) detects a signal failure condition, it sets the flag up by setting the diagnostic field of the BFD control packet to a particular value to indicate the failure condition on the associated PW, LSP, or Section, and transmitting the BFD control packet with the failure flag up to the other end point (its peer MEP). The RDI function can be used to facilitate protection switching by synchronizing the two end points when unidirectional failure occurs and is detected by one end. 5.6. Packet Loss and Delay Measurement The packet loss and delay measurement toolset enables operators to measure the quality of the packet transmission over a PW, LSP, or Section. The loss and delay protocols have the following characteristics and capabilities: o They support measurement of packet loss, delay and throughput over Label Switched Paths (LSPs), pseudowires, and MPLS sections. o The same LM and DM protocols can be used for both continuous/ proactive and selective/on-demand measurement. o The LM and DM protocols use a simple query/response model for bidirectional measurement that allows a single node - the querier - to measure the loss or delay in both directions. o The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can either be carried out at the downstream node(s) or at the querier if an out-of-band return path is available. o The LM and DM protocols do not require that the transmit and receive interfaces be the same when performing bidirectional measurement. o The LM protocol supports both 32-bit and 64-bit counters although for simplicity only 32-bit packet counters are currently included in the MPLS-TP profile. o The LM protocol supports measurement in terms of both packet counts and octet counts although for simplicity only packet counters are currently included in the MPLS-TP profile. Sprecher & Fang Expires April 14, 2012 [Page 17] Internet-Draft OAM Tool Set October 2011 o The LM protocol can be used to measure channel throughput as well as packet loss. o The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes. 6. IANA Considerations This document makes no request of IANA. The OAM tools and functions defined under G-ACh use IANA assigned code points. the codes are defined in the corresponding IETF RFCs Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations This document does not by itself raise any particular security considerations. Security considerations for each function in the OAM toolset need to be documented in the document that specifies the particular functionality. The general security considerations are provided in [MPLS and GMPLS Security Frwk] and [MPLS-TP Security Frwk]. 8. Acknowledgements The discussion on the needed OAM toolset took place, mainly, in the MPLS Interoperability Design Team (the MEAD). A toolset was agreed upon and was reported to the MPLS working group in Stockholm (July 2009) during the IETF (#75) meetings. This was also judged to be the working group consensus. 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. 9. References Sprecher & Fang Expires April 14, 2012 [Page 18] Internet-Draft OAM Tool Set October 2011 9.1. Normative References [LSP Ping] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [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", RFC 4385, February 2006. [PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [MPLS G-ACH] Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic Associated Channel", RFC 5586, June 2009. [MPLS-TP Reqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, "Requirements for the Transport Profile of MPLS", RFC 5654, April 2009. [MPLS-TP OAM Reqs] Vigoureux, M., Betts, M., and D. Ward, "Requirements for OAM in MPLS Transport Networks", RFC 5860, April 2009. [BASE BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, February 2009. [MPLS BFD] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", RFC 5884, June 2008. [MPLS TP Idents] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers", RFC 6370, September 2011. [MPLS-TP OAM Frwk] Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM Framework and Overview", RFC 6371, September 2011. [Loss-Delay] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. Sprecher & Fang Expires April 14, 2012 [Page 19] Internet-Draft OAM Tool Set October 2011 [TP-Loss-Delay-Profile] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks", RFC 6375, September 2011. [Pro CC-V] Allan, D. and G. Swallow, "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", ID draft-ietf-mpls-tp-cc-cv-rdi-06, August 2011. [Demand CV] Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS on-demand Connectivity Verification, Route Tracing and Adjacency Verification", ID draft-ietf-mpls-tp-on-demand-cv-06, August 2011. [Fault Mng] Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault Management OAM", ID draft-ietf-mpls-tp-fault-07, September 2011. [LiLoopback] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, "MPLS Transport Profile Lock Instruct and Loopback Functions", ID draft-ietf-mpls-tp-li-lb-05, September 2011. 9.2. Informative References [MPLS-TP Security Frwk] Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Security Framework", ID draft-ietf-mpls-tp-security-framework-01, May 2011. [MPLS and GMPLS Security Frwk] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [Y.1731] International Telecommunications Union - Standardization, "OAM functions and mechanisms for Ethernet based networks", ITU Y.1731, May 2006. [MPLS TP ITU Idents] Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", ID draft-ietf-mpls-tp-itu-t-identifiers-00, July 2011. Sprecher & Fang Expires April 14, 2012 [Page 20] Internet-Draft OAM Tool Set October 2011 Authors' Addresses Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Luyuan Fang Cisco 111 Wood Avenue South Iselin, NJ 08830 USA Email: lufang@cisco.com Sprecher & Fang Expires April 14, 2012 [Page 21]