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 Telstra 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 Han Li Maarten Vissers Wang Lei Huawei China Mobile Communications Corporation Vishwas Manral Masahiko Mizutani IPInfusion Hitachi Expires: January 2010 July 13, 2009 MPLS-TP OAM based on Y.1731 draft-bhh-mpls-tp-oam-y1731-03.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 Busi and al. Expires January 13, 2010 [Page 1] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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....................................5 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................................................8 4. MPLS-TP OAM Functions........................................9 4.1. Continuity check message (CCM) PDU.....................10 4.1.1. CCM PDU Format....................................10 4.1.1.1. MEG ID Formats...............................12 4.1.2. CCM Transmission Procedures.......................14 Busi and al. Expires January 13, 2010 [Page 2] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 4.1.3. CCM Reception Procedures..........................15 4.2. Loopback Message/Reply (LBM/LBR) PDU...................16 4.2.1. LBM PDU Format....................................16 4.2.2. LBR PDU Format....................................19 4.2.3. LBM Transmission Procedures.......................20 4.2.4. LBM Reception and LBR Transmission Procedures.....20 4.2.5. LBR Reception Procedures..........................21 4.3. Alarm Indication Signal (AIS) PDU......................21 4.4. Locked (LCK) PDU.......................................21 4.5. Test (TST) PDU.........................................22 4.6. Automatic Protection Switching (APS) PDU...............22 4.7. Loss Measurement Message/Reply (LMM/LMR) PDU...........22 4.8. One-way delay measurement (1DM) PDU....................22 4.9. Delay Measurement Message/Reply (DMM/DMR) PDU..........23 5. Security Considerations.....................................23 6. IANA Considerations.........................................23 7. Acknowledgments.............................................24 8. References..................................................25 8.1. Normative References...................................25 8.2. Informative References.................................25 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 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 (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. Busi and al. Expires January 13, 2010 [Page 3] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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 OAM interworking between a p2p Ethernet Service VLAN and a p2p MS-PW. Service interworking requirements and mechanisms are outside the scope of this document. o Reduce the complexity and increase the reuse of code for implementation in packet transport devices that may support both Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS applications. 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. 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 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 Busi and al. Expires January 13, 2010 [Page 4] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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, Nurit Sprecher, Yaakov Stein, Yuji Tochio, Munefumi Tsurusawa, Maarten Vissers, Yaacov Weingarten 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 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. Busi and al. Expires January 13, 2010 [Page 5] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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 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. 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 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. 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 January 13, 2010 [Page 6] Internet-Draft MPLS-TP OAM based on Y.1731 July 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 noting that this document proposes that MPLS-TP OAM supports the OAM PDUs and procedures that are defined in Y.1731 [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. [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.] Busi and al. Expires January 13, 2010 [Page 7] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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. 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 noting 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. Busi and al. Expires January 13, 2010 [Page 8] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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. 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. The LTM/LTR OAM PDUs, as defined in 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). Extensions to LTM/LTR can be defined in a future version of this document using the MPLS-TP MEP and MIP Identifiers under definition in [9]. [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] Busi and al. Expires January 13, 2010 [Page 9] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 [Editor's note - Check the status of CSF definition within ITU-T and, if needed, add the CSF PDU to a future version of this draft] 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 check and connectivity verification o Pro-active remote defect indication o Pro-active packet loss It is worth noting that the use of CCM does not require any additional status information other than the configuration parameters and defect states. 4.1.1. CCM PDU Format The format of the CCM PDU within the ACH is described in Figure 3. Busi and al. Expires January 13, 2010 [Page 10] Internet-Draft MPLS-TP OAM based on Y.1731 July 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 [Editor's note - The figure above describes the CCM PDU format if the first option for encapsulation is adopted. The figure will be updated if the second option is selected] The fields of the CCM PDU are set 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 an RDI condition. 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 Busi and al. Expires January 13, 2010 [Page 11] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 o The Period field MUST indicate the configured transmission and reception period of CCM packets according to the following table: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 0x46 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 value as described in section 4.1.1.1. 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. 4.1.1.1. MEG ID Formats The MEG ID field MUST contain the globally unique identifier of the Maintenance Entity. Busi and al. Expires January 13, 2010 [Page 12] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 The generic format of MEG IDs is defined in Figure 4: 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+ | Reserved (0x01) | +-+-+-+-+-+-+-+-+-+ | MEG ID Format | +-+-+-+-+-+-+-+-+-+ | MEG ID Length | +-+-+-+-+-+-+-+-+-+ | | : MEG ID Value : | | +-+-+-+-+-+-+-+-+-+ Figure 4 Generic MEG ID Format In transport networks, the MEG ID for LSPs, PWs and Sections uses the ICC-based format as defined in Figure 5. The ICC-based MEG ID is an ASCII string of up to thirteen characters, each character being either alphabetic (i.e. A-Z) or numeric (i.e. 0- 9) character. It consists of two subfields: the ITU-T Carrier Code (ICC), as defined in [9], followed by a unique MEG ID code (UMC) with trailing NULLs characters. Busi and al. Expires January 13, 2010 [Page 13] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 0 1 2 3 4 5 6 7 8 +---+---+---+---+---+---+---+---+---+ | Reserved (0x01) | +---+---+---+---+---+---+---+---+---+ | MEG ID Format 0x20) | +---+---+---+---+---+---+---+---+---+ | MEG ID Length (0x0D) | +---+---+---+---+---+---+---+---+---+ | 0 | MEG ID Value [1] | +---+---+---+---+---+---+---+---+---+ | 0 | MEG ID Value [2] | +---+---+---+---+---+---+---+---+---+ : : +---+---+---+---+---+---+---+---+---+ | 0 | MEG ID Value [13] | +---+---+---+---+---+---+---+---+---+ | | : Unused (all zeros) : | | +---+---+---+---+---+---+---+---+---+ Figure 5 ICC-based MEG ID Format [Editor's note - Additional formats for MEG IDs for IP environment are also possible. New formats, in alignment with draft-swallow-mpls- tp-identifiers will be added in future versions of this document.] 4.1.2. CCM Transmission Procedures The transmission of CCM MUST be explicitly enabled or disabled in a MEP. A MEP MUST always be capable to report the reception of CCM PDUs with unexpected information irrespectively on whether CCM transmission has been enabled or not. If CCM transmission is enabled, the source MEP generates CCM packets at the configured transmission period. Each CCM PDU is formatted as described in section 4.1.1. The transmission period of the CCM is always the configured period and does not change unless the operator reconfigures it. The R (RDI) bit MUST be set when the MEP detects a failure condition as described in [4]. [Editor's note - The procedures for pro-active loss measurement will be added in a future version of this document] Busi and al. Expires January 13, 2010 [Page 14] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 4.1.3. CCM Reception Procedures When a MEP receives a CCM packet, it performs the following checks: o If the Period field is equal to "000", the CCM packet is malformed. The CCM packet is considered invalid and discarded without further processing. o If the MEG ID field is different than the expected value, a Mismerge (MMG) defect is detected. The CCM packet is considered invalid and discarded without further processing. o If the MEP ID field is different than the peer MEP ID, a Unexpected MEP (UNM)defect is detected. The CCM packet is considered invalid and discarded without further processing. o If the Period field is different than the configured transmission period, a Unexpected Period defect (UNP) is detected. The CCM packet is still considered valid. [Editor's note - Checks on the TC fields are not yet defined in [4]. They can be added in future versions of this document in accordance with [4]] The defects detected during the validation phase are cleared when one of the following conditions happens: o The MMG defect is cleared if no CCM packet with invalid MEG ID field is received for a period of time that is at least K (with 3.25.K .3.5) times the longest Period in the CCM packets received with an invalid MEG ID field since the MMG defect has been raised; o The UNM defect is cleared if no CCM packet with invalid MEP ID field is received for a period of time that is at least K (with 3.25.K .3.5) times the longest Period in the CCM packets received with an invalid MEP ID since the UNM defect has been raised; o The UNP defect is cleared if no CCM packet with invalid Period field is received for a period of time that is at least K (with 3.25.K .3.5) times the longest Period in the CCM packets received with an invalid Period since the UNP defect has been raised. If no valid CCM packets are received for a period of time that is K (with 3.25.K .3.5) times the configured CCM transmission period, a Loss Busi and al. Expires January 13, 2010 [Page 15] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 of Continuity (LOC) defect is detected. The LOC defect is cleared as soon as a valid CCM packet is received. If a valid CCM packet is received with the R (RDI) bit set, the RDI defect is also detected. The RDI defect is cleared as soon as a valid CCM packet is received with the R (RDI) bit cleared. [Editor's note - The procedures for pro-active loss measurement will be added in a future version of this document] [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] 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 On-demand bidirectional 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]. 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 path is locked on both sides by network management operations. However, single-ended procedures as defined in [8] MAY be used. 4.2.1. LBM PDU Format The format of the LBM PDU within the ACH is described in Figure 6. Busi and al. Expires January 13, 2010 [Page 16] Internet-Draft MPLS-TP OAM based on Y.1731 July 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID/Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Optional TLVs : | +-+-+-+-+-+-+-+-+ | | End TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 LBM PDU within a single ACH Channel Type [Editor's note - The figure above describes the LBM PDU format if the first option for encapsulation is adopted. The figure will be updated if the second option is selected] The fields of the LBM PDU are set 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 0x03 (indicating a LBM PDU) o The Flags field MUST be set 0x00 in transmission and ignored in reception o The TLV Offset field MUST b e set to 0x04 o The Transaction ID/Sequence Number MUST be set to the transaction ID, when LBM/LBR is used for on-demand connectivity verification, or to the Sequence Number when LBM/LBR is used for bidirectional diagnostic test When LBM is used for on-demand connectivity verification, it MAY carry the Data TLV as defined Figure 7: Busi and al. Expires January 13, 2010 [Page 17] Internet-Draft MPLS-TP OAM based on Y.1731 July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x03) | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : Data Pattern : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Data TLV format The Type field indicates a Data TLV and MUST be set to 0x03. The Length field MUST indicate, in bytes, the length of the Value field containing the Data Pattern. The Data Pattern is an arbitrary bit pattern of arbitrary length. When LBM is used for bidirectional diagnostic test, it MUST carry the Test TLV as defined 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 (0x20) | Length | Pattern Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Test Pattern : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 Test TLV format The Type field indicates a Test TLV and MUST be set to 0x20. The Length field MUST indicate, in bytes, the length of the Value field containing the Test Pattern and the optional CRC-32 when present. The Pattern Type identifies the type of Test Pattern and whether or not the CRC-32 is used. The possible values are: o 0 - Null signal without CRC-32 Busi and al. Expires January 13, 2010 [Page 18] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 o 1 - Null signal with CRC-32 o 2 - PRBS without CRC-32 o 3 - PRBS with CRC-32 o 4-255 Reserved for future standardization The Test Pattern is a pattern of arbitrary length carrying either the NULL (all zeroes) or the PRBS test signal. CRC-32, when present, contains the CRC-32 covering all fields (from Type to the last octet before the CRC-32 field). 4.2.2. LBR PDU Format The format of the LBR PDU within the ACH is described 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID/Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Optional TLVs : | +-+-+-+-+-+-+-+-+ | | End TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 LBR PDU within a single ACH Channel Type [Editor's note - The figure above describes the LBR PDU format if the first option for encapsulation is adopted. The figure will be updated if the second option is selected] The fields of the LBR PDU are set as follows: o The MEL field MUST be copied from the received LBM packet o The Version field MUST be copied from the received LBM packet o The OpCode field MUST be set to 0x02 (indicating a LBR PDU) Busi and al. Expires January 13, 2010 [Page 19] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 o The Flags field MUST be copied from the received LBM packet o The TLV Offset field MUST copied from the received LBM packet o The Transaction ID/Sequence Number MUST be copied from the received LBM packet o The Optional TLVs and the End TLV MUST be copied from the received LBM packet NOTE: 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 adopting the proposal of reusing Y.1731 OAM PDU and procedures in MPLS-TP.] 4.2.3. LBM Transmission Procedures LBM packets are generated on-demand. When used to verify bidirectional connectivity, a MEP MUST send the LBM packet with a specific transaction ID to the target MIP or MEP and it expects to receive a reply within 5 seconds. A Data TLV MAY also be added in order to check the transmission of different packet sizes. A MEP MUST NOT generate two LBM packets with the same Transaction ID within one minute. 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. When used to perform a bidirectional diagnostic test, a MEP MUST send the LBM packet with the Test TLV carrying the test pattern generated by the test signal generator together with the Sequence Number. 4.2.4. LBM Reception and LBR Transmission Procedures When a MIP or MEP receives an LBM packet, it MUST generate an LBR packet and sent it back to the MEP that has generated the LBM packet. Busi and al. Expires January 13, 2010 [Page 20] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 When used for bidirectional diagnostic test, it can be useful to configure the receiving MEP into the OAM Loopback Mode (OLB). This can be done either via a network management procedure or as defined in [8]. The need to set the receiving MEP in OLB mode requires further study. 4.2.5. LBR Reception Procedures A MEP that receives an LBR packet for connectivity verification with the expected Transaction ID and within 5 seconds from the transmission of the request LBM packet, MUST consider the LBR packet valid and the connectivity check passed. A MEP that receives an LBR packet for diagnostic text MUST process it according to the test procedures. The Sequence Number field MAY also be validated as part of the test procedure. [Editor's note - Further details will be provided in the next version of the draft] 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 reporting function, 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 lock reporting function, 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 January 13, 2010 [Page 21] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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 uni-directional in-service or out-of- service diagnostic test function, 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] 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]. Busi and al. Expires January 13, 2010 [Page 22] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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. Security Considerations To be added in a future version of the document 6. 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. 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. Busi and al. Expires January 13, 2010 [Page 23] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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] 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 January 13, 2010 [Page 24] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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-01(work in progress), July 2009 [5] Beller, D., Farrel, A., "An Inband Data Communication Network For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-dcn-03 (work in progress), May 2009 8.2. Informative References [6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 02 (work in progress), July 2009 [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-02 (work in progress), March 2009 [9] Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-swallow- mpls-tp-identifiers-00 (work in progress), July 2009 [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 January 13, 2010 [Page 25] Internet-Draft MPLS-TP OAM based on Y.1731 July 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 (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 January 13, 2010 [Page 26] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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 January 13, 2010 [Page 27] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 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 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 13, 2010 [Page 28] Internet-Draft MPLS-TP OAM based on Y.1731 July 2009 Yaacov Weingarten Nokia Siemens Networks Email: yaacov.weingarten@nsn.com Busi and al. Expires January 13, 2010 [Page 29]