MPLS Working Group I. Busi (Ed) Internet Draft Alcatel-Lucent Intended status: Standard Track H. van Helvoort (Ed) J. He (Ed) Huawei Christian Addeo Manuel Paul Vincenzo Sestito Josef Roese Alcatel-Lucent Deutsche Telekom Simon Delord Nurit Sprecher Uecomm Yaacov Weingarten John Hoffmans Nokia Siemens Networks KPN Yaakov Stein Ruiquan Jing RAD China Telecom Yuji Tochio Julien Meuric Fujitsu Philippe Niger Munefumi Tsurusawa France Telecom KDDI R&D Labs Maarten Vissers Huawei Expires: September 2009 March 24, 2009 MPLS-TP OAM based on Y.1731 draft-bhh-mpls-tp-oam-y1731-02.txt 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 24, 2009 [Page 1] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 Copyright Notice Copyright (c) 2009 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. Abstract This document specifies how 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 specifies 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. Table of Contents 1. Introduction.................................................3 1.1. Contributing Authors....................................4 2. Conventions used in this document............................5 2.1. Terminology.............................................5 3. Encapsulation of OAM PDU in MPLS-TP..........................5 3.1. Encapsulation of different OAM PDUs within a single ACH Channel Type.................................................6 3.2. Encapsulation of different OAM PDUs within different ACH Channel Types................................................7 4. MPLS-TP OAM Functions........................................9 4.1. Continuity check message (CCM) PDU......................9 4.2. Loopback Message/Reply (LBM/LBR) PDU...................11 4.3. Alarm Indication Signal (AIS) PDU......................12 4.4. Locked (LCK) PDU.......................................12 4.5. Test (TST) PDU.........................................13 4.6. Automatic Protection Switching (APS) PDU...............13 4.7. Loss Measurement Message/Reply (LMM/LMR) PDU...........13 Busi and al. Expires September 24, 2009 [Page 2] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 4.8. One-way delay measurement (1DM) PDU....................14 4.9. Delay Measurement Message/Reply (DMM/DMR) PDU..........14 5. MPLS-TP and Ethernet OAM Interworking.......................14 6. Security Considerations.....................................14 7. IANA Considerations.........................................14 8. Acknowledgments.............................................15 9. References..................................................16 9.1. Normative References...................................16 9.2. Informative References.................................16 1. Introduction This document specifies how to leverage Y.1731 [2] Protocol Data Units (PDU) 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]. ITU-T Recommendation Y.1731 [2] specifies: o OAM PDUs and procedures (state machines) 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 be used also in other packet technologies (e.g. MPLS-TP) provided that the technology specific encapsulation is defined. This document proposes that MPLS-TP OAM reuses the same OAM PDUs and procedures (state machines) defined in Y.1731 [2], specifying the necessary MPLS-TP technology specific encapsulation mechanisms for supporting MPLS-TP OAM capabilities. Following are the advantages of using this approach: o Availability of MPLS-TP OAM functions in the near terms, since Ethernet OAM functions are already supported and deployed o Simplify the interworking between a p2p Ethernet Service VLAN and a p2p MS-PW. Further details regarding this interworking will be provided in section 5. Busi and al. Expires September 24, 2009 [Page 3] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 o Reduce the complexity and increase the reuse of code for implementation in packet transport devices that may support both Ethernet (e.g. VPLS and H-VPLS) and MPLS-TP capabilities. [Editor's note - Add also the description of operational benefit of reusing the same OAM protocols in LSP, PW and VPLS (i.e. the operator has to test and maintain a single protocol set rather than two).] 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 advantages 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 or preclude definition of other MPLS-TP OAM tools. Precedence rules are for further study. The mechanisms proposed 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, Julien Meuric, Philippe Niger, Manuel Paul, Josef Roese, Vincenzo Sestito, Nurit Sprecher, Yaakov Stein, Yuji Tochio, Munefumi Tsurusawa, Maarten Vissers, Yaacov Weingarten Busi and al. Expires September 24, 2009 [Page 4] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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]. 2.1. Terminology ACH Associated Channel Header LME LSP Maintenance Entity ME Maintenance Entity MEP Maintenance End Point MIP Maintenance Intermediate Point PME PW Maintenance Entity SME Section Maintenance Entity TCME Tandem Connection Maintenance Entity TPME Tandem PW Maintenance Entity 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 ACH [3] construct and they are addressed to MEPs and MIPs by using label stacking and TTL expiration. Busi and al. Expires September 24, 2009 [Page 5] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 It is therefore possible to encapsulate OAM PDUs within MPLS-TP using the [3] to distinguish OAM packets from user data packets. The label stack entries on top of the ACH and the TTL field are used as defined in [4] to address these packets to the correct MEPs and MIPs. 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 about the usage of the ACH TLV will be added in the future version of this draft] This version of the document describes two possible options to encapsulate OAM PDUs within ACH: 1. Use a single ACH Channel Type (0xXX) identifying the whole Y.1731 toolset and rely upon the OpCode field in Y.1731 to identify the specific OAM PDU 2. Use of multiple ACH Channel Type values, one for each OAM PDU thus making the usage of the OpCode field within the OAM PDU not required when used in MPLS-TP Future versions of the document will describe the proposed option to be standardized for encapsulating OAM PDUs within ACH. Moreover, MPLS-TP relies upon a different mechanism for supporting tandem connection monitoring (i.e. label stacking) than that 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. 3.1. Encapsulation of different OAM PDUs within a single ACH Channel Type When the first option is used, OAM PDUs are encapsulated using the ACH, according to [3], as described in Figure 1 below. Busi and al. Expires September 24, 2009 [Page 6] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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 Y.1731 PDU within a single ACH Channel Type The Channel Type value 0xXX identifies the payload as a Y.1731 PDU. [Editor's note - The value 0x8902 has been proposed to keep the channel type identical to the EtherType value used in Ethernet OAM] It is worth noticing that this document proposes that MPLS-TP OAM supports the OAM PDUs and procedures that are defined in [2], as approved in February 2008, and that are explicitly listed in section 4. If in the future, additional OAM PDUs, or update versions of existing OAM PDUs and procedures, need to be supported for MPLS-TP OAM, a new document that explicitly proposes their support will be developed according to the IETF Standard Process. 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] and reproduced in 4. . 3.2. Encapsulation of different OAM PDUs within different ACH Channel Types When the second option is used, OAM PDUs are encapsulated using the ACH, according to [3], as described in Figure 2 below. Busi and al. Expires September 24, 2009 [Page 7] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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| Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | OpCode | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | OAM function specific fields | | (Y.1731 based) | + + : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Y.1731 PDU within multiple ACH Channel Types The Channel Type MUST be set to a value that is obtained by adding the OpCode value defined in Y.1731 to an offset 0xYY (to be defined). [Editor's note - The value 0x0200 has been proposed as the offset for channel type] This approach requires that IANA reserves 256 channel type codepoints to identify Y.1731 PDUs to allow a simple mapping of the Y.1731 OpCode and ACH Channel Type field. It is worth noticing that these 256 codepoints need just to be reserved and not to be allocated. Only the codepoints associated with the Y.1731 PDUs and procedures that are defined in [2], as approved in February 2008, and that are explicitly listed in section 4. need to be allocated. If in the future, additional OAM PDUs, or updated versions of existing OAM PDUs and procedures, need to be supported for MPLS-TP OAM, a new document that explicitly proposes their support will be developed according to the IETF Standard Process. That document MUST allocate the required Channel Type codepoint(s) within this reserved range according to the rule described in this document. The OpCode field MUST NOT be used. The setting of the Version, Flags and TLV Offset is OpCode specific and described in Y.1731 [2] and reproduced in 4. . Busi and al. Expires September 24, 2009 [Page 8] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 4. MPLS-TP OAM Functions This section describes the OAM PDUs and procedures, as defined in Y.1731 [2], that are proposed by this document to be used in MPLS-TP environment as well as the functions supported by each OAM PDU to meet MPLS-TP OAM Requirements, as defined in [6]. This document is proposing not to use the VSM/VSR and EXM/EXR OAM PDUs in MPLS-TP. The experimental ACH Channel Type code-points that are allocated in [3] should be used instead. This document is proposing not to use the MCC OAM PDU in MPLS-TP. The solution proposed in [5] should be used instead. [Editor's note - Clarify that LTM/LTR, as currently defined in Y.1731, are not applicable to MPLS-TP] [Editor's note - There is a need to ensure the full alignment between the technology-independent OAM PDUs and procedures defined in Y.1731 and in this document] [Editor's Note - This section will be completed in the next version of the document, for example other PDUs can be added on the basis of IETF consensus] 4.1. Continuity check message (CCM) PDU The format of the CCM PDU and the associated procedures are defined in Y.1731 [2] and reproduced in this section. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the following MPLS-TP OAM functions required in [6]: o Pro-active continuity and connectivity verification o Pro-active remote defect indication o Pro-active loss measurement The format of the CCM PDU within the ACH is described in Figure 3. Busi and al. Expires September 24, 2009 [Page 9] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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 |R| Res. | Per | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEP ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : MEG ID (48 bytes) : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TxFCf | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxFCf | RxFCb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RxFCb | TxFCb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxFCb | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | End TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 CCM PDU within a single ACH Channel Type The fields of the CCM PDU format are as follows: o The MEL field MUST be set to a configurable value (Default value is "111") o The Version field MUST be set to "00000" o The OpCode field MUST be set to 0x01 (indicating a CCM PDU) o The R (RDI) bit MUST be set to 1 to indicate RDI. Otherwise is MUST be set to 0 o The Res. Bits are reserved and MUST be set to "0000" in transmission and ignored in reception o The Period field MUST indicate the transmission and reception period of CCM packets according to the following table: Busi and al. Expires September 24, 2009 [Page 10] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| Invalid value | Invalid value for CCM PDU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1| 3.33 ms | 300 packets per second | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0| 10 ms | 100 packets per second | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1| 100 ms | 10 packets per second | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 1 s | 1 packet per second | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1| 10 s | 6 packets per minute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0| 1 min | 1 packet per minute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1| 10 min | 6 packets per hour | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o The TLV OffSet field MUST be set to 0d70 o The MEP ID field MUST be set to a configurable 13-bit integer value identifying the transmitting MEP within the MEG. The three MSBs of the first octet are not used and MUST be set to ZERO. o The MEG ID field MUST be set to a configurable 48-octet value. Refer to Annex A of ITU-T Recommendation Y.1731 for the format used for the MEG ID field with ICC-based format o TxFCf, TxFCb, RxFCb: 4-octet integer values with samples of the wrap-around packet counters. These fields are set to all-ZEROes when not used. o Reserved fields MUST be set to all ZEROes o The End TLV is an all ZEROes octet representing that there are no TLVs within the CCM PDU. [Editor's note - Further details will be provided in the next version of the draft] 4.2. Loopback Message/Reply (LBM/LBR) PDU The format of the LBM/LBR PDUs and the associated procedures are defined in Y.1731 [2]. Busi and al. Expires September 24, 2009 [Page 11] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the following MPLS-TP OAM functions required in [6]: o On-demand bidirectional continuity and connectivity verification o Bidirectional in-service or out-of-service diagnostic test Note - It is worth noticing that these OAM PDUs cover different functions that those defined in [8] NOTE: LBM/LBR OAM requires TargetMEP/MIP ID and OriginatorMEP 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 adopting the proposal of reusing Y.1731 OAM PDU and procedures in MPLS-TP.] [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] 4.3. Alarm Indication Signal (AIS) PDU This format of the AIS PDU and the associated procedures are defined in Y.1731 [2]. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the MPLS-TP OAM alarm suppression function, in case of a failure condition of the MPLS-TP server (sub-)layer, as required in [6]. [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] 4.4. Locked (LCK) PDU This format of the LCK PDU and the associated procedures are defined in Y.1731 [2]. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the MPLS-TP OAM alarm suppression Busi and al. Expires September 24, 2009 [Page 12] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 function, in case of an administrative locking of the MPLS-TP server (sub-)layer, as required in [6]. [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] 4.5. Test (TST) PDU This format of the TST PDU and the associated procedures are defined in Y.1731 [2]. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the MPLS-TP OAM alarm suppression function, in case of an administrative locking of the MPLS-TP server (sub-)layer, as required in [6]. [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] 4.6. Automatic Protection Switching (APS) PDU This 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 - The format of these PDUs and the procedures will be illustrated in a future version of this document] 4.7. Loss Measurement Message/Reply (LMM/LMR) PDU The format of the LMM/LMR PDUs and the associated procedures are defined in Y.1731 [2]. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the MPLS-TP OAM on-demand and proactive bidirectional packet loss measurement functions as required in [6]. [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] Busi and al. Expires September 24, 2009 [Page 13] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 4.8. One-way delay measurement (1DM) PDU This format of the 1DM PDU and the associated procedures are defined in Y.1731 [2]. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the MPLS-TP OAM on-demand one-way delay measurement as required in [6]. These PDUs can also be used to support MPLS-TP OAM proactive one-way delay measurement. [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] 4.9. Delay Measurement Message/Reply (DMM/DMR) PDU The format of the DMM/DMR PDUs and the associated procedures are defined in Y.1731 [2]. These PDUs are encapsulated within MPLS-TP as described in section 3. and can be used to support the MPLS-TP OAM on-demand two-ways delay measurement function as required in [6]. These PDUs can also be used to support MPLS-TP OAM proactive two-ways delay measurement. [Editor's note - The format of these PDUs and the procedures will be illustrated in a future version of this document] 5. MPLS-TP and Ethernet OAM Interworking To be added in a future version of the document 6. Security Considerations To be added in a future version of the document 7. IANA Considerations The IANA considerations of this draft depend on the mechanism that will be specified for the encapsulation of Y.1731 derived OAM PDUs within MPLS-TP. Busi and al. Expires September 24, 2009 [Page 14] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 If the first option is selected (i.e. one codepoint for all of these OAM PDUs) IANA is requested to allocate a Channel Type value 0xXX to identify an associated channel carrying all such OAM PDUs and procedures 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] If in the future, additional Y.1731 OAM PDUs, or update versions of existing OAM PDUs and procedures, MAY need to be supported for MPLS- TP OAM, and a new document that explicitly proposes their support MUST be developed according to the IETF Standards Process. That document MUST request IANA to update the reference to this Channel Type allocation. If the second option is selected (i.e. one codepoint for each OAM PDU), IANA is requested to reserve (but not to allocate) 256 consecutive channel type codepoints as described in section 3.2. IANA is also requested to allocate the codepoints associated with the OAM PDUs and procedures that are explicitly listed in section 4. If in the future, additional such OAM PDUs, or updated versions of existing OAM PDUs and procedures, need to be supported for MPLS-TP OAM, a new document that explicitly proposes their support MUST be developed according to the IETF Standards Process. That document MUST request IANA to allocate the required Channel Type codepoint(s), within this reserved range according to the rule described in this document, for the new proposed OAM PDUs, if any, and/or to update the reference to existing Channel Type allocations for the proposed updated OAM PDUs and procedures. [Editor's note - The IANA considerations will be completed in a future version of the document where the encapsulation mechanism will be defined] 8. 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 24, 2009 [Page 15] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., "MPLS Generic Associated Channel", draft-ietf-mpls-tp-gach-gal- 02 (work in progress), February 2009 [4] Busi,I., Niven-Jenkins, B., "MPLS-TP OAM Framework and Overview", draft-busi-mpls-tp-oam-framework-00(work in progress), October 2008 [5] Beller, D., Farrel, A., "An Inband Data Communication Network For the MPLS Transport Profile", draft-beller-mpls-tp-gach-dcn- 00 (work in progress), January 2009 9.2. Informative References [6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 00 (work in progress), December 2008 [7] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3-oam-msg-map-08 (work in progress), November 2008 [8] Boutros, S., et al., "Operating MPLS Transport Profile LSP in Loopback Mode", draft-boutros-mpls-tp-loopback-01 (work in progress), December 2008 [9] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and Metropolitan Area Networks: Connectivity Fault Management", September 2007 Busi and al. Expires September 24, 2009 [Page 16] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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 Huawei Technologies Email: hejia@huawei.com Contributing Authors' Addresses Christian Addeo Alcatel-Lucent Email: Christian.Addeo@alcatel-lucent.it Simon Delord Uecomm Email: sdelord@uecomm.com.au John Hoffmans KPN Email: john.hoffmans@kpn.com Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn Busi and al. Expires September 24, 2009 [Page 17] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 Julien Meuric France Telecom Email: julien.meuric@orange-ftgroup.com Philippe Niger France Telecom Email: philippe.niger@orange-ftgroup.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.it Nurit Sprecher Nokia Siemens Networks Email: nurit.sprecher@nsn.com Yaakov (Jonathan) Stein RAD Data Communications Email: yaakov_s@rad.com Busi and al. Expires September 24, 2009 [Page 18] Internet-Draft MPLS-TP OAM based on Y.1731 March 2009 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 Yaacov Weingarten Nokia Siemens Networks Email: yaacov.weingarten@nsn.com Busi and al. Expires September 24, 2009 [Page 19]