MPLS Working Group I. Busi (Ed) Internet Draft Alcatel-Lucent H. van Helvoort (Ed) J. He (Ed) Huawei Expires: September 2010 March 8, 2010 MPLS-TP OAM based on Y.1731 draft-bhh-mpls-tp-oam-y1731-04.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 [6]. 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 September 8, 2010 [Page 1] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 Copyright Notice Copyright (c) 2010 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 September 8, 2010 [Page 2] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 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 Functions........................................8 4.1. Pro-active CC-V and RDI (CCM)...........................8 4.2. OAM Loopback (LB).......................................9 4.3. Alarm Indication Signal (AIS)..........................10 4.4. Lock Reporting (LCK)...................................10 4.5. Test (TST).............................................10 4.6. Automatic Protection Switching (APS)...................11 4.7. Loss Measurement (LM)..................................11 4.8. One-way delay measurement (1DM)........................11 4.9. Two-way delay Measurement Message/Reply (DM)...........11 5. Security Considerations.....................................12 6. IANA Considerations.........................................12 7. Acknowledgments.............................................12 8. References..................................................13 8.1. Normative References...................................13 8.2. Informative References.................................13 Busi and al. Expires September 8, 2010 [Page 3] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 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 [6]. 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. [Editor's note - Place information on the fact that existing implementations of this solution already exist] 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 Availability of MPLS-TP OAM functions in the near terms, since Ethernet OAM functions are already 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 September 8, 2010 [Page 4] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS applications. Ethernet OAM is also defined by IEEE 802.1ag [9]. 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. IEEE 802.1ag defines additional status reporting that is advantageous in enterprise networks but not required in transport networks. ITU-T Y.1731 defines 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 [7]. 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 [7]. The mapping procedures are outside the scope of this version of the document. They will be specified in a future version of this document, in a future version of [7] or in another document that updates [7]. 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, Simon Delord, John Hoffmans, Ruiquan Jing, Wang Lei, Han Li, Vishwas Manral, Julien Meuric, Masahiko Mizutani, Philippe Niger, Manuel Paul, Josef Roese, Vincenzo Sestito, Yaakov Stein, Yuji Tochio, Munefumi Tsurusawa, Maarten Vissers 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 September 8, 2010 [Page 5] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 2.1. Terminology ACH Associated Channel Header ME Maintenance Entity MEG Maintenance Entity Group MEP Maintenance End Point MIP Maintenance Intermediate Point 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 MAC DA, MAC SA and EtherType are 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 [4], 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 (0xXX) 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. [Editor's note - The value 0x8902 has been proposed to keep the channel type identical to the EtherType value used in Ethernet OAM] OAM PDUs are encapsulated using the ACH, according to [3], as described in Figure 1 below. Busi and al. Expires September 8, 2010 [Page 6] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 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 (0xXX) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | OpCode | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | OAM function specific fields | | (Y.1731 based) | + + : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 G-ACh Packet carrying a Y.1731 PDU The usage of the ACH TLV object, as defined in [3], provides enough flexibility to support IP-based addressing schemes to allow the usage of these OAM tools also within an IP/MPLS environment. [Editor's note - Further considerations (e.g., usage of the ACH Authentication TLV as defined in draft-manral-mpls-tp-oam-auth-tlv- 00) about the usage of the ACH TLV will be added in the future version of this draft] 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 not 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]. Busi and al. Expires September 8, 2010 [Page 7] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 [Editor's note - This option allows packing multiple PDUs together. The mechanisms and the advantages of packing multiple OAM PDUs in the same packets require further study.] 4. MPLS-TP OAM Functions 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 [6]. This document is proposing not to use the Y.1731 MCC OAM PDU in MPLS-TP. The solution proposed in [5], 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. 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. In order to support the MPLS-TP OAM Requirements for Route Tracing, as defined in [6], two options are possible: o extend the current definition of LTM/LTR to make them applicable to MPLS-TP; o define a new tool (as reported in section 1, this document is not precluding the definition of other MPLS-TP OAM tools). [Editor's note - Check draft-he-mpls-tp-csf as well as the status of CSF definition within ITU-T and, if needed, add the CSF PDU to a future version of this draft] 4.1. Pro-active CC-V and RDI (CCM) The CCM PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as described in section 3, can be used to support the following MPLS-TP OAM functional requirements: o Pro-active continuity check (section 2.2.2 of [6]); o Pro-active connectivity verification (section 2.2.3 of [6]); o Pro-active remote defect indication (section 2.2.9 of [6]); Busi and al. Expires September 8, 2010 [Page 8] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 o Pro-active packet loss measurement (section 2.2.11 of [6]). Procedures for generating and processing CCM PDUs are defined in Y.1731 [2]. 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 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 [4]. In transport networks, the source MEP for LSPs, PWs and Sections is identified by combining a globally unique MEG ID, which uses the ICC-based format as defined in Annex A of Y.1731 [2], with a MEP ID that is unique within the scope of the Maintenance Entity Group. 4.2. OAM Loopback (LB) The LBM/LBR PDUs, defined in Y.1731 [2] and encapsulated within MPLS- TP as described in section 3, and can be used to support the following MPLS-TP OAM functional requirements: o On-demand bidirectional connectivity verification (section 2.2.3 of [6]); o Bidirectional in-service or out-of-service diagnostic test (section 2.2.5 of [6]). Procedures for generating and processing LBM/LBR PDUs are defined in Y.1731 [2]. It is worth noticing that these OAM PDUs cover different functions than those defined in [8]. 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 September 8, 2010 [Page 9] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 path is locked on both sides by network management operations. However, single-ended procedures as defined in [8] MAY be used. LBM/LBR OAM requires Target MEP/MIP ID and Originator MEP ID to be carried. Current Y.1731 Recommendation [2] assumes that those IDs are carried in the DA and SA fields of the encapsulating Ethernet frames. In MPLS-TP OAM those IDs can be carried in additional TLV within the LBM/LBR PDU or within the ACH TLV. [Editor's note - This issue will be further investigated in the next version of the draft but it is not a showstopper for reusing Y.1731 OAM PDU and procedures in MPLS-TP.] 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. [Editor's note - Clarify that this solution supports both per-node and per-interface MIP architectures] 4.3. Alarm Indication Signal (AIS) The AIS PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as described in section 3, can be used to support the alarm reporting MPLS-TP OAM functional requirement (section 2.2.8 of [6]). Procedures for generating and processing AIS PDUs are defined in Y.1731 [2]. 4.4. Lock Reporting (LCK) The LCK PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as described in section 3, can be used to support the lock reporting MPLS-TP OAM functional requirement (section 2.2.7 of [6]). Procedures for generating and processing LCK PDUs are defined in Y.1731 [2]. 4.5. Test (TST) The TST PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as described in section 3, 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 [6]). Busi and al. Expires September 8, 2010 [Page 10] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 Procedures for generating and processing TST PDUs are defined in Y.1731 [2]. 4.6. Automatic Protection Switching (APS) The APS PDU supports the requirements for MPLS-TP protection switching coordination. The complete format of the APS PDUs and the associated procedures are outside the scope of [2]. They will be added in future version of this document. [Editor's note - Further details will be provided in the next version of the draft] 4.7. Loss Measurement (LM) The LMM/LMR PDUs, defined in Y.1731 [2] and encapsulated within MPLS- TP as described in section 3, can be used to support on-demand and proactive packet loss measurement MPLS-TP OAM functional requirement (section 2.2.11 of [6]). Procedures for generating and processing LMM/LMR PDUs are defined in Y.1731 [2]. 4.8. One-way delay measurement (1DM) The 1DM PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as described in section 3, can be used to support the on-demand one-way packet delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of [6]). It can also be used to support proactive one-way delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of [6]). Procedures for generating and processing 1DM PDUs are defined in Y.1731 [2]. 4.9. Two-way delay Measurement Message/Reply (DM) The DMM/DMR PDUs, defined in Y.1731 [2] and encapsulated within MPLS- TP as described in section 3, can be used to support on-demand two- ways packet delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of [6]). Busi and al. Expires September 8, 2010 [Page 11] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 It can also be used to support proactive two-ways packet delay measurement MPLS-TP OAM functional requirement (section 2.2.12 of [6]). Procedures for generating and processing DMM/DMR PDUs are defined in Y.1731 [2]. 5. Security Considerations To be added in a future version of the document 6. IANA Considerations IANA is requested to allocate a Channel Type value 0xXX 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] 7. Acknowledgments To be added in a future version of the document This document was prepared using 2-Word-v2.0.template.dot. Busi and al. Expires September 8, 2010 [Page 12] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 8. References 8.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] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., "MPLS Generic Associated Channel", RFC 5586, June 2009 [4] Busi,I., Niven-Jenkins, B., "MPLS-TP OAM Framework and Overview", draft-ietf-mpls-tp-oam-framework-05 (work in progress), March 2010 [5] Beller, D., Farrel, A., "An Inband Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010 8.2. Informative References [6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 06 (work in progress), March 2010 [7] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3-oam-msg-map-11 (work in progress), June 2009 [8] Boutros, S., et al., "Operating MPLS Transport Profile LSP in Loopback Mode", draft-boutros-mpls-tp-loopback-03 (work in progress), March 2010 [9] Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-ietf- mpls-tp-identifiers-00 (work in progress), November 2010 [10] ITU-T Recommendation M.1400 (07/06), " Designations for interconnections among operators' networks", July 2006 [11] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and Metropolitan Area Networks: Connectivity Fault Management", September 2007 Busi and al. Expires September 8, 2010 [Page 13] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 Author's Addresses Italo Busi (Editor) Alcatel-Lucent Email: Italo.Busi@alcatel-lucent.it Huub van Helvoort (Editor) Huawei Technologies Email: hhelvoort@huawei.com Jia He (Editor) Huawei Technologies Email: hejia@huawei.com Contributing Authors' Addresses Christian Addeo Alcatel-Lucent Email: Christian.Addeo@alcatel-lucent.it 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 Busi and al. Expires September 8, 2010 [Page 14] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 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 Julien Meuric France Telecom Email: julien.meuric@orange-ftgroup.com Masahiko Mizutani Hitachi, Ltd. Email: masahiko.mizutani.ew@hitachi.com Philippe Niger France Telecom Email: philippe.niger@orange-ftgroup.com Manuel Paul Deutsche Telekom Email: Manuel.Paul@telekom.de Busi and al. Expires September 8, 2010 [Page 15] Internet-Draft MPLS-TP OAM based on Y.1731 March 2010 Josef Roese Deutsche Telekom Email: Josef.Roese@t-systems.com Vincenzo Sestito Alcatel-Lucent Email: vincenzo.sestito@alcatel-lucent.it Yaakov (Jonathan) Stein RAD Data Communications Email: yaakov_s@rad.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 September 8, 2010 [Page 16]