[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08

MPLS Working Group                                         I. Busi (Ed)
Internet Draft                                           Alcatel-Lucent
Intended status: Standard Track                    H. van Helvoort (Ed)
                                                             J. He (Ed)
                                                                 Huawei

Expires: July 2012                                     January 11, 2012


                        MPLS-TP OAM based on Y.1731
                    draft-bhh-mpls-tp-oam-y1731-08.txt


Abstract

   This document describes methods to leverage Y.1731 [2] Protocol Data
   Units (PDU) and procedures (state machines) to provide a set of
   Operation, Administration, and Maintenance (OAM) mechanisms that
   meets the MPLS Transport Profile (MPLS-TP) OAM requirements as
   defined in [8].

   In particular, this document describes the MPLS-TP technology
   specific encapsulation mechanisms to carry these OAM PDUs within
   MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP
   networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html




Busi and al.            Expires July 11, 2012                 [Page 1]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


Copyright Notice

   Copyright (c) 2012 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.





































Busi and al.            Expires July 11, 2012                 [Page 2]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


Table of Contents

   1. Introduction.................................................4
      1.1. Contributing Authors....................................5
   2. Conventions used in this document............................5
      2.1. Terminology.............................................6
   3. Encapsulation of OAM PDU in MPLS-TP..........................6
   4. MPLS-TP OAM Packet Formats...................................7
      4.1. Continuity Check Message (CCM)..........................8
         4.1.1. MEG ID Formats.....................................9
      4.2. OAM Loopback (LBM/LBR)..................................9
         4.2.1. Format of MEP and MIP ID TLVs.....................12
      4.3. Alarm Indication Signal (AIS)..........................16
      4.4. Lock Reporting (LCK)...................................16
      4.5. Test (TST).............................................17
      4.6. Loss Measurement (LMM/LMR).............................17
      4.7. One-way delay measurement (1DM)........................17
      4.8. Two-way delay Measurement Message/Reply (DM)...........17
      4.9. Client Signal Fail (CSF)...............................18
   5. MPLS-TP OAM Procedures......................................18
      5.1. Continuity Check Message (MT-CCM) procedures...........18
      5.2. OAM Loopback (MT-LBM/LBR) procedures...................20
      5.3. Alarm Indication Signal (MT-AIS) procedures............21
      5.4. Lock Reporting (LCK)...................................22
      5.5. Test (TST).............................................23
      5.6. Loss Measurement (LMM/LMR).............................23
      5.7. One-way delay measurement (1DM)........................23
      5.8. Two-way delay Measurement Message/Reply (DM)...........23
      5.9. Client Signal Fail (CSF)...............................23
   6. Security Considerations.....................................23
   7. IANA Considerations.........................................23
   8. Acknowledgments.............................................23
   9. References..................................................25
      9.1. Normative References...................................25
      9.2. Informative References.................................25











Busi and al.            Expires July 11, 2012                 [Page 3]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


1. Introduction

   This document describes the method for leveraging Y.1731 [2] Protocol
   Data Units (PDUs) and procedures to provide a set of Operation,
   Administration, and Maintenance (OAM) mechanisms that meet the MPLS
   Transport Profile (MPLS-TP) OAM requirements as defined in [8].

   This version of the draft does not introduce any technical change to
   the -06 version of this draft.

   ITU-T Recommendation Y.1731 [2] specifies:

   o  OAM PDUs and procedures that meet the transport networks
      requirements for OAM

   o  Encapsulation mechanisms to carry these OAM PDUs within Ethernet
      frames to provide Ethernet OAM capabilities in Ethernet networks

   Although Y.1731 is focused on Ethernet OAM, the definition of OAM
   PDUs and procedures are technology independent and can also be used
   in other packet technologies (e.g., MPLS-TP) provided that the
   technology specific encapsulation is defined.

   The OAM toolset defined in Y.1731 [2] serves as a benchmark for a
   high performance, comprehensive suite of packet transport OAM
   capabilities.  It can be provided by lightweight protocol design and
   supports operational simplicity by providing commonality with the
   established operation models utilized in other transport network
   technologies (e.g., SDH/SONET and OTN).

   This document describes mechanisms for MPLS-TP OAM that reuse the
   same OAM PDUs and procedures defined in Y.1731 [2], together with the
   necessary MPLS-TP technology specific encapsulation mechanisms.

   The advantages offered by this toolset are summarized below:

   o  Simplify the operations for the network operators and service
      providers that have to test and maintain a single general OAM
      protocol set when operating LSP, PW and VPLS networks.

   o  Accelerate the market adoption of MPLS-TP since Y.1731 is already
      mature, supported, and deployed.

   o  Reduce the complexity and increase the reuse of code for
      implementation in packet transport devices that may support both


Busi and al.            Expires July 11, 2012                 [Page 4]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


      Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS
      applications.

   It is worth noting that multi-vendor interoperable implementations of
   the OAM mechanisms described in this document already exist to meet
   the essential OAM requirements for MPLS-TP deployments in PTN
   applications as described in [9].

   Ethernet OAM is also defined by IEEE 802.1ag [14]. IEEE 802.1ag and
   ITU-T Y.1731 have been developed in cooperation by IEEE and ITU. They
   support a common subset of OAM functions. ITU-T Y.1731 further
   extends this common subset with additional OAM mechanisms that are
   important for the transport network (e.g. AIS, DM, LM).

   This document does not deprecate existing MPLS and PW OAM mechanisms
   nor preclude definition of other MPLS-TP OAM tools.

   The mechanisms described in this document, when used to provide
   MPLS-TP PW OAM functions, are open to support the OAM message mapping
   procedures defined in [10]. 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 [10].

   The mapping procedures are outside the scope of this document.

   In the rest of this document the term "OAM PDU" is used to indicate
   an OAM PDU whose format and associated procedures are defined in
   Y.1731 [2] and that this document proposes to be used to provide
   MPLS-TP OAM functions.

1.1. Contributing Authors

   Italo Busi, Huub van Helvoort, Jia He, Christian Addeo, Alessandro
   D'Alessandro, Simon Delord, John Hoffmans, Ruiquan Jing, Kam Lam,
   Wang Lei, Han Li, Vishwas Manral, Masahiko Mizutani, Manuel Paul,
   Josef Roese, Vincenzo Sestito, Yuji Tochio, Munefumi Tsurusawa,
   Maarten Vissers, Rolf Winter

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].




