MPLS Working Group I. Busi (Ed) Internet Draft Alcatel-Lucent Intended status: Standard Track H. van Helvoort (Ed) J. He (Ed) Huawei Expires: January 2012 July 11, 2011 MPLS-TP OAM based on Y.1731 draft-bhh-mpls-tp-oam-y1731-07.txt Abstract This document describes methods to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [8]. In particular, this document describes the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Busi and al. Expires January 11, 2012 [Page 1] Internet-Draft MPLS-TP OAM based on Y.1731 July 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 BSD License. Busi and al. Expires January 11, 2012 [Page 2] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Table of Contents 1. Introduction.................................................4 1.1. Contributing Authors....................................5 2. Conventions used in this document............................5 2.1. Terminology.............................................6 3. Encapsulation of OAM PDU in MPLS-TP..........................6 4. MPLS-TP OAM Packet Formats...................................7 4.1. Continuity Check Message (CCM)..........................8 4.1.1. MEG ID Formats.....................................9 4.2. OAM Loopback (LBM/LBR)..................................9 4.2.1. Format of MEP and MIP ID TLVs.....................12 4.3. Alarm Indication Signal (AIS)..........................16 4.4. Lock Reporting (LCK)...................................16 4.5. Test (TST).............................................17 4.6. Loss Measurement (LMM/LMR).............................17 4.7. One-way delay measurement (1DM)........................17 4.8. Two-way delay Measurement Message/Reply (DM)...........17 4.9. Client Signal Fail (CSF)...............................18 5. MPLS-TP OAM Procedures......................................18 5.1. Continuity Check Message (MT-CCM) procedures...........18 5.2. OAM Loopback (MT-LBM/LBR) procedures...................20 5.3. Alarm Indication Signal (MT-AIS) procedures............21 5.4. Lock Reporting (LCK)...................................22 5.5. Test (TST).............................................23 5.6. Loss Measurement (LMM/LMR).............................23 5.7. One-way delay measurement (1DM)........................23 5.8. Two-way delay Measurement Message/Reply (DM)...........23 5.9. Client Signal Fail (CSF)...............................23 6. Security Considerations.....................................23 7. IANA Considerations.........................................23 8. Acknowledgments.............................................23 9. References..................................................25 9.1. Normative References...................................25 9.2. Informative References.................................25 Busi and al. Expires January 11, 2012 [Page 3] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 1. Introduction This document describes the method for leveraging Y.1731 [2] Protocol Data Units (PDUs) and procedures to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meet the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [8]. This version of the draft does not introduce any technical change to the -06 version of this draft. ITU-T Recommendation Y.1731 [2] specifies: o OAM PDUs and procedures that meet the transport networks requirements for OAM o Encapsulation mechanisms to carry these OAM PDUs within Ethernet frames to provide Ethernet OAM capabilities in Ethernet networks Although Y.1731 is focused on Ethernet OAM, the definition of OAM PDUs and procedures are technology independent and can also be used in other packet technologies (e.g., MPLS-TP) provided that the technology specific encapsulation is defined. The OAM toolset defined in Y.1731 [2] serves as a benchmark for a high performance, comprehensive suite of packet transport OAM capabilities. It can be provided by lightweight protocol design and supports operational simplicity by providing commonality with the established operation models utilized in other transport network technologies (e.g., SDH/SONET and OTN). This document describes mechanisms for MPLS-TP OAM that reuse the same OAM PDUs and procedures defined in Y.1731 [2], together with the necessary MPLS-TP technology specific encapsulation mechanisms. The advantages offered by this toolset are summarized below: o Simplify the operations for the network operators and service providers that have to test and maintain a single general OAM protocol set when operating LSP, PW and VPLS networks. o Accelerate the market adoption of MPLS-TP since Y.1731 is already mature, supported, and deployed. o Reduce the complexity and increase the reuse of code for implementation in packet transport devices that may support both Busi and al. Expires January 11, 2012 [Page 4] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS applications. It is worth noting that multi-vendor interoperable implementations of the OAM mechanisms described in this document already exist to meet the essential OAM requirements for MPLS-TP deployments in PTN applications as described in [9]. Ethernet OAM is also defined by IEEE 802.1ag [11]. IEEE 802.1ag and ITU-T Y.1731 have been developed in cooperation by IEEE and ITU. They support a common subset of OAM functions. ITU-T Y.1731 further extends this common subset with additional OAM mechanisms that are important for the transport network (e.g. AIS, DM, LM). This document does not deprecate existing MPLS and PW OAM mechanisms nor preclude definition of other MPLS-TP OAM tools. The mechanisms described in this document, when used to provide MPLS-TP PW OAM functions, are open to support the OAM message mapping procedures defined in [9]. In order to support those procedures, the PEs MUST map the states of the procedures defined in Y.1731 to the PW defect states defined in [9]. The mapping procedures are outside the scope of this document. In the rest of this document the term "OAM PDU" is used to indicate an OAM PDU whose format and associated procedures are defined in Y.1731 [2] and that this document proposes to be used to provide MPLS-TP OAM functions. 1.1. Contributing Authors Italo Busi, Huub van Helvoort, Jia He, Christian Addeo, Alessandro D'Alessandro, Simon Delord, John Hoffmans, Ruiquan Jing, Kam Lam, Wang Lei, Han Li, Vishwas Manral, Julien Meuric, Masahiko Mizutani, Philippe Niger, Manuel Paul, Josef Roese, Vincenzo Sestito, Yuji Tochio, Munefumi Tsurusawa, Maarten Vissers, Rolf Winter 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Busi and al. Expires January 11, 2012 [Page 5] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 2.1. Terminology ACH Associated Channel Header G-ACh Generic Associated Channel GAL G-ACh Label ME Maintenance Entity MEL MEG Level MEG Maintenance Entity Group MEP Maintenance End Point MIP Maintenance Intermediate Point PTN Packet Transport Network TLV Type Length Value 3. Encapsulation of OAM PDU in MPLS-TP Although Y.1731 is focused on Ethernet OAM, the definition of OAM PDUs and procedures are technology independent. When used to provide Ethernet OAM capabilities, these PDUs are encapsulated into an Ethernet frame where an Ethernet header is prepended to the OAM PDUs. The MAC DA is used to identify the MEPs and MIPs where the OAM PDU needs to be processed. The EtherType is used to distinguish OAM frames from user data frames. Within MPLS-TP OAM Framework [6], OAM packets are distinguished from user data packets using the GAL and ACH [3] construct and they are addressed to MEPs or MIPs using existing MPLS forwarding mechanisms (i.e. label stacking and TTL expiration). It is therefore possible to reuse the OAM PDUs defined in [2] within MPLS-TP and encapsulate them within ACH. A single ACH Channel Type (0xXXXX) is required to identify the presence of Y.1731 OAM PDU. Within the OAM PDU, the OpCode field, defined in [2], allows identifying the specific OAM PDU. Busi and al. Expires January 11, 2012 [Page 6] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 OAM PDUs are encapsulated using the ACH, according to [3], as described in Figure 1 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Y.1731 Channel Type (0xXXXX) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | OpCode | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | OAM function specific fields | | (Y.1731 based) | + + : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 G-ACh Packet carrying a Y.1731 PDU Moreover, MPLS-TP relies upon a different mechanism for supporting tandem connection monitoring (i.e. label stacking) than the fixed MEL (Maintenance Entity Group Level) field used in Ethernet. Therefore in MPLS-TP the MEL field is allowed not to be used for supporting tandem connection monitoring. When OAM PDUs are used in MPLS-TP, the MEL field MUST be set on transmission and checked at reception for compliancy with Y.1731 [2]. The MEL value to set and check MUST be configurable. The DEFAULT value MUST be "111". With co-routed bidirectional transport paths, the configured MEL MUST be the same in both directions. The OpCode field identifies the type of the OAM PDU. The setting of the Version, Flags and TLV Offset is OpCode specific and described in Y.1731 [2]. 4. MPLS-TP OAM Packet Formats This section describes the OAM functions that can be supported reusing the OAM PDUs and procedures defined in Y.1731 [2] to meet MPLS-TP OAM Requirements, as defined in [8]. Busi and al. Expires January 11, 2012 [Page 7] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 This document is proposing not to use the Y.1731 MCC OAM PDU in MPLS-TP. The solution proposed in [6], where MCC PDU is directly encapsulated within an ACH with a PID, SHOULD be used instead. The LTM/LTR OAM PDUs, as currently defined Y.1731 [2], are tracing the path for a specific MAC address: this tool is therefore addressing a different requirement than the "Route Tracing" functional requirement described in section 2.2.4 of RFC 5860 [8]. Their purpose is to test the MAC Address Forwarding tables. Due to the fact that MPLS-TP forwarding is not based on the MAC Address Forwarding tables, these tools are not applicable to MPLS-TP as currently defined. Procedures for supporting the route tracing MPLS-TP OAM functional requirement (section 2.2.4 of RFC 5860 [8]) are outside the scope of this document. 4.1. Continuity Check Message (CCM) The CCM PDU is defined in Y.1731 [2]. When encapsulated within MPLS- TP as described in section 3, it can be used to support the following MPLS-TP OAM functional requirements: o Pro-active continuity check (section 2.2.2 of RFC 5860 [8]); o Pro-active connectivity verification (section 2.2.3 of RFC 5860 [8]); o Pro-active remote defect indication (section 2.2.9 of RFC 5860 [8]); o Pro-active packet loss measurement (section 2.2.11 of RFC 5860 [8]). Procedures for transmitting and receiving CCM PDUs are defined in Y.1731 [2] and described in section 5.1. It is worth noting that the use of CCM does not require any additional status information other than the configuration parameters and defect states. The transmission period of the CCM MUST always be the configured period and MUST not change unless the operator reconfigures it. This is a fundamental requirement to allow deterministic and predictable Busi and al. Expires January 11, 2012 [Page 8] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 protocol behavior: in transport networks the operator configures and fully controls the repetition rate of pro-active CC-V. In order to perform pro-active Connectivity Verification, the CCM packet contains a globally unique identifier of the source MEP, as described in [6]. The source MEP for LSPs, PWs and Sections is identified by combining a globally unique MEG ID (see section 4.1.1) with a MEP ID that is unique within the scope of the Maintenance Entity Group. 4.1.1. MEG ID Formats The generic format for MEG ID is defined in Figure A-1 of Y.1731 [2]. Different formats of MEG ID are allowed: the MEG ID format type is identified by the MEG ID Format field. The format of the ICC-based MEG ID is defined in Annex A of Y.1731 [2]. This format is applicable to MPLS-TP Sections, LSPs and PWs. MPLS-TP supports also IP-based format for MEG ID. These formats are still under definition in [11] and therefore outside the scope of this document. 4.2. OAM Loopback (LBM/LBR) The LBM/LBR PDUs, defined in Y.1731 [2]. When encapsulated within MPLS-TP, as described in section 3, they can be used to support the following MPLS-TP OAM functional requirements: o On-demand bidirectional connectivity verification (section 2.2.3 of RFC 5860 [8]); o Bidirectional in-service or out-of-service diagnostic test (section 2.2.5 of RFC 5860 [8]). Procedures for transmitting and receiving LBM/LBR PDUs are defined in Y.1731 [2] and described in section 5.2. It is worth noticing that these OAM PDUs cover different functions than those defined in [10]. When the LBM/LBR is used for out-of-service diagnostic test, it is REQUIRED that the transport path is locked on both MEPs before the diagnostic test is performed. In transport networks, the transport Busi and al. Expires January 11, 2012 [Page 9] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 path is locked on both sides by network management operations. However, single-ended procedures as defined in [10] MAY be used. In order to allow proper identification of the target MEP/MIP the LBM is addressed to, the LBM PDU MUST include the Target MEP/MIP ID TLV: this TLV MUST be present in an LBM PDU and MUST be located at the top of the TLVs (i.e., it MUST start at the offset indicated by the TLV Offset field). A LBM packet with the Target MIP/MEP ID equal to the ID of receiving MIP or MEP is considered to be a valid LBM packet. Every field in the LBM packet is copied to the LBR packet, only the OpCode field is changed from LBM to LBR. To allow proper identification of the actual MEP/MIP that has replied to an LBM PDU, the LBR PDU MUST include the Replying MEP/MIP ID TLV: this TLV MUST be present in an LBR PDU and it MUST be located at the top of the TLVs (i.e., it MUST start at the offset indicated by the TLV Offset field). In order to simplify hardware based implementations, these TLVs have been defined to have a fixed position (as indicated by the TLV Offset field) and a fixed length (see clause 4.2.1). It is worth noting that the MEP/MIP identifiers used in the Target MEP/MIP ID and in the Replying MEP/MIP ID TLVs SHOULD be unique within the scope of the MEG. When LBM/LBR OAM is used for connectivity verification purposes, there are some misconnectivity cases that could not be easily located by simply relying upon these TLVs. In order to locate these misconnectivity configurations, the LBM PDU SHOULD carry a Requesting MEP ID TLV that provides a globally unique identification of the MEP that has originated the LBM PDU. When the Requesting MEP ID TLV is present in the LBM PDU, the replying MIP/MEP MUST check that the received requesting MEP identifier matches with the expected requesting MEP identifier before replying. In this case, the LBR PDU MUST carry the Requesting MEP ID TLV confirming to the MEP the LBR PDU is sent to that the Requesting MEP ID TLV in the LBM PDU has been checked before replying. When LBM/LBR OAM is used for bidirectional diagnostic tests, the Requesting MEP ID TLVs MUST NOT be included. The format of the LBM and LBR PDUs are shown in Figure 2 and in Figure 3. Busi and al. Expires January 11, 2012 [Page 10] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Y.1731 Channel Type (0xXXXX) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | OpCode | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID/Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target MEP/MIP ID TLV | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [optional Requesting MEP ID TLV] | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [other optional TLV starts here] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End TLV | +-+-+-+-+-+-+-+-+-+ Figure 2 LBM Packet Format The OpCode MUST be set to 0x03 (LBM). The TLV Offset MUST be set to 0x04. The formats of the Target MEP/MIP ID TLV and of the Requesting MEP ID TLV are defined in 4.2.1. The Target MEP/MIP ID MUST be always present as the first TLV within the LBM PDU. When present, the Requesting MEP ID TLV MUST immediately follow the Target MEP/MIP ID TLV. When the LBM packet is sent to a target MIP, the source MEP MUST know the hop count to the target MIP and set the TTL field accordingly, as described in [6]. This solution allows supporting per-node and per-interface MIP implementations as described in section 3.4 of [6]: o In the case of a per-node MIP implementation, the LBM packet is processed in the per-node MIP if the Target MEP/MIP ID matches the per-node MIP identifier; otherwise, the LBM packet is dropped; Busi and al. Expires January 11, 2012 [Page 11] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 o In the case of a per-interface MIP implementation, the LBM packet is processed in the ingress MIP if the Target MEP/MIP ID matches the ingress MIP identifier; otherwise, the LBM packet is forwarded to the egress port(s) together (i.e., fate sharing) with the user data packets. The LBM packet is processed in the egress MIP if the Target MEP/MIP ID matches the egress MIP identifier; otherwise, the LBM packet is dropped. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Y.1731 Channel Type (0xXXXX) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | OpCode | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID/Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replying MEP/MIP ID TLV | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [optional Requesting MEP ID TLV] | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [other optional TLV starts here] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End TLV | +-+-+-+-+-+-+-+-+-+ Figure 3 LBR Packet Format The Replying MEP/MIP ID TLV MUST be present as the first TLV within the LBR PDU. When present, the Requesting MEP ID TLV MUST follow the Replying MEP/MIP ID TLV within the LBR PDU. 4.2.1. Format of MEP and MIP ID TLVs The format of the Target and Replying MIP/MEP ID TLVs are shown in Figure 4 and Figure 5. Busi and al. Expires January 11, 2012 [Page 12] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x21) | Length (25) | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | MEP/MIP Identifier (format is ID Sub-Type specific) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Target MEP/MIP ID TLV format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x22) | Length (25) | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | MEP/MIP Identifier (format is ID Sub-Type specific) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Replying MEP/MIP ID TLV format Different formats of MEP/MIP identifiers MAY be used: the format type is described by the MEP/MIP ID Sub-Type field. The "Discovery ingress/node MEP/MIP" and the "Discovery egress MEP/MIP" identifiers MAY only be used within the LBM PDU (and MUST NOT appear in an LBR PDU) for discovering the identifiers of the MEPs or of the MIPs located at a given TTL distance from the MEP originating the LBM PDU. The format of the Target MEP/MIP ID TLV carrying a "Discovery ingress/node MEP/MIP" is shown in Figure 6. Busi and al. Expires January 11, 2012 [Page 13] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x21) | Length (25) |Sub-Type (0x00)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | MUST be ZERO | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Target MEP/MIP ID TLV format (discovery ingress/node MEP/MIP) The format of the Target MEP/MIP ID TLV carrying a "Discovery egress MEP/MIP" is shown in Figure 7. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x21) | Length (25) |Sub-Type (0x01)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | MUST be ZERO | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Target MEP/MIP ID TLV format (discovery egress MEP/MIP) The format of the Target or Replying MEP/MIP ID TLV carrying an "ICC-based MEP ID" is shown in Figure 8. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length (25) |Sub-Type (0x02)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEP ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | | MUST be ZERO | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 Target or Replying MEP/MIP ID TLV format (ICC-based MEP ID) Busi and al. Expires January 11, 2012 [Page 14] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 The MEP ID is a 16-bit integer value identifying the transmitting MEP within the MEG. The format of the Target or Replying MEP/MIP ID TLV carrying an "ICC-based MIP ID" is shown in Figure 9. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length (25) |Sub-Type (0x03)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU-T Carrier Code (ICC) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Node-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node-ID | IF-Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IF-Num | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | | MUST be ZERO | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 Target or Replying MEP/MIP ID TLV format (ICC-based MIP ID) The ITU-T Carrier Code (ICC) is a code assigned to a network operator/service provider and maintained by the ITU-T Telecommunication Standardization Bureau (TSB) as per [13]. The Node-ID is a numeric identifier of the node where the MIP is located. Its assignment is a matter for the organization to which the ICC has been assigned, provided that uniqueness within that organization is guaranteed. The IF-Num is a numeric identifier of the Access Point (AP) toward the server layer trail, which can be either an MPLS-TP or a non MPLS-TP server layer, where a per-interface MIP is located. Its assignment is a matter for the node the MIP is located, provided that uniqueness within that node is guaranteed. Note that the value 0 for IF-Num is reserved to identify per-node MIPs. MPLS-TP supports also IP-based format for MIP and MEP identifiers. These formats are still under definition in [11] and therefore outside the scope of this document. Busi and al. Expires January 11, 2012 [Page 15] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 The format of the Requesting MEP ID TLVs is shown in Figure 10. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x23) | Length (53) | Loopback Ind. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEP ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | MEG ID | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved (0x0000) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10Requesting MEP ID TLV format The MEP ID and MEG ID carry the globally unique MEP ID as defined in section 4.1.1. The Reserved bits MUST be set to all-ZEROes in transmission and ignored in reception. The Loopback Indication MUST be set to 0x0000 when this TLV is inserted in an LBM PDU and SHOULD be set to 0x0001 in the LBR PDU. This is used to indicate that the value of this TLV has been checked by the node that generated the LBR PDU. 4.3. Alarm Indication Signal (AIS) The AIS PDU is defined in Y.1731 [2]. When encapsulated within MPLS- TP, as described in section 3, it can be used to support the alarm reporting MPLS-TP OAM functional requirement (section 2.2.8 of RFC 5860 [8]). Procedures for transmitting and receiving AIS PDUs are defined in Y.1731 [2] and described in section 5.3. 4.4. Lock Reporting (LCK) The LCK PDU is defined in Y.1731 [2]. When encapsulated within MPLS- TP, as described in section 3, it can be used to support the lock reporting MPLS-TP OAM functional requirement (section 2.2.7 of RFC 5860 [8]). Busi and al. Expires January 11, 2012 [Page 16] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Procedures for transmitting and receiving LCK PDUs are defined in Y.1731 [2] and described in section 5.4. 4.5. Test (TST) The TST PDU is defined in Y.1731 [2]. When encapsulated within MPLS- TP, as described in section 3, it can be used to support the uni-directional in-service or out-of-service diagnostic tests MPLS-TP OAM functional requirement (section 2.2.8 of RFC 5860 [8]). Procedures for transmitting and receiving TST PDUs are defined in Y.1731 [2] and described in section 5.5. 4.6. Loss Measurement (LMM/LMR) The LMM/LMR PDUs are defined in Y.1731 [2]. When encapsulated within MPLS-TP, as described in section 3, they can be used to support on- demand packet loss measurement MPLS-TP OAM functional requirement (section 2.2.11 of RFC 5860 [8]). Procedures for transmitting and receiving LMM/LMR PDUs are defined in Y.1731 [2] and described in section 5.6. 4.7. One-way delay measurement (1DM) The 1DM PDU is defined in Y.1731 [2]. When encapsulated within MPLS- TP, as described in section 3, it can be used to support the on- demand one-way packet delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]). It can also be used to support proactive one-way delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]). Procedures for transmitting and receiving 1DM PDUs are defined in Y.1731 [2] and described in section 5.7. 4.8. Two-way delay Measurement Message/Reply (DM) The DMM/DMR PDUs are defined in Y.1731 [2]. When encapsulated within MPLS-TP, as described in section 3, they can be used to support on- demand two-ways packet delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]). Busi and al. Expires January 11, 2012 [Page 17] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 They can also be used to support proactive two-ways packet delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]). Procedures for transmitting and receiving DMM/DMR PDUs are defined in Y.1731 [2] and described in section 5.8. 4.9. Client Signal Fail (CSF) The CSF PDU is defined in Y.1731 Amendment 1 [3]. When encapsulated within MPLS-TP, as described in section 3, it can be used to support the client failure indication MPLS-TP OAM functional requirement (section 2.2.10 of RFC 5860 [8]). Procedures for transmitting and receiving CSF PDUs are defined in Y.1731 [3] and described in section 5.9. 5. MPLS-TP OAM Procedures The high level procedures for processing Y.1731 OAM PDUs are described in [2] and [3]. The technology independent procedures are also applicable to MPLS-TP OAM. More detailed and formal procedures for processing Y.1731 OAM PDUs are defined in G.8021 [4]. Although the description in [4] is Ethernet-specific, the technology independent procedures are also applicable to MPLS-TP OAM. This section describes the MPLS-TP OAM procedures based on the technology independent ones defined in [2], [3] and [4]. 5.1. Continuity Check Message (MT-CCM) procedures The MT-CCM PDU format is defined in section 4.1. When CCM generation is enabled, the MEP MUST generate CCM OAM packets with the periodicity and the PHB configured by the operator: o MEL field MUST be set to the configured value (see section 3); o Version field MUST be set to 0 (see section 3); o OpCode field MUST be set to 0x01 (see section 4.1); Busi and al. Expires January 11, 2012 [Page 18] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 o RDI flag MUST be set, if the MEP asserts signal file. Otherwise, it MUST be cleared; o Reserved flags MUST be set to 0 (see section 4.1); o Period field MUST be set according to the configured periodicity (see Table 9-3 of [2]); o TLV Offset field MUST be set to 70 (see section 4.1); o Sequence Number MUST be set to 0 (see section 4.1); o MEP ID and MEG ID fields MUST carry the configured values; o The TxFCf field MUST carry the current value of the counter for in-profile data packets transmitted towards the peer MEP, when pro-active loss measurement is enabled. Otherwise it MUST be set to 0. o The RxFCb field MUST carry the current value of the counter for in-profile data packets received from the peer MEP, if pro-active loss measurement is enabled. Otherwise it MUST be set to 0. o The TxFCb field MUST carry the value of TxFCf of the last received CCM PDU from the peer MEP, if pro active loss measurement is enabled. Otherwise it MUST be set to 0. o Reserved field MUST be set to 0 (see section 4.1); o End TLV MUST be inserted after the Reserved field (see section 4.1). The transmission period of the CCM is always the configured period and does not change unless the operator reconfigures it. When a MEP receives a CCM OAM packet, it checks the various fields (see Figure 8-19 of [4]). The following defects are detected as described in clause 6.1 of [4]: dLOC, dUNL, dMMG, dUNM, dUNP, dUNPr and dRDI. If the Version, MEL, MEG and MEP fields are valid and pro-active loss measurement is enabled, the values of the packet counters are processed as described in clause 8.1.7.4 of [4]. Busi and al. Expires January 11, 2012 [Page 19] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 5.2. OAM Loopback (MT-LBM/LBR) procedures The MT-LBM/LBR PDU formats are defined in section 4.2. When an out-of-service OAM loopback function is performed, client data traffic is disrupted in the diagnosed ME. The MEP configured for the out-of-service test MUST transmit MT-LCK packets in the immediate client (sub-)layer, as described in section 5.4. When an in-service OAM loopback function is performed, client data traffic is not disrupted and the packets with MT-LBM/LBR information are transmitted in such a manner that a limited part of the service bandwidth is utilized. The periodicity for packets with MT-LBM/LBR information is pre-determined. When on-demand OAM loopback is enabled at a MEP, the (requesting) MEP MUST generate and send to one of the MIPs or the peer MEP MT-LBM OAM packets with the periodicity and the PHB configured by the operator: o MEL field MUST be set to the configured value (see section 3); o Version field MUST be set to 0 (see section 3); o OpCode field MUST be set to 0x03 (see section 4.2); o Flags field MUST be set to all-ZEROes (see section 4.2); o TLV Offset field MUST be set to 4 (see section 4.2); o Transaction field is a 4-octet field that contains the transaction ID/sequence number for the loop-back measurement; o Target MEP/MIP-ID and Originator MEP-ID fields are set to carry the configured values; o Optional TLV field whose length and contents are configurable at the requesting MEP. The contents can be a test pattern and an optional checksum. Examples of test patterns include pseudo-random bit sequence (PRBS) (2^31-1) as specified in sub-clause 5.8/O.150, all '0' pattern, etc. For bidirectional diagnostic test application, configuration is required for a test signal generator and a test signal detector associated with the MEP; o End TLV field is set to all-ZEROes (see section 4.2). Busi and al. Expires January 11, 2012 [Page 20] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Whenever a valid MT-LBM packet is received by a (receiving) MIP or a (receiving) MEP, an MT-LBR packet is generated and transmitted by the receiving MIP/MEP to the requesting MEP: o MEL field MUST be copied from the received MT-LBM PDU; o Version field MUST be copied from the received MT-LBM PDU; o OpCode field MUST be set to 2 (see section 4.2); o Flags field MUST be copied from the received MT-LBM PDU; o TLV Offset field MUST be copied from the received MT-LBM PDU; o Transaction field MUST be copied from the received MT-LBM PDU o The Target MEP/MIP-ID and Originator MEP-ID fields are is set to the value which is copied from the last received MT-LBM PDU; o The Optional TLV field MUST be copied from the received MT-LBM PDU; o End TLV field MUST be inserted after the last TLV field and it MUST be copied from the last received MT-LBM PDU. 5.3. Alarm Indication Signal (MT-AIS) procedures The MT-AIS PDU format is described in section 4.3. When the server layer trail termination sink asserts signal fail, it notifies the server/MT_A_Sk function that raises the aAIS consequent action. The aAIS is cleared when the server layer trail termination clears the signal fail condition and notifies the server/MT_A_Sk. When the aAIS consequent action is raised, the server/MT_A_Sk MUST continuously generate MPLS-TP OAM packets carrying the AIS PDU until the aAIS consequent action is cleared: o MEL field MUST be set to the configured value (see section 3): o Version field MUST be set to 0 (see section 3): o OpCode MUST be set to 0x21 (see section 4.3): o Reserved flags MUST be set to 0 (see section 4.3): Busi and al. Expires January 11, 2012 [Page 21] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 o Period field MUST be set according to the configure periodicity (see Table 9-4 of [2]); o TLV Offset MUST be set to 0 (see section 4.3): o End TLV MUST be inserted after the TLV Offset field (see section 4.3). The DEFAULT periodicity for MT-AIS is once per second. The generated AIS packets MUST be inserted in the incoming stream, i.e., the output stream contains the incoming packets and the generated AIS packets. When a MEP receives an AIS packet with the correct MEL value, it MUST detect the dAIS defect as described in clause 6.1 of [4]. 5.4. Lock Reporting (LCK) The MT-LCK PDU format is described in section 4.4. When the access to the server layer trail is administratively locked by the operator, the server/MT_A_So and server/MT_A_Sk functions raise the aLCK consequent action. The aLCK is cleared when the access to the server layer trail is administratively unlocked. When the aLCK consequent action is raised, the server/MT_A_So and server/MT_A_Sk MUST continuously generate, on both directions, MPLS-TP OAM packets carrying the LCK PDU until the aLCK consequent action is cleared: o MEL field MUST be set to the configured value (see section 3): o Version field MUST be set to 0 (see section 3): o OpCode MUST be set to 0x23 (see section 4.4): o Reserved flags MUST be set to 0 (see section 4.4): o Period field MUST be set according to the configure periodicity (see Table 9-4 of [2]); o TLV Offset MUST be set to 0 (see section 4.4): Busi and al. Expires January 11, 2012 [Page 22] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 o End TLV MUST be inserted after the TLV Offset field (see section 4.4). The DEFAULT periodicity for MT-LCK is once per second. When a MEP receives an LCK packet with the correct MEL value, it detects the dLCK defect as described in clause 6.1 of [4]. 5.5. Test (TST) 5.6. Loss Measurement (LMM/LMR) 5.7. One-way delay measurement (1DM) 5.8. Two-way delay Measurement Message/Reply (DM) 5.9. Client Signal Fail (CSF) 6. Security Considerations Spurious OAM messages, such as those defined in this document, potentially could form a vector for a denial of service attack. However, since these messages are carried in a control channel, one would have to gain access to a node providing the service in order to launch such an attack. Since transport networks are usually operated as a walled garden, such threats are less likely. 7. IANA Considerations IANA is requested to allocate a Channel Type value 0xXXXX to identify an associated channel carrying all the OAM PDUs that are defined in section 4 [Editor's note - The value 0x8902 has been proposed to keep the channel type identical to the EtherType value used in Ethernet OAM] 8. Acknowledgments The authors gratefully acknowledge the contributions of Malcolm Betts, Zhenlong Cui, Feng Huang, Kam Lam, Jian Yang, Haiyan Zhang for the definition of extensions to LBM/LBR required for supporting on-demand connectivity verification OAM functions. The authors would like to thank all the members of the CCSA for their comments and support. Busi and al. Expires January 11, 2012 [Page 23] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 The authors would also like to thank Brian Branscomb, Feng Huang, Kam Lam, Fang Li, Akira Sakurai and Yaakov Stein for their comments and enhancements to the text. This document was prepared using 2-Word-v2.0.template.dot. Busi and al. Expires January 11, 2012 [Page 24] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] ITU-T Recommendation Y.1731 (02/08), "OAM functions and mechanisms for Ethernet based networks", February 2008 [3] ITU-T Recommendation Y.1731 Amendment 1 (07/10), "OAM functions and mechanisms for Ethernet based networks", July 2010 [4] ITU-T Recommendation G.8021 (12/07), "Characteristics of Ethernet transport network equipment functional blocks", December 2007 [5] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., "MPLS Generic Associated Channel", RFC 5586, June 2009 [6] Busi, I., Allan, D., " Operations, Administration and Maintenance Framework for MPLS-based Transport Networks", draft-ietf-mpls-tp-oam-framework-11 (work in progress), February 2011 [7] Beller, D., Farrel, A., "An Inband Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010 9.2. Informative References [8] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010 [9] Li, F., Li, H., D'Alessandro, A., Jing, R., Wang, G., "Operator Considerations on MPLS-TP OAM Mechanisms", draft-fang-mpls-tp-oam-considerations-02 (work in progress), July 2011 [10] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3-oam-msg-map-16 (work in progress), April 2011 [11] Boutros, S., et al., "Operating MPLS Transport Profile LSP in Loopback Mode", draft-ietf-mpls-tp-li-lb-02 (work in progress), June 2011 Busi and al. Expires January 11, 2012 [Page 25] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 [12] Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-ietf- mpls-tp-identifiers-02 (work in progress), July 2010 [13] ITU-T Recommendation M.1400 (07/06), " Designations for interconnections among operators' networks", July 2006 [14] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and Metropolitan Area Networks: Connectivity Fault Management", September 2007 Author's Addresses Italo Busi (Editor) Alcatel-Lucent Email: Italo.Busi@alcatel-lucent.com Huub van Helvoort (Editor) Huawei Technologies Email: huub.van.helvoort@huawei.com Jia He (Editor) Huawei Technologies Email: hejia@huawei.com Contributing Authors' Addresses Christian Addeo Alcatel-Lucent Email: Christian.Addeo@alcatel-lucent.com Alessandro D'Alessandro Telecom Italia Email: alessandro.dalessandro@telecomitalia.it Busi and al. Expires January 11, 2012 [Page 26] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Simon Delord Telstra Email: simon.a.delord@team.telstra.com John Hoffmans KPN Email: john.hoffmans@kpn.com Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn Hing-Kam (Kam) Lam Alcatel-Lucent Email: Kam.Lam@alcatel-lucent.com Wang Lei China Mobile Communications Corporation Email: wangleiyj@chinamobile.com Han Li China Mobile Communications Corporation Email: lihan@chinamobile.com Vishwas Manral IPInfusion Inc Email: vishwas@ipinfusion.com Busi and al. Expires January 11, 2012 [Page 27] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Masahiko Mizutani Hitachi, Ltd. Email: masahiko.mizutani.ew@hitachi.com Manuel Paul Deutsche Telekom Email: Manuel.Paul@telekom.de Josef Roese Deutsche Telekom Email: Josef.Roese@t-systems.com Vincenzo Sestito Alcatel-Lucent Email: vincenzo.sestito@alcatel-lucent.com Yuji Tochio Fujitsu Email: tochio@jp.fujitsu.com Munefumi Tsurusawa KDDI R&D Labs Email: tsuru@kddilabs.jp Maarten Vissers Huawei Technologies Email: maarten.vissers@huawei.com Busi and al. Expires January 11, 2012 [Page 28] Internet-Draft MPLS-TP OAM based on Y.1731 July 2011 Rolf Winter NEC Email: Rolf.Winter@nw.neclab.eu Busi and al. Expires January 11, 2012 [Page 29]