Busi and al.            Expires July 11, 2012                 [Page 5]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


2.1. Terminology

   ACH    Associated Channel Header

   G-ACh   Generic Associated Channel

   GAL    G-ACh Label

   ME      Maintenance Entity

   MEL    MEG Level

   MEG    Maintenance Entity Group

   MEP    Maintenance End Point

   MIP    Maintenance Intermediate Point

   PTN    Packet Transport Network

   TLV     Type Length Value

3. Encapsulation of OAM PDU in MPLS-TP

   Although Y.1731 is focused on Ethernet OAM, the definition of OAM
   PDUs and procedures are technology independent.

   When used to provide Ethernet OAM capabilities, these PDUs are
   encapsulated into an Ethernet frame where an Ethernet header is
   prepended to the OAM PDUs.

   The MAC DA is used to identify the MEPs and MIPs where the OAM PDU
   needs to be processed. The EtherType is used to distinguish OAM
   frames from user data frames.

   Within MPLS-TP OAM Framework [6], OAM packets are distinguished from
   user data packets using the GAL and ACH [5] construct and they are
   addressed to MEPs or MIPs using existing MPLS forwarding mechanisms
   (i.e. label stacking and TTL expiration). It is therefore possible to
   reuse the OAM PDUs defined in [2] within MPLS-TP and encapsulate them
   within ACH.

   A single ACH Channel Type (0xXXXX) is required to identify the
   presence of Y.1731 OAM PDU. Within the OAM PDU, the OpCode field,
   defined in [2], allows identifying the specific OAM PDU.


Busi and al.            Expires July 11, 2012                 [Page 6]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   OAM PDUs are encapsulated using the ACH, according to [5], as
   described in Figure 1 below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|  Y.1731 Channel Type (0xXXXX) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MEL | Version |    OpCode     |     Flags     |   TLV Offset  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                  OAM function specific fields                 |
      |                         (Y.1731 based)                        |
      +                                                               +
      :                              ...                              :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1 G-ACh Packet carrying a Y.1731 PDU

   Moreover, MPLS-TP relies upon a different mechanism for supporting
   tandem connection monitoring (i.e. label stacking) than the fixed MEL
   (Maintenance Entity Group Level) field used in Ethernet.

   Therefore in MPLS-TP the MEL field is allowed not to be used for
   supporting tandem connection monitoring.

   When OAM PDUs are used in MPLS-TP, the MEL field MUST be set on
   transmission and checked at reception for compliancy with Y.1731 [2].

   The MEL value to set and check MUST be configurable. The DEFAULT
   value MUST be "111". With co-routed bidirectional transport paths,
   the configured MEL MUST be the same in both directions.

   The OpCode field identifies the type of the OAM PDU.

   The setting of the Version, Flags and TLV Offset is OpCode specific
   and described in Y.1731 [2].

4. MPLS-TP OAM Packet Formats

   This section describes the OAM functions that can be supported
   reusing the OAM PDUs and procedures defined in Y.1731 [2] to meet
   MPLS-TP OAM Requirements, as defined in [8].


Busi and al.            Expires July 11, 2012                 [Page 7]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   This document is proposing not to use the Y.1731 MCC OAM PDU in
   MPLS-TP. The solution proposed in [7], where MCC PDU is directly
   encapsulated within an ACH with a PID, SHOULD be used instead.

   The LTM/LTR OAM PDUs, as currently defined Y.1731 [2], are tracing
   the path for a specific MAC address: this tool is therefore
   addressing a different requirement than the "Route Tracing"
   functional requirement described in section 2.2.4 of RFC 5860 [8].
   Their purpose is to test the MAC Address Forwarding tables. Due to
   the fact that MPLS-TP forwarding is not based on the MAC Address
   Forwarding tables, these tools are not applicable to MPLS-TP as
   currently defined.

   Procedures for supporting the route tracing MPLS-TP OAM functional
   requirement (section 2.2.4 of RFC 5860 [8]) are outside the scope of
   this document.

4.1. Continuity Check Message (CCM)

   The CCM PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
   TP as described in section 3, it can be used to support the following
   MPLS-TP OAM functional requirements:

   o  Pro-active continuity check (section 2.2.2 of RFC 5860 [8]);

   o  Pro-active connectivity verification (section 2.2.3 of RFC 5860
      [8]);

   o  Pro-active remote defect indication (section 2.2.9 of RFC 5860
      [8]);

   o  Pro-active packet loss measurement (section 2.2.11 of RFC 5860
      [8]).

   Procedures for transmitting and receiving CCM PDUs are defined in
   Y.1731 [2] and described in section 5.1.

   It is worth noting that the use of CCM does not require any
   additional status information other than the configuration parameters
   and defect states.

   The transmission period of the CCM MUST always be the configured
   period and MUST not change unless the operator reconfigures it. This
   is a fundamental requirement to allow deterministic and predictable



Busi and al.            Expires July 11, 2012                 [Page 8]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   protocol behavior: in transport networks the operator configures and
   fully controls the repetition rate of pro-active CC-V.

   In order to perform pro-active Connectivity Verification, the CCM
   packet contains a globally unique identifier of the source MEP, as
   described in [6].

   The source MEP for LSPs, PWs and Sections is identified by combining
   a globally unique MEG ID (see section 4.1.1) with a MEP ID that is
   unique within the scope of the Maintenance Entity Group.

4.1.1. MEG ID Formats

   The generic format for MEG ID is defined in Figure A-1 of Y.1731 [2].
   Different formats of MEG ID are allowed: the MEG ID format type is
   identified by the MEG ID Format field.

   The format of the ICC-based MEG ID is defined in Annex A of Y.1731
   [2]. This format is applicable to MPLS-TP Sections, LSPs and PWs.

   MPLS-TP supports also IP-based format for MEG ID. These formats are
   still under definition in [12] and therefore outside the scope of
   this document.

4.2. OAM Loopback (LBM/LBR)

   The LBM/LBR PDUs, defined in Y.1731 [2]. When encapsulated within
   MPLS-TP, as described in section 3, they can be used to support the
   following MPLS-TP OAM functional requirements:

   o  On-demand bidirectional connectivity verification  (section 2.2.3
      of RFC 5860 [8]);

   o  Bidirectional in-service or out-of-service diagnostic test (section
      2.2.5 of RFC 5860 [8]).

   Procedures for transmitting and receiving LBM/LBR PDUs are defined in
   Y.1731 [2] and described in section 5.2.

   It is worth noticing that these OAM PDUs cover different functions
   than those defined in [11].

   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 July 11, 2012                 [Page 9]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   path is locked on both sides by network management operations.
   However, single-ended procedures as defined in [11] MAY be used.

   In order to allow proper identification of the target MEP/MIP the LBM
   is addressed to, the LBM PDU MUST include the Target MEP/MIP ID TLV:
   this TLV MUST be present in an LBM PDU and MUST be located at the top
   of the TLVs (i.e., it MUST start at the offset indicated by the TLV
   Offset field).

   A LBM packet with the Target MIP/MEP ID equal to the ID of receiving
   MIP or MEP is considered to be a valid LBM packet. Every field in the
   LBM packet is copied to the LBR packet, only the OpCode field is
   changed from LBM to LBR.

   To allow proper identification of the actual MEP/MIP that has replied
   to an LBM PDU, the LBR PDU MUST include the Replying MEP/MIP ID TLV:
   this TLV MUST be present in an LBR PDU and it MUST be located at the
   top of the TLVs (i.e., it MUST start at the offset indicated by the
   TLV Offset field).

   In order to simplify hardware based implementations, these TLVs have
   been defined to have a fixed position (as indicated by the TLV Offset
   field) and a fixed length (see clause 4.2.1).

   It is worth noting that the MEP/MIP identifiers used in the Target
   MEP/MIP ID and in the Replying MEP/MIP ID TLVs SHOULD be unique
   within the scope of the MEG. When LBM/LBR OAM is used for
   connectivity verification purposes, there are some misconnectivity
   cases that could not be easily located by simply relying upon these
   TLVs. In order to locate these misconnectivity configurations, the
   LBM PDU SHOULD carry a Requesting MEP ID TLV that provides a globally
   unique identification of the MEP that has originated the LBM PDU.
   When the Requesting MEP ID TLV is present in the LBM PDU, the
   replying MIP/MEP MUST check that the received requesting MEP
   identifier matches with the expected requesting MEP identifier before
   replying. In this case, the LBR PDU MUST carry the Requesting MEP ID
   TLV confirming to the MEP the LBR PDU is sent to that the Requesting
   MEP ID TLV in the LBM PDU has been checked before replying.

   When LBM/LBR OAM is used for bidirectional diagnostic tests, the
   Requesting MEP ID TLVs MUST NOT be included.

   The format of the LBM and LBR PDUs are shown in Figure 2 and in
   Figure 3.



Busi and al.            Expires July 11, 2012                [Page 10]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|  Y.1731 Channel Type (0xXXXX) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MEL | Version |    OpCode     |     Flags     |   TLV Offset  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Transaction ID/Sequence Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Target MEP/MIP ID TLV                      |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               [optional Requesting MEP ID TLV]                |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | [other optional TLV starts here]                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     End TLV     |
      +-+-+-+-+-+-+-+-+-+

                        Figure 2 LBM Packet Format

   The OpCode MUST be set to 0x03 (LBM). The TLV Offset MUST be set to
   0x04. The formats of the Target MEP/MIP ID TLV and of the Requesting
   MEP ID TLV are defined in 4.2.1.

   The Target MEP/MIP ID MUST be always present as the first TLV within
   the LBM PDU. When present, the Requesting MEP ID TLV MUST immediately
   follow the Target MEP/MIP ID TLV.

   When the LBM packet is sent to a target MIP, the source MEP MUST know
   the hop count to the target MIP and set the TTL field accordingly, as
   described in [6].

   This solution allows supporting per-node and per-interface MIP
   implementations as described in section 3.4 of [6]:

   o  In the case of a per-node MIP implementation, the LBM packet is
      processed in the per-node MIP if the Target MEP/MIP ID matches the
      per-node MIP identifier; otherwise, the LBM packet is dropped;







Busi and al.            Expires July 11, 2012                [Page 11]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   o  In the case of a per-interface MIP implementation, the LBM packet
      is processed in the ingress MIP if the Target MEP/MIP ID matches
      the ingress MIP identifier; otherwise, the LBM packet is forwarded
      to the egress port(s) together (i.e., fate sharing) with the user
      data packets. The LBM packet is processed in the egress MIP if the
      Target MEP/MIP ID matches the egress MIP identifier; otherwise,
      the LBM packet is dropped.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|  Y.1731 Channel Type (0xXXXX) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MEL | Version |    OpCode     |     Flags     |   TLV Offset  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Transaction ID/Sequence Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Replying MEP/MIP ID TLV                     |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               [optional Requesting MEP ID TLV]                |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | [other optional TLV starts here]                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     End TLV     |
      +-+-+-+-+-+-+-+-+-+

                        Figure 3 LBR Packet Format

   The Replying MEP/MIP ID TLV MUST be present as the first TLV within
   the LBR PDU. When present, the Requesting MEP ID TLV MUST follow the
   Replying MEP/MIP ID TLV within the LBR PDU.

4.2.1. Format of MEP and MIP ID TLVs

   The format of the Target and Replying MIP/MEP ID TLVs are shown in
   Figure 4 and Figure 5.








Busi and al.            Expires July 11, 2012                [Page 12]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (0x21)  |          Length (25)          |   Sub-Type    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      |      MEP/MIP Identifier (format is ID Sub-Type specific)      |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4 Target MEP/MIP ID TLV format

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (0x22)  |          Length (25)          |   Sub-Type    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      |      MEP/MIP Identifier (format is ID Sub-Type specific)      |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5 Replying MEP/MIP ID TLV format

   Different formats of MEP/MIP identifiers MAY be used: the format type
   is described by the MEP/MIP ID Sub-Type field.

   The "Discovery ingress/node MEP/MIP" and the "Discovery egress
   MEP/MIP" identifiers MAY only be used within the LBM PDU (and MUST
   NOT appear in an LBR PDU) for discovering the identifiers of the MEPs
   or of the MIPs located at a given TTL distance from the MEP
   originating the LBM PDU.

   The format of the Target MEP/MIP ID TLV carrying a "Discovery
   ingress/node MEP/MIP" is shown in Figure 6.











Busi and al.            Expires July 11, 2012                [Page 13]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (0x21)  |          Length (25)          |Sub-Type (0x00)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      |                          MUST be ZERO                         |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6 Target MEP/MIP ID TLV format (discovery ingress/node
                                 MEP/MIP)

   The format of the Target MEP/MIP ID TLV carrying a "Discovery egress
   MEP/MIP" is shown in Figure 7.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (0x21)  |          Length (25)          |Sub-Type (0x01)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      |                          MUST be ZERO                         |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 7 Target MEP/MIP ID TLV format (discovery egress MEP/MIP)

   The format of the Target or Replying MEP/MIP ID TLV carrying an
   "ICC-based MEP ID" is shown in Figure 8.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |          Length (25)          |Sub-Type (0x02)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MEP ID            |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                              ...                              |
      |                          MUST be ZERO                         |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 8 Target or Replying MEP/MIP ID TLV format (ICC-based MEP ID)



Busi and al.            Expires July 11, 2012                [Page 14]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   The MEP ID is a 16-bit integer value identifying the transmitting MEP
   within the MEG.

   The format of the Target or Replying MEP/MIP ID TLV carrying an
   "ICC-based MIP ID" is shown in Figure 9.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |          Length (25)          |Sub-Type (0x03)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    ITU-T Carrier Code (ICC)                   |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |            Node-ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Node-ID            |             IF-Num            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IF-Num            |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                              ...                              |
      |                          MUST be ZERO                         |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 9 Target or Replying MEP/MIP ID TLV format (ICC-based MIP ID)

   The ITU-T Carrier Code (ICC) is a code assigned to a network
   operator/service provider and maintained by the ITU-T
   Telecommunication Standardization Bureau (TSB) as per [13].

   The Node-ID is a numeric identifier of the node where the MIP is
   located. Its assignment is a matter for the organization to which the
   ICC has been assigned, provided that uniqueness within that
   organization is guaranteed.

   The IF-Num is a numeric identifier of the Access Point (AP) toward
   the server layer trail, which can be either an MPLS-TP or a non
   MPLS-TP server layer, where a per-interface MIP is located. Its
   assignment is a matter for the node the MIP is located, provided that
   uniqueness within that node is guaranteed. Note that the value 0 for
   IF-Num is reserved to identify per-node MIPs.

   MPLS-TP supports also IP-based format for MIP and MEP identifiers.
   These formats are still under definition in [12] and therefore
   outside the scope of this document.


Busi and al.            Expires July 11, 2012                [Page 15]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   The format of the Requesting MEP ID TLVs is shown in Figure 10.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (0x23)  |          Length (53)          | Loopback Ind. |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MEP ID            |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                             MEG ID                            |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |       Reserved (0x0000)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 10Requesting MEP ID TLV format

   The MEP ID and MEG ID carry the globally unique MEP ID as defined in
   section 4.1.1.

   The Reserved bits MUST be set to all-ZEROes in transmission and
   ignored in reception.

   The Loopback Indication MUST be set to 0x0000 when this TLV is
   inserted in an LBM PDU and SHOULD be set to 0x0001 in the LBR PDU.
   This is used to indicate that the value of this TLV has been checked
   by the node that generated the LBR PDU.

4.3. Alarm Indication Signal (AIS)

   The AIS PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
   TP, as described in section 3, it can be used to support the alarm
   reporting MPLS-TP OAM functional requirement (section 2.2.8 of RFC
   5860 [8]).

   Procedures for transmitting and receiving AIS PDUs are defined in
   Y.1731 [2] and described in section 5.3.

4.4. Lock Reporting (LCK)

   The LCK PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
   TP, as described in section 3, it can be used to support the lock
   reporting MPLS-TP OAM functional requirement (section 2.2.7 of RFC
   5860 [8]).


Busi and al.            Expires July 11, 2012                [Page 16]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   Procedures for transmitting and receiving LCK PDUs are defined in
   Y.1731 [2] and described in section 5.4.

4.5. Test (TST)

   The TST PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
   TP, as described in section 3, it can be used to support the
   uni-directional in-service or out-of-service diagnostic tests MPLS-TP
   OAM functional requirement (section 2.2.8 of RFC 5860 [8]).

   Procedures for transmitting and receiving TST PDUs are defined in
   Y.1731 [2] and described in section 5.5.

4.6. Loss Measurement (LMM/LMR)

   The LMM/LMR PDUs are defined in Y.1731 [2]. When encapsulated within
   MPLS-TP, as described in section 3, they can be used to support on-
   demand packet loss measurement MPLS-TP OAM functional requirement
   (section 2.2.11 of RFC 5860 [8]).

   Procedures for transmitting and receiving LMM/LMR PDUs are defined in
   Y.1731 [2] and described in section 5.6.

4.7. One-way delay measurement (1DM)

   The 1DM PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
   TP, as described in section 3, it can be used to support the on-
   demand one-way packet delay measurement MPLS-TP OAM functional
   requirement (section 2.2.12 of RFC 5860 [8]).

   It can also be used to support proactive one-way delay measurement
   MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]).

   Procedures for transmitting and receiving 1DM PDUs are defined in
   Y.1731 [2] and described in section 5.7.

4.8. Two-way delay Measurement Message/Reply (DM)

   The DMM/DMR PDUs are defined in Y.1731 [2]. When encapsulated within
   MPLS-TP, as described in section 3, they can be used to support on-
   demand two-ways packet delay measurement MPLS-TP OAM functional
   requirement (section 2.2.12 of RFC 5860 [8]).





Busi and al.            Expires July 11, 2012                [Page 17]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   They can also be used to support proactive two-ways packet delay
   measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC
   5860 [8]).

   Procedures for transmitting and receiving DMM/DMR PDUs are defined in
   Y.1731 [2] and described in section 5.8.

4.9. Client Signal Fail (CSF)

   The CSF PDU is defined in Y.1731 Amendment 1 [3]. When encapsulated
   within MPLS-TP, as described in section 3, it can be used to support
   the client failure indication MPLS-TP OAM functional requirement
   (section 2.2.10 of RFC 5860 [8]).

   Procedures for transmitting and receiving CSF PDUs are defined in
   Y.1731 Amendment 1 [3] and described in section 5.9.

5. MPLS-TP OAM Procedures

   The high level procedures for processing Y.1731 OAM PDUs are
   described in [2] and [3]. The technology independent procedures are
   also applicable to MPLS-TP OAM.

   More detailed and formal procedures for processing Y.1731 OAM PDUs
   are defined in G.8021 [4]. Although the description in [4] is
   Ethernet-specific, the technology independent procedures are also
   applicable to MPLS-TP OAM.

   This section describes the MPLS-TP OAM procedures based on the
   technology independent ones defined in [2], [3] and [4].

5.1. Continuity Check Message (MT-CCM) procedures

   The MT-CCM PDU format is defined in section 4.1.

   When CCM generation is enabled, the MEP MUST generate CCM OAM packets
   with the periodicity and the PHB configured by the operator:

   o  MEL field MUST be set to the configured value (see section 3);

   o  Version field MUST be set to 0 (see section 3);

   o  OpCode field MUST be set to 0x01 (see section 4.1);




Busi and al.            Expires July 11, 2012                [Page 18]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   o  RDI flag MUST be set, if the MEP asserts signal file. Otherwise,
      it MUST be cleared;

   o  Reserved flags MUST be set to 0 (see section 4.1);

   o  Period field MUST be set according to the configured periodicity
      (see Table 9-3 of [2]);

   o  TLV Offset field MUST be set to 70 (see section 4.1);

   o  Sequence Number MUST be set to 0 (see section 4.1);

   o  MEP ID and MEG ID fields MUST carry the configured values;

   o  The TxFCf field MUST carry the current value of the counter for
      in-profile data packets transmitted towards the peer MEP, when
      pro-active loss measurement is enabled. Otherwise it MUST be set
      to 0.

   o  The RxFCb field MUST carry the current value of the counter for
      in-profile data packets received from the peer MEP, if pro-active
      loss measurement is enabled. Otherwise it MUST be set to 0.

   o  The TxFCb field MUST carry the value of TxFCf of the last received
      CCM PDU from the peer MEP, if pro active loss measurement is
      enabled. Otherwise it MUST be set to 0.

   o  Reserved field MUST be set to 0 (see section 4.1);

   o  End TLV MUST be inserted after the Reserved field (see section
      4.1).

   The transmission period of the CCM is always the configured period
   and does not change unless the operator reconfigures it.

   When a MEP receives a CCM OAM packet, it checks the various fields
   (see Figure 8-19 of [4]). The following defects are detected as
   described in clause 6.1 of [4]: dLOC, dUNL, dMMG, dUNM, dUNP, dUNPr
   and dRDI.

   If the Version, MEL, MEG and MEP fields are valid and pro-active loss
   measurement is enabled, the values of the packet counters are
   processed as described in clause 8.1.7.4 of [4].




Busi and al.            Expires July 11, 2012                [Page 19]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


5.2. OAM Loopback (MT-LBM/LBR) procedures

   The MT-LBM/LBR PDU formats are defined in section 4.2.

   When an out-of-service OAM loopback function is performed, client
   data traffic is disrupted in the diagnosed ME. The MEP configured for
   the out-of-service test MUST transmit MT-LCK packets in the immediate
   client (sub-)layer, as described in section 5.4.

   When an in-service OAM loopback function is performed, client data
   traffic is not disrupted and the packets with MT-LBM/LBR information
   are transmitted in such a manner that a limited part of the service
   bandwidth is utilized. The periodicity for packets with MT-LBM/LBR
   information is pre-determined.

   When on-demand OAM loopback is enabled at a MEP, the (requesting) MEP
   MUST generate and send to one of the MIPs or the peer MEP MT-LBM OAM
   packets with the periodicity and the PHB configured by the operator:

   o  MEL field MUST be set to the configured value (see section 3);

   o  Version field MUST be set to 0 (see section 3);

   o  OpCode field MUST be set to 0x03 (see section 4.2);

   o  Flags field MUST be set to all-ZEROes (see section 4.2);

   o  TLV Offset field MUST be set to 4 (see section 4.2);

   o  Transaction field is a 4-octet field that contains the transaction
      ID/sequence number for the loop-back measurement;

   o  Target MEP/MIP-ID and Originator MEP-ID fields are set to carry
      the configured values;

   o  Optional TLV field whose length and contents are configurable at
      the requesting MEP. The contents can be a test pattern and an
      optional checksum. Examples of test patterns include pseudo-random
      bit sequence (PRBS) (2^31-1) as specified in sub-clause 5.8/O.150,
      all '0' pattern, etc. For bidirectional diagnostic test
      application, configuration is required for a test signal generator
      and a test signal detector associated with the MEP;

   o  End TLV field is set to all-ZEROes (see section 4.2).



Busi and al.            Expires July 11, 2012                [Page 20]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   Whenever a valid MT-LBM packet is received by a (receiving) MIP or a
   (receiving) MEP, an MT-LBR packet is generated and transmitted by the
   receiving MIP/MEP to the requesting MEP:

   o  MEL field MUST be copied from the received MT-LBM PDU;

   o  Version field MUST be copied from the received MT-LBM PDU;

   o  OpCode field MUST be set to 2 (see section 4.2);

   o  Flags field MUST be copied from the received MT-LBM PDU;

   o  TLV Offset field MUST be copied from the received MT-LBM PDU;

   o  Transaction field MUST be copied from the received MT-LBM PDU

   o  The Target MEP/MIP-ID and Originator MEP-ID fields are is set to
      the value which is copied from the last received MT-LBM PDU;

   o  The Optional TLV field MUST be copied from the received MT-LBM
      PDU;

   o  End TLV field MUST be inserted after the last TLV field and it
      MUST be copied from the last received MT-LBM PDU.

5.3. Alarm Indication Signal (MT-AIS) procedures

   The MT-AIS PDU format is described in section 4.3.

   When the server layer trail termination sink asserts signal fail, it
   notifies the server/MT_A_Sk function that raises the aAIS consequent
   action. The aAIS is cleared when the server layer trail termination
   clears the signal fail condition and notifies the server/MT_A_Sk.

   When the aAIS consequent action is raised, the server/MT_A_Sk MUST
   continuously generate MPLS-TP OAM packets carrying the AIS PDU until
   the aAIS consequent action is cleared:

   o  MEL field MUST be set to the configured value (see section 3):

   o  Version field MUST be set to 0 (see section 3):

   o  OpCode MUST be set to 0x21 (see section 4.3):

   o  Reserved flags MUST be set to 0 (see section 4.3):


Busi and al.            Expires July 11, 2012                [Page 21]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   o  Period field MUST be set according to the configure periodicity
      (see Table 9-4 of [2]);

   o  TLV Offset MUST be set to 0 (see section 4.3):

   o  End TLV MUST be inserted after the TLV Offset field (see section
      4.3).

   The DEFAULT periodicity for MT-AIS is once per second.

   The generated AIS packets MUST be inserted in the incoming stream,
   i.e., the output stream contains the incoming packets and the
   generated AIS packets.

   When a MEP receives an AIS packet with the correct MEL value, it MUST
   detect the dAIS defect as described in clause 6.1 of [4].

5.4. Lock Reporting (LCK)

   The MT-LCK PDU format is described in section 4.4.

   When the access to the server layer trail is administratively locked
   by the operator, the server/MT_A_So and server/MT_A_Sk functions
   raise the aLCK consequent action. The aLCK is cleared when the access
   to the server layer trail is administratively unlocked.

   When the aLCK consequent action is raised, the server/MT_A_So and
   server/MT_A_Sk MUST continuously generate, on both directions,
   MPLS-TP OAM packets carrying the LCK PDU until the aLCK consequent
   action is cleared:

   o  MEL field MUST be set to the configured value (see section 3):

   o  Version field MUST be set to 0 (see section 3):

   o  OpCode MUST be set to 0x23 (see section 4.4):

   o  Reserved flags MUST be set to 0 (see section 4.4):

   o  Period field MUST be set according to the configure periodicity
      (see Table 9-4 of [2]);

   o  TLV Offset MUST be set to 0 (see section 4.4):




Busi and al.            Expires July 11, 2012                [Page 22]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   o  End TLV MUST be inserted after the TLV Offset field (see section
      4.4).

   The DEFAULT periodicity for MT-LCK is once per second.

   When a MEP receives an LCK packet with the correct MEL value, it
   detects the dLCK defect as described in clause 6.1 of [4].

5.5. Test (TST)

5.6. Loss Measurement (LMM/LMR)

5.7. One-way delay measurement (1DM)

5.8. Two-way delay Measurement Message/Reply (DM)

5.9. Client Signal Fail (CSF)

6. Security Considerations

   Spurious OAM messages, such as those defined in this document,
   potentially could form a vector for a denial of service attack.
   However, since these messages are carried in a control channel, one
   would have to gain access to a node providing the service in order to
   launch such an attack.  Since transport networks are usually operated
   as a walled garden, such threats are less likely.

7. IANA Considerations

   IANA is requested to allocate a Channel Type value 0xXXXX to identify
   an associated channel carrying all the OAM PDUs that are defined in
   section 4

   [Editor's note - The value 0x8902 has been proposed to keep the
   channel type identical to the EtherType value used in Ethernet OAM]

8. Acknowledgments

   The authors gratefully acknowledge the contributions of Malcolm
   Betts, Zhenlong Cui, Feng Huang, Kam Lam, Jian Yang, Haiyan Zhang for
   the definition of extensions to LBM/LBR required for supporting
   on-demand connectivity verification OAM functions.

   The authors would like to thank all the members of the CCSA for their
   comments and support.


Busi and al.            Expires July 11, 2012                [Page 23]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   The authors would also like to thank Brian Branscomb, Feng Huang, Kam
   Lam, Fang Li, Akira Sakurai and Yaakov Stein for their comments and
   enhancements to the text.

   This document was prepared using 2-Word-v2.0.template.dot.









































Busi and al.            Expires July 11, 2012                [Page 24]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


9. References

9.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   ITU-T Recommendation Y.1731 (02/08), "OAM functions and
         mechanisms for Ethernet based networks", February 2008

   [3]   ITU-T Recommendation Y.1731 Amendment 1 (07/10), "OAM functions
         and mechanisms for Ethernet based networks", July 2010

   [4]   ITU-T Recommendation G.8021 (12/07), "Characteristics of
         Ethernet transport network equipment functional blocks",
         December 2007

   [5]   Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
         "MPLS Generic Associated Channel", RFC 5586, June 2009

   [6]   Busi, I., Allan, D., " Operations, Administration and
         Maintenance Framework for MPLS-based Transport Networks",
         draft-ietf-mpls-tp-oam-framework-11 (work in progress),
         February 2011

   [7]   Beller, D., Farrel, A., "An Inband Data Communication Network
         For the MPLS Transport Profile", RFC 5718, January 2010

9.2. Informative References

   [8]   Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", RFC 5860, May 2010

   [9]   Li, F., Li, H., D'Alessandro, A., Jing, R., Wang, G., "Operator
         Considerations on MPLS-TP OAM Mechanisms",
         draft-fang-mpls-tp-oam-considerations-02 (work in progress),
         July 2011

   [10]  Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping",
         draft-ietf-pwe3-oam-msg-map-16 (work in progress), April 2011

   [11]  Boutros, S., et al., "Operating MPLS Transport Profile LSP in
         Loopback Mode", draft-ietf-mpls-tp-li-lb-02 (work in progress),
         June 2011



Busi and al.            Expires July 11, 2012                [Page 25]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   [12]  Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-ietf-
         mpls-tp-identifiers-02 (work in progress), July 2010

   [13]  ITU-T Recommendation M.1400 (07/06), " Designations for
         interconnections among operators' networks", July 2006

   [14]  IEEE Standard 802.1ag-2007, "IEEE Standard for Local and
         Metropolitan Area Networks: Connectivity Fault Management",
         September 2007

Author's Addresses

   Italo Busi (Editor)
   Alcatel-Lucent

   Email: Italo.Busi@alcatel-lucent.com


   Huub van Helvoort (Editor)
   Huawei Technologies

   Email: hhelvoort@huawei.com


   Jia He (Editor)
   Huawei Technologies

   Email: hejia@huawei.com


Contributing Authors' Addresses

   Christian Addeo
   Alcatel-Lucent

   Email: Christian.Addeo@alcatel-lucent.com


   Alessandro D'Alessandro
   Telecom Italia

   Email: alessandro.dalessandro@telecomitalia.it





Busi and al.            Expires July 11, 2012                [Page 26]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   Simon Delord
   Telstra

   Email: simon.a.delord@team.telstra.com


   John Hoffmans
   KPN

   Email: john.hoffmans@kpn.com


   Ruiquan Jing
   China Telecom

   Email: jingrq@ctbri.com.cn


   Hing-Kam (Kam) Lam
   Alcatel-Lucent

   Email: Kam.Lam@alcatel-lucent.com


   Wang Lei
   China Mobile Communications Corporation

   Email: wangleiyj@chinamobile.com


   Han Li
   China Mobile Communications Corporation

   Email: lihan@chinamobile.com


   Vishwas Manral
   IPInfusion Inc

   Email: vishwas@ipinfusion.com







Busi and al.            Expires July 11, 2012                [Page 27]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   Masahiko Mizutani
   Hitachi, Ltd.

   Email: masahiko.mizutani.ew@hitachi.com


   Manuel Paul
   Deutsche Telekom

   Email: Manuel.Paul@telekom.de


   Josef Roese
   Deutsche Telekom

   Email: Josef.Roese@t-systems.com


   Vincenzo Sestito
   Alcatel-Lucent

   Email: vincenzo.sestito@alcatel-lucent.com


   Yuji Tochio
   Fujitsu

   Email: tochio@jp.fujitsu.com


   Munefumi Tsurusawa
   KDDI R&D Labs

   Email: tsuru@kddilabs.jp


   Maarten Vissers
   Huawei Technologies

   Email: maarten.vissers@huawei.com







Busi and al.            Expires July 11, 2012                [Page 28]


Internet-Draft       MPLS-TP OAM based on Y.1731          January 2012


   Rolf Winter
   NEC

   Email: Rolf.Winter@nw.neclab.eu










































Busi and al.            Expires July 11, 2012                [Page 29]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/