MPLS Working Group                                                L. Xia
Internet-Draft                                                   M. xiao
Intended status: Informational                                    X. Dai
Expires: January 28, 2011                                        J. Yang
                                                         ZTE Corporation
                                                           July 27, 2010


                       MPLS-TP P2MP OAM analysis
                 draft-xia-mpls-tp-p2mp-oam-analysis-00

Abstract

   This document attempts to analyze MPLS-TP P2MP OAM implementations
   and related problems by combining with MPLS-TP P2MP network
   characteristics and the MPLS-TP OAM requirements.  We give a specific
   analysis to some key issues in P2MP scenarios.  And we analyze every
   MPLS-TP OAM function in P2MP scenarios and give guidelines or
   recommendations.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 28, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Xia, et al.             Expires January 28, 2011                [Page 1]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Movitation and Scope . . . . . . . . . . . . . . . . . . .  3
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  MPLS P2MP signaling technology overview  . . . . . . . . .  5
     1.5.  MPLS-TP P2MP OAM requirements and current solutions  . . .  5
   2.  P2MP key issues  . . . . . . . . . . . . . . . . . . . . . . .  9
     2.1.  Scalability issue  . . . . . . . . . . . . . . . . . . . .  9
     2.2.  Return path  . . . . . . . . . . . . . . . . . . . . . . .  9
     2.3.  P2MP Node Identifier TLV . . . . . . . . . . . . . . . . .  9
     2.4.  TTL setting and handle . . . . . . . . . . . . . . . . . . 10
     2.5.  Bud node analysis  . . . . . . . . . . . . . . . . . . . . 11
     2.6.  SPME OAM in P2MP . . . . . . . . . . . . . . . . . . . . . 13
     2.7.  Locally independence requirements  . . . . . . . . . . . . 13
     2.8.  Per-interface MIP/MEP  . . . . . . . . . . . . . . . . . . 13
   3.  P2MP OAM Functions Analysis  . . . . . . . . . . . . . . . . . 14
     3.1.  Continuity Check and Pro-active Connectivity
           Verification and Remote Defect Indication  . . . . . . . . 14
     3.2.  Alarm Reporting and Lock Reporting . . . . . . . . . . . . 15
     3.3.  On-demand Connectivity Verification and Route Tracing  . . 16
     3.4.  Diagnostic Tests . . . . . . . . . . . . . . . . . . . . . 17
       3.4.1.  Throughput Estimation  . . . . . . . . . . . . . . . . 17
       3.4.2.  Data Plane Loopback  . . . . . . . . . . . . . . . . . 18
     3.5.  Lock Instruct  . . . . . . . . . . . . . . . . . . . . . . 19
     3.6.  Client Failure Indication  . . . . . . . . . . . . . . . . 19
     3.7.  Packet Loss Measurement  . . . . . . . . . . . . . . . . . 20
     3.8.  Packet Delay Measurement . . . . . . . . . . . . . . . . . 20
   4.  P2MP PW analysis . . . . . . . . . . . . . . . . . . . . . . . 20
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24









Xia, et al.             Expires January 28, 2011                [Page 2]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


1.  Introduction

1.1.  Movitation and Scope

   MPLS-TP OAM provides efficient and reliable methods for fault
   management and performance monitoring.  It also can help operators to
   meet the SLAs while reducing their operational costs.

   [RFC5654] in general, and [RFC5860] in particular define a set of
   requirements for OAM functionality applied to MPLS-TP Label Switched
   Paths (LSPs) (network infrastructure) and Pseudowires (PWs)
   (services).  [I-D.ietf-mpls-tp-oam-analysis] has given an analysis to
   those existing OAM tools defined for MPLS and in ITU-T, including LSP
   Ping, MPLS BFD, VCCV, and Y.1731.  It has identified which tools need
   to be extended to comply with the MPLS-TP OAM requirements, and which
   new tools need to be defined.

   Based on above documents, some drafts concerning specific OAM tool
   have been worked out.  Including
   [I-D.ietf-mpls-tp-lsp-ping-bfd-procedures],
   [I-D.ietf-mpls-tp-cc-cv-rdi],
   [I-D.nitinb-mpls-tp-lsp-ping-extensions], etc.

   The current situation is that these above drafts mainly focus on the
   analysis and implementation of P2P OAM, and they do not have enough
   in-depth analysis with respect to P2MP OAM.

   Then this document attempts to analyze MPLS-TP P2MP OAM
   implementations and related problems by combining with MPLS-TP P2MP
   network characteristics and the MPLS-TP OAM requirements.  Solutions
   are provided for some problems, and others need further study.

   This document is arranged as follows: first, an overview of MPLS P2MP
   technology and MPLS-TP P2MP OAM requirements with current solutions,
   which is given as a starting point for following discussion;
   secondly, from the structure point of view, a specific analysis is
   given to some key issues; finally, from a functional perspective,
   every MPLS-TP P2MP OAM function is analyzed and guidelines or
   recommendations are given.

1.2.  Conventions

   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 [RFC2119].






Xia, et al.             Expires January 28, 2011                [Page 3]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


1.3.  Abbreviations

   ACH: Associated Channel Header

   BFD: Bidirectional Forwarding Detection

   CC: Continuity Check

   CRC: Cyclic Redundancy Check

   CV: Connectivity Verification

   DM: Packet Delay Measurement

   LB: Loopback

   LDP: Label Distribution Protocol

   LM: Loss Measurement

   LSP: Label Switched Path

   MEG: Maintenance Entity Group

   MEP: Maintenance Entity Group End Point

   MIP: Maintenance Entity Group Intermediate Point

   MPLS-TP: MPLS Transport Profile

   OAM: Operations, Administration and Maintenance

   P2P: Point to Point

   P2MP: Point to MultiPoint

   PW: PseudoWire

   RSVP-TE: Resource Reservation Protocol-Traffic Engineering

   SLA: Service Level Agreement

   SPME: Sub-Path Maintenance Element

   TLV: Type Length Value

   VCCV: Virtual Circuit Connection Verification




Xia, et al.             Expires January 28, 2011                [Page 4]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


1.4.  MPLS P2MP signaling technology overview

   P2MP service is used to deliver data from a single source to one or
   more receivers.  This service can be simply supported by combination
   of P2P LSPs.  But the fully efficient way (mainly refer to bandwidth
   consumption, numbers of used LSPs) to support P2MP service is using
   P2MP LSP.  P2MP LSP has only one ingress LSR,but may have one or more
   egress LSRs.  Data traffic is efficiently replicated in branch LSRs.
   Signaling requirements for the P2MP TE LSPs can refer to [RFC4461].

   Currently, there are two kinds of signaling protocol mechanisms to
   build P2MP LSP:

   1.  Extensions to RSVP-TE protocol for P2MP TE LSPs([RFC4875]):This
       solution relies on the semantics of the Resource Reservation
       Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs.  It
       doesn't require a multicast routing protocol in the Service
       Provider core.  A P2MP LSP is comprised of multiple source-to-
       leaf (S2L) sub-LSPs.  These S2L sub-LSPs are set up between the
       ingress and egress LSRs and are appropriately combined by the
       branch LSRs using RSVP semantics to result in a P2MP TE LSP.  One
       Path message may signal one or multiple S2L sub-LSPs for a single
       P2MP LSP.  Hence the S2L sub-LSPs belonging to a P2MP LSP can be
       signaled using one Path message or split across multiple Path
       messages.

   2.  LDP Extensions for P2MP and MP2MP LSPs([I-D.ietf-mpls-ldp-p2mp]):
       These extensions are also referred to as mLDP Multicast LDP. mLDP
       constructs the P2MP or MP2MP LSPs without interacting with or
       relying upon any other multicast tree construction protocol.
       Leaf nodes initiate P2MP LSP setup and tear-down.  Leaf nodes
       also install forwarding state to deliver the traffic received on
       a P2MP LSP to wherever it needs to go.  Transit nodes install
       MPLS forwarding state and propagate the P2MP LSP setup (and tear-
       down) toward the root.  The root node installs forwarding state
       to map traffic into the P2MP LSP.

   MPLS-TP decides to build P2MP TE LSP by using RSVP-TE signaling
   protocol in Control Plane or by static configuration in Management
   Plane.  LDP Extensions for P2MP is outside the scope of this
   document.

1.5.  MPLS-TP P2MP OAM requirements and current solutions

   MPLS-TP OAM is running on Data Plane.  So, its implementation
   mechanism must be based on the characteristics of the data plane.
   The basic characteristics of the data plane in P2MP network is a
   unidirectional tree topology.  Data traffic is sent from the only one



Xia, et al.             Expires January 28, 2011                [Page 5]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   ingress LSR, and replicated in branch LSRs, received by all (one or
   more) egress LSRs.

   MPLS P2MP OAM requirements([RFC4687]) analyzes from various
   functional point of view, including Detection and Diagnosis of LSP
   Defects, Path Characterization, SLA Measurement, Frequency of OAM
   Execution, Alarm Suppression, Fault Notification, etc.  It gives the
   general requirements and related high-level analysis about OAM
   implementations in P2MP MPLS network.

   MPLS-TP OAM Requirements ([RFC5860]) analyzes the OAM requirements in
   MPLS-TP network from the architectural and functional these two
   aspects.  The table below gives a summary about P2MP part in this
   document:


+-----------+------------+-----------+---------------+---------+-----------+
|   Item    | pro-active | on-demand |   path type   |   P2MP  |   out of  |
|           |            |           |               |         |    band   |
|           |            |           |               |         |   return  |
|           |            |           |               |         |    path   |
|           |            |           |               |         |    for    |
|           |            |           |               |         |    P2MP   |
+-----------+------------+-----------+---------------+---------+-----------+
|    CC     |   support  |    no     |      E2E      | support |  no need  |
|           |            |  support  |               |         |           |
|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|    CV     |   support  |  support  | pro-active:   | support | on-demand |
|           |            |           | E2E,          |         |    need   |
|           |            |           | on-demand:E2E |         |           |
|           |            |           |  or E2I       |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|   Route   |     no     |  support  |   E2E or E2I  | support |    need   |
|  Tracing, |   support  |           |               |         |           |
| Diagnostic|            |           |               |         |           |
|   Tests   |            |           |               |         |           |
|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|   Lock    |   support  |     no    |      I2E      | support |  no need  |
| Reporting,|            |  support  |               |         |           |
|   Alarm   |            |           |               |         |           |
| Reporting |            |           |               |         |           |
|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|  Remote   |   support  |     no    |      E2E      | support |    need   |
|  Defect   |            |  support  |               |         |           |
| Indication|            |           |               |         |           |



Xia, et al.             Expires January 28, 2011                [Page 6]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|  Client   |   support  |     no    |      E2E      | support |  no need  |
| Failure   |            |   support |               |         |           |
| Indication|            |           |               |         |           |
|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|  Packet   |   support  |   support |      E2E      | support |  no need  |
|   Loss    |            |           |               |         |           |
|Measurement|            |           |               |         |           |
|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+
|  Packet   |   support  |   support |      E2E      | one way |  no need  |
|   Delay   |            |           |               |  delay: |           |
|Measurement|            |           |               | support |           |
|           |            |           |               | two way |           |
|           |            |           |               |  delay  |           |
|           |            |           |               | : no    |           |
|           |            |           |               | support |           |
|           |            |           |               |         |           |
+-----------+------------+-----------+---------------+---------+-----------+


               Figure 1: MPLS_TP P2MP OAM requirements table

   Notes:

   1)  The abbreviations in column "path type" of E2E, E2I, I2E means
       separately end point to end point, end point to intermediate
       point, intermediate point to end point;

   2)  Out of band return path for P2MP: P2MP LSP is an unidirectional
       path from the ingress node to all of the egress nodes in Data
       Plane.  So the return path here referred does not exist in Data
       Plane.  It mainly refers to the Control Plane or IP routing
       return path.  It is usually called out of band return path.

   MPLS-TP OAM analysis document ([I-D.ietf-mpls-tp-oam-analysis])
   analyzes the current OAM tools defined for MPLS and ITU-T, and gives
   the conclusions about whether existing OAM tools can be used to meet
   the MPLS-TP OAM requirements, and identify which tools need to be
   extended to comply with the requirements and which new tools need to
   be defined.  Based on this document, many specific OAM tools
   implementation documents have been produced.  The table below gives a
   summary of OAM tools implementation which is also applied to P2MP
   scenario:





Xia, et al.             Expires January 28, 2011                [Page 7]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   +--------------+-----------------+-----------------+----------------+
   |     Items    | Recommendations |       Gaps      |    Solutions   |
   +--------------+-----------------+-----------------+----------------+
   |  Pro-active  | Extend MPLS BFD |     MPLS BFD    |   use ACH for  |
   | CC-V, Remote |     to fully    |   requires IP   |     non-IP     |
   |    Defect    |     support     |  encapsulation  |  encapsulation |
   |   Indication |                 |-----------------+----------------|
   |              |                 |  For CV, basic  |  define a new  |
   |              |                 |      BFD's      | type ACH and a |
   |              |                 |  limitation of  |     new TLV    |
   |              |                 |  locally unique |  carrying the  |
   |              |                 |  (to each node) |  unique source |
   |              |                 |     session     | MEP Identifier |
   |              |                 |   identifiers   |                |
   +--------------+-----------------+-----------------+----------------+
   |   On-demand  | Extend LSP Ping |     LSP Ping    |   use ACH for  |
   |   CV, Route  |     to fully    |   requires IP   |     non-IP     |
   |    Tracing   |     support     |  encapsulation  | encapsulation  |
   |              |                 |-----------------+----------------|
   |              |                 |  How to arrive  | Proper setting |
   |              |                 |   intermediate  |   of the TTL   |
   |              |                 |       node      |     value      |
   |              |                 |-----------------+----------------|
   |              |                 |     Global      |      Add new   |
   |              |                 | identifiers for |     type TLVs  |
   |              |                 | Source Address, |                |
   |              |                 |   MEP, MIP etc  |                |
   +--------------+-----------------+-----------------+----------------+
   |     Lock     | Extend LSP Ping |     PDU and     |    Refer to    |
   |   Instruct   |    to support   |    procedure    |     Y.1731     |
   |              |                 |    definition   |                |
   +--------------+-----------------+-----------------+----------------+
   |     Alarm    |   Define a new  |     PDU and     |    Refer to    |
   |  Reporting,  |  PDU which will |    procedure    |     Y.1731     |
   |     Lock     |  be transmitted |    definition   |                |
   |  Reporting,  |  over G-ACH to  |                 |                |
   |  Diagnostic  |     support     |                 |                |
   |    Tests,    |                 |                 |                |
   |  Packet Loss |                 |                 |                |
   | Measurement, |                 |                 |                |
   | Packet Delay |                 |                 |                |
   |  Measurement |                 |                 |                |
   +--------------+-----------------+-----------------+----------------+
   |    Client    |  Use PWE3 tool  |     PDU and     |   Define new   |
   |    Failure   |   to propagate  |    procedure    |                |
   |  Indication  |   Client Fail   |    definition   |                |
   |              |  Indication via |                 |                |
   |              |      an ACH     |                 |                |



Xia, et al.             Expires January 28, 2011                [Page 8]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   +--------------+-----------------+-----------------+----------------+



       Figure 2: MPLS-TP P2MP OAM tools implementation summary table


2.  P2MP key issues

2.1.  Scalability issue

   Scalability is a key requirement in P2MP network.  Since the number
   of egresses for a single P2MP LSP is unknown and not bounded by any
   small number, it follows that all mechanisms defined for OAM support
   MUST scale well with the number of egresses and the complexity of the
   path of the LSP.  So, P2MP OAM mechanisms MUST be designed to scale
   well with an increase in the number of any of the sink MEPs and MIPs.

   Scalability is a high-level and general requirement.  How to achieve
   it needs further study on every specific OAM tool.

2.2.  Return path

   P2MP LSP is inherently an unidirectional path from the ingress node
   to all of the egress nodes in Data Plane.  And in band return path
   does not exist in Data Plane.  So, it can not directly support the
   OAM mechanism which needs to return a confirmation message.  For
   example, On-demand CV, Route Tracing, etc.  In this case, we have
   three general solutions:

   1.  Out of band return path: It mainly refers to the Control Plane or
       IP routing return path;

   2.  In band return path: Building a P2P LSP from an egress node to
       ingress node in Data Plane to be the in band return path;

   3.  Extending existed OAM tools to run without the support of return
       path.  This solution needs further study.

2.3.  P2MP Node Identifier TLV

   P2MP Node Identifier TLV here means the TLV attribute that was
   brought in the OAM packet, and contains enough information to
   uniquely identify the destination MEP or MIP node.  It is also called
   P2MP Responder Identifier TLV in [I-D.ietf-mpls-p2mp-lsp-ping].

   In a P2MP LSP, the ingress node can be the only one source MEP, all
   the branch nodes in the middle of the P2MP tree can be the MIPs, all



Xia, et al.             Expires January 28, 2011                [Page 9]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   of the bud nodes can be both sink MEPs and MIPs, all egress nodes can
   be sink MEPS.

   In general, OAM packets sent from the source MEP, through the Data
   Plane, forwarded to all sink MEPs, should be processed by each sink
   MEPs.  If the OAM packets are required to be processed only by one or
   a group of designated sink MEPs, but not all sink MEPs, then a new
   extending mechanism--- P2MP Node Identifier TLV can achieve it.

   An OAM packet transmitted by the source MEP can carry a number of
   P2MP Node Identifier TLVs, corresponding to a group of designated
   sink MEPs.  This OAM packet is forwarded through Data Plane, to reach
   all sink MEPs.  Sink MEPs can use those P2MP Node Identifier TLVs
   carried in the OAM packet to decide how to process this OAM packet.
   A sink MEP will process the OAM packet only when it matches a P2MP
   Node Identifier TLV in the OAM packet, or else it should discard the
   OAM packet.  Of course, if an OAM packet does not carry any P2MP Node
   Identifier TLV, it should be processed by all sink MEPs.

   The P2MP Node Identifier TLV only has meaning on an OAM message which
   is sent from source MEP to sink MEPs.  If present on a return OAM
   message, it SHOULD be ignored.

   Sometimes, OAM packets need to be processed by one or a group of
   designated MIPs.  In this case, except for P2MP Node Identifier TLV,
   but also needs TTL together to locate the designated MIPs.  Section
   2.4 will give a more detailed description about it.

   One possibility is that the number of sink MEPs or MIPS which need to
   process an OAM packet is too large to carry all P2MP Node Identifier
   TLVs in an OAM packet.  In order to handle this problem, source MEP
   can set the max number of P2MP Node Identifier TLVs in an OAM packet
   and transmit the OAM packet for several times.

   The TLV format based on IP address and the details of using it are
   defined in [I-D.ietf-mpls-p2mp-lsp-ping], the non-IP definition needs
   further study.

2.4.  TTL setting and handle

   In the case of MPLS-TP P2P LSP,when an OAM packet needs to be
   processed by a MIP, it must properly set the TTL value to be the hop
   number from the MEP to MIP, together with the only Node Identifier
   TLV carried in the OAM packet to verify the validity of the
   destination MIP.

   P2MP LSP also has the same requirement.  There are three cases when
   an OAM packet transmitted from the source MEP needs to be processed



Xia, et al.             Expires January 28, 2011               [Page 10]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   by one or a group of MIPs in the P2MP LSP, as follow:

   1.  Case one: Destination is one MIP.  After properly setting the TTL
       value and the P2MP Node Identifier TLV carried in the OAM packet,
       the source MEP sends the OAM packet out, and then the OAM packet
       is terminated in those MIPs whose hop number from the source MEP
       is equal to the setting of TTL value.  These MIPs decide whether
       to process the OAM packet by checking the P2MP Node Identifier
       TLV in the OAM packet.  At last, only one MIP will process the
       OAM packet and other MIPs should discard the OAM packet.

   2.  Case two: Destination is a group of MIPs which have the same hop
       number from the source MEP.  The TTL setting and processing is
       similar with case one, the only difference is that the OAM packet
       needs to carry more than one P2MP Node Identifier TLVs or no P2MP
       Node Identifier TLV(aimed to all MIPs with the same TTL value).
       At last, these group(or all) MIPs will process the OAM packet and
       other MIPs should discard the OAM packet.

   3.  Case three: Destination includes a group of MIPs which have the
       different hop number from the source MEP.  In this case, the
       source MEP must construct more than one OAM packets with
       different TTL value, the destination of every OAM packet is a
       group of MIPs which have the same hop number from the source MEP.
       Every OAM packet can carry more than one P2MP Node Identifier
       TLVs.

   The above process solutions have a premise that the source MEP
   already knew the hop number between itself and each designated MIP.

   In above process, one possibility is that some sink MEPs may have
   less hop number from the source MEP than the TTL value setted in the
   OAM packet.  In this case, how to process the OAM packet is nothing
   to do with the TTL value, and the OAM packet must be terminated in
   the sink MEPs.  When the OAM packet carrys the Node Identifier TLVs,
   the sink MEPs will discard the OAM packet because of the mismatch of
   the P2MP Node Identifier TLV.  If not, [I-D.ietf-mpls-p2mp-lsp-ping]
   has provided a solution of a new "Respond Only If TTL Expired" flag
   to reduce extraneous responses from sink MEPs.

2.5.  Bud node analysis

   In a P2MP LSP, the bud node can be not only a MIP, but also a sink
   MEP.

   As a MIP, the bud node should forward all the OAM packets whose
   destination is the downstream MIPs or sink MEPs.  At the same time as
   a sink MEP, the bud node must do a copy of every OAM packet it



Xia, et al.             Expires January 28, 2011               [Page 11]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   received to handle.

   We can describe a bud node function logically in the below figure:


                             --------------------------
                            |     |           |        |
                            |  |->|    MEP    |        |
                            |  |   -----------         |
                            |  |                       |
                            |  |                  -----|
                            |  | copy         ->-|     |->----
                            |  |             |   | Out |
                            |  ^             |   | i/f |
                            |  |       ----  |    -----|
                            |-----    |  f | |         |
                            | MIP |   |  o | |    -----|
                            |     |   |  r |-    |     |
                     ----->-| In  |->-|  w |--->-| Out |->----
                            | i/f |   |  a |-    | i/f |
                            |-----    |  r | |    -----|
                            |         |  d | |         |
                            |          ----  |    -----|
                            |                |   |     |
                            |                 ->-| Out |->----
                            |                    | i/f |
                            |                     -----|
                             --------------------------





                     Figure 3: Bud node logic function

   From the figure above, we can see that the MEP in bud node gets a
   copy of the OAM packet it received to handle.  This copy of OAM
   packet is nothing to do with the OAM packets forward to downstream
   nodes of the bud node.  So, the defects such as LOC of CC or
   unintended connectivity between two MEPs (e.g. mismerging or
   misconnection or unexpected MEP) of CV and so on, found by the MEP in
   the bud node are also nothing to do with the downstream nodes of the
   bud node.

   In general, although the bud node takes two roles of MIP and sink
   MEP, but these two functions are still running independent of each
   other. the OAM processing results of MEP can not in turn affect the
   MIP operation.



Xia, et al.             Expires January 28, 2011               [Page 12]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


2.6.  SPME OAM in P2MP

   SPME OAM in P2P LSP scenarios is intended to be used for monitoring
   the behavior of a portion of a P2P LSP or a set of co-routed P2P
   LSPs.  It is implemented by means of setting the two end nodes of the
   SPME to be MEPs and utilizing label stack to support multiple layer
   operation.

   Similarly, SPME OAM can also be used in P2MP LSP tree scenarios,
   intended to be used for monitoring the behavior of a sub-tree of a
   P2MP LSP tree.  In this case, it needs to set the root and all leaf
   nodes of the sub-tree to be MEPs, and still utilizes label stack to
   support multiple layer operation.  And the sub-tree SPME OAM MEG is
   independent of the P2MP LSP tree OAM MEG.  The OAM packet belong to
   the latter MEG is considered a common data packet in former MEG and
   should be forwarded in Data Plane without any OAM operations.  The
   OAM packet belong to the former MEG is only forwarded and performs
   OAM operation between MEPs of itself, and will not leak to the latter
   MEG.

   More complex, if a sub-tree exists in more than one P2MP LSP trees,
   it is preferred to implement only a sub-tree SPME OAM MEG for this
   sub-tree.  This sub-tree SPME OAM MEG can provide monitoring for all
   P2MP LSP trees.  So it does not need to have a sub-tree SPME OAM MEG
   for every above P2MP LSP tree.  Specially, when the middle portion
   multiplexing rate of multiple P2MP LSPs is relatively high, the
   method is particularly applicable.

2.7.  Locally independence requirements

   A P2MP LSP tree may contain many branches and sub-trees.  From
   scalability point of view, it requires that the partial changes
   happened in a sub-tree only affect this sub-tree OAM functions and
   can not affect the OAM functions of the other part of the P2MP LSP.
   These partial changes include the add, delete, modification of the
   sub-tree or the leafs.

   This issue needs more examples to perform a more in-depth analysis!

2.8.  Per-interface MIP/MEP

   Per-interface MIP/MEP model is the extended and enhancement
   definition of the two basic concepts of MIP and MEP.  Compare to the
   traditional Per-node MIP/MEP model, MIP and MEP can be defined and
   run on the in interface or out interface of a node.  Because of the
   more precise location of MIP and MEP, per-interface MIP/MEP model can
   provide more effective and more precise OAM functions such as a
   proactive continuity check, proactive on-demand connectivity



Xia, et al.             Expires January 28, 2011               [Page 13]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   verification, on-demand route tracing, on-demand loss measurement,
   on-demand delay measurement and diagnostic test than per-node MIP/MEP
   model.

   [I-D.koike-ietf-mpls-tp-oam-maintenance-points] provides the
   requirements and definitions of the Per-interface MIP/MEP model and
   its implementations in every OAM function.
   [I-D.farrel-mpls-tp-mip-mep-map] describes a way of forming OAM
   messages so that they can be targeted at incoming MIPs and outgoing
   MIPs, forwarded correctly through the "switch fabric", and handled
   efficiently in optimized node implementations where there is no
   distinction between the incoming and outgoing MIP.  The contents of
   these two documents can all directly apply to P2MP scenarios.

   As for P2MP scenarios, the Per-interface MIP model in branch node
   needs focus attention and study.  Branch node has one in
   interface,more than one out interfaces.  They can all be set to be
   MIPs so that get more precise fault location or performance
   monitoring information than traditional Per-node model.


3.  P2MP OAM Functions Analysis

3.1.  Continuity Check and Pro-active Connectivity Verification and
      Remote Defect Indication

   As specified in [I-D.ietf-mpls-tp-oam-framework]:

   o   CC(Continuity Check) monitors the integrity of the continuity of
       the path for any loss of continuity defect by pro-actively
       sending OAM packet.

   o   Pro-active CV(Connectivity Verification) monitors the integrity
       of the routing of the path between sink and source for any
       connectivity issues by pro-actively sending OAM packet.

   o   RDI(Remote Defect Indication) enables an End Point to report, to
       its associated End Point, a fault or defect condition that it
       detects on a path.

   According to [I-D.ietf-mpls-tp-oam-analysis], they can all be fully
   supported by Extending MPLS BFD.

   Currently, [I-D.ietf-mpls-tp-cc-cv-rdi] has already given the
   definitions and descriptions of how MPLS BFD supports the above three
   pro-active OAM functions.

   RDI requires bidirectional path support.  So, RDI cannot be supported



Xia, et al.             Expires January 28, 2011               [Page 14]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   directly in P2MP scenario because of the inherently unidirectional
   characteristics of P2MP, unless an out of band return path from sink
   MEP to source MEP exists.

   For CC and pro-active CV,below is a comparison between the P2MP LSP
   and P2P LSP:

   o   Source MEP: Only one source MEP per LSP.  The format and
       semantics of the extended MPLS BFD packet for P2P LSP CC and pro-
       active CV function do not need any changes to identify the source
       MEP in the P2MP LSP.  So the implementation of this two OAM
       functions in the source MEP has no difference between the P2MP
       LSP and the P2P LSP.

   o   Sink MEP: Only one sink MEP in a P2P LSP.  P2MP LSP is extended
       to have one or more sink MEPs.  However, each sink MEP of the
       P2MP LSP can run the OAM packets receiving and LSP defects
       detection of the CC and pro-active CV function independently, and
       exactly the same as the sink MEP of P2P LSP.

   o   The transmission of the OAM packet: P2MP LSP inherently supports
       to forward the OAM packet from source MEP to all sink MEPs in
       Data Plane.  Since each sink MEP runs the OAM function
       independently from each other,the CC and pro-active CV function
       in P2MP LSP can be considered a group of OAM functions
       independently and simultaneously running between the source MEP
       and each sink MEP.  In this respect, there is no essential
       difference between P2MP LSP and the P2P LSP.

   In summary, the definition and implementation of the CC and pro-
   active CV in [I-D.ietf-mpls-tp-cc-cv-rdi] can be applied directly on
   the P2MP LSP.

3.2.  Alarm Reporting and Lock Reporting

   The MPLS-TP Alarm Indication Signal (AIS) message is generated in
   response to detecting defects in the server layer.

   The MPLS-TP Locked Report (LKR) message is generated when a server
   layer entity has been administratively locked to communicate that
   condition to inform the client layer entities.

   These two kinds of OAM messages are immediately sent to the client
   MEPs by inserting them into the affected paths in the direction
   opposite to the detecting MEP's peer server MEP(s) after they are
   once generated.  Their primary purpose is to suppress alarms in the
   MPLS-TP layer network above the level at which the defect occurs.
   The AIS message MAY be used to trigger recovery mechanisms.



Xia, et al.             Expires January 28, 2011               [Page 15]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   These two OAM functions are all inter-layer functions.  For P2MP LSP
   scenario, there are two kinds of situations:

   o   P2MP LSP as a client layer: The server layer which carries it is
       Section layer, or P2MP/P2P LSP SPME sub-layer.  These two server
       layers have exactly the same treatment to the messages.  Next,
       Section layer is introduced as an example.  Section monitoring is
       running between two directly connected nodes, intention to detect
       bidirectional defects or administrative locking between them.
       When a node has detected above events, AIS or LKR messages will
       be immediately generated in the node and inserted into P2MP LSP
       client layer.  Because the P2MP LSP is unidirectional, these two
       kinds of OAM messages are also unidirectional.  They are
       forwarded along the direction of the P2MP LSP to notify the
       defect or administrative locking to all downstream sink MEPs of
       the node.  These messages can suppress alarms in the downstream
       sink MEPs.  The AIS message MAY be used to trigger recovery
       mechanisms.

   o   P2MP LSP as a server layer: The client layer carried above it can
       be PW, LSP, IP, etc layer.  In this case, the sink MEPs of the
       P2MP LSP are the intermediate point of the above client layer.
       The defect or administrative locking of the unidirectional P2MP
       LSP detected in the sink MEPs will cause the generation of AIS or
       LKR messages and inserted them into the client layer.  These
       messages are forwarded along the direction of the P2MP LSP to
       notify the defect or administrative locking to the end MEP of the
       client layer.  These messages can suppress alarms in the end MEP
       of the client layer.  The AIS message MAY be used to trigger
       recovery mechanisms.

   The above contents analysis the AIS and LKR implementation in P2MP
   LSP.  In general, the current AIS and LKR
   mechanism([I-D.ietf-mpls-tp-fault]) can apply to P2MP LSP without
   problem.

3.3.  On-demand Connectivity Verification and Route Tracing

   On-demand CV(Connectivity Verification) enables an End Point to
   determine whether or not it is connected to specific End Point(s) by
   means of the expected PW, LSP or Section, or is connected to specific
   Intermediate Point(s) by means of the expected PW, LSP.

   On-demand Route Tracing enables an End Point to discover the
   Intermediate (if any) and End Point(s) along a PW, LSP or Section,
   and more generally to trace the route of a PW, LSP or Section.  The
   information collected MUST include identifiers related to the nodes
   and interfaces composing that route.



Xia, et al.             Expires January 28, 2011               [Page 16]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   According to the OAM analysis, they can all be fully supported by
   Extending LSP Ping.

   Currently, [I-D.nitinb-mpls-tp-lsp-ping-extensions] has already given
   the definitions and descriptions of how LSP Ping supports the above
   two on-demand OAM functions.

   The process of these two OAM functions is basically the same, the
   echo request message is generated in source MEP, forwarded to the
   destination sink MEPs or MIPs.  They return echo response with result
   after some processes.  So, these two OAM functions all need return
   path.  Because P2MP LSP is a unidirectional LSP without in band
   return path by itself, the return path is a key issue of these two
   OAM functions.  The analysis about return path discussed in section
   2.2 is applicable here.

   On-demand CV function send OAM messages from source MEP to any MIPs
   or sink MEPs by using P2MP Node Indentifier TLV and proper TTL value.
   These OAM packets carry the TLVs(including source address TLV, MEP/
   MIP id TLV, etc) for connectivity verification.  The destination
   nodes(MIPs or sink MEPs) use these TLVs for connectivity verification
   and return response message with result to source MEP.

   Route Tracing is implemented by using Downstream Detailed Mapping
   TLV.  This TLV can be used for transit, branch or bud node to return
   multiple Return Codes for different downstream paths.

   [I-D.ietf-mpls-p2mp-lsp-ping] has defined an extended LSP Ping
   mechanism for supporting MPLS P2MP scenarios.  Whether this mechanism
   can be directly applied to MPLS-TP P2MP scenarios without problem or
   some new problems generated to be resolved needs further study.

3.4.  Diagnostic Tests

3.4.1.  Throughput Estimation

   As specified in [I-D.ietf-mpls-tp-oam-framework], throughput
   estimation is an on-demand out-of-service function, which allows
   verifying the bandwidth/throughput of an MPLS-TP transport path (LSP
   or PW) before it is put in-service.  Throughput estimation is
   performed between MEPs and can be performed in one-way or two-way
   modes.

   When applied to P2MP transport path, only one-way throughput
   estimation can be performed in case a return path exists.  Also note
   that there are two options for throughput estimation on P2MP
   transport path, one is that respective throughput result can be
   obtained for each ME between the root and each specific leaf, another



Xia, et al.             Expires January 28, 2011               [Page 17]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   one is that only one throughput result can be obtained for the MEG
   between the root and all leaves.  Just like throughput estimation in
   P2P transport path, two simple measurement methods can be used to
   estimate throughput in P2MP transport path, one is binary search
   method and another one is to increase sending rate (up to the
   theoretical maximum) of OAM test packets in fixed step until OAM test
   packets begin to drop.

   For the option 1 that respective throughput result can be obtained
   for each ME, the two measurement methods mentioned above can be used
   in different way.  When the binary search method is used, each
   independent throughput estimation process will be needed for each ME
   between the root and each specific leaf, which requires the source
   MEP to send a single OAM packet which contains sufficient information
   to identify a target leaf, and therefore is processed only by the
   target leaf and ignored by the other leaves.  When the other method
   described above is used, only one throughput estimation process will
   be needed and also the individual throughput result will be obtained
   for each ME, also note that with this method the precision of
   measurement result is lower compared with the binary search method.

   For the option 2 that only one throughput result can be obtained for
   the MEG, the two measurement methods mentioned above can be used in
   the same way.  When the binary search method is used, like the other
   method that increase sending rate in fixed step, only one throughput
   estimation process will be needed for the MEG between the root and
   all leaves, which requires the source MEP to send a single OAM packet
   to all leaves and is processed by all leaves at the same time, and
   packet loss will be judged by emerging packet loss at any leaf.

3.4.2.  Data Plane Loopback

   As specified in [I-D.ietf-mpls-tp-oam-framework], data plane loopback
   is an out-of-service function, which permits all traffic (including
   user data and OAM except for the OAM used for this function)
   originated at the ingress of a transport path or inserted by the test
   equipment to be looped back in the direction of the point of origin
   by an interface at either an intermediate node or a terminating node.

   Due to the specific function mechanism of data plane loopback, this
   function is applicable to co-routed bidirectional path when it's
   performed at an intermediate node, and applicable to co-routed
   bidirectional or associated bidirectional path when it's performed at
   an end node.  So with P2MP path, it's only applicable at a leaf node
   in case an associated bidirectional path exists.  Also note that when
   this function is performed with P2MP path, at any time only one leaf
   node can be set as loopback mode, otherwise the root can't
   distinguish from which leaf the received traffic is looped back.



Xia, et al.             Expires January 28, 2011               [Page 18]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


3.5.  Lock Instruct

   Lock Instruct function is a command which allows a MEP to instruct
   its peer MEP(s) to put a MPLS-TP transport path into a locked
   condition.  This function allows single-side and two side provisions,
   only the former requires a lock instruct message be sent to the peer
   MEP(s).

   For a P2MP transport path, there may be no return path to the lock
   instruct request MEP.  So no response message is needed in this case,
   or can sends a response via a control plane protocol if the control
   plane exists.  Under this situation, the peer MEP(s) should always
   accept the lock instruction.

   Currently, there is no standardized mechanism defined in the IETF to
   support this function.

   In general, the recommendation is to define a new tool and PDU to
   support Lock Instruct.  Some material useful for this scope can be
   found in [I-D.boutros-mpls-tp-loopback] and
   [I-D.dai-mpls-tp-lock-instruct].

3.6.  Client Failure Indication

   The CFI function is used to propagate the information of a client's
   defect or fault condition through the MPLS-TP network from edge to
   edge in case the client layer OAM functionality does not provide an
   alarm notification function.  This defect or fault is detected at and
   end point of a PW or LSP.

   when used on a P2MP transport path, if this defect is detected by the
   root node, this CFI message will be sent through this P2MP path to
   all the leaves, and mapped to the associted ACs; however, if this
   defect is detected by a leaf node, this condition should also be
   propagated to the root node, so this requires a P2P return path from
   this leaf node to the root node.

   Static PW status([I-D.ietf-pwe3-static-pw-status]) can be used to
   perform this function on a PW .  However, the peer node shoud
   identify it's a fault on the AC or on the PW.  There is no mechanism
   defined in IETF to support this functionality for P2MP LSP.

   So, It needs to define a new tool and PDU to support this
   functionality for CFI function in MPLS-TP P2MP scenarios.  Some
   material useful for this scope can be found in [I-D.he-mpls-tp-csf]
   and [I-D.ietf-pwe3-static-pw-status].





Xia, et al.             Expires January 28, 2011               [Page 19]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


3.7.  Packet Loss Measurement

   LM(Loss Measurement) is an OAM toolset which provides a function to
   enable the quantification of packet loss ratio over a PW, LSP or
   Section.

   The Implementation of LM function in P2MP LSP is similar to which in
   P2P LSP.  The source MEP send LM query messages periodically to all
   sink MEPs, every sink MEP uses a group of related counter values to
   calculate its own packet loss ratio.  So, the LM mechanism defined
   and described in [I-D.frost-mpls-tp-loss-delay] can be directly
   applied to MPLS-TP P2MP LSP.

   The existed problems of LM function in P2P LSP such as message loss
   and packet misorder conditions and congestion also exist and are more
   serious in P2MP LSP.  These questions all need a unified solution
   with P2P LSP.

   For P2MP LSP, there is a specific requirement to support LM function
   in designated egress node of a P2MP LSP.  This requirement can be
   implemented by setting proper P2MP Node Identifier TLV.

3.8.  Packet Delay Measurement

   DM(Delay Measurement) is an OAM toolset which provides a function to
   enable the quantification of the one-way, and if appropriate, the
   two-way, delay of a PW, LSP or Section.

   Unidirectional P2MP LSP can only implement one-way DM function.  The
   mechanism is similar to which in P2P LSP.  The source MEP send DM
   query messages with timestamp of sending time to all sink MEPs, every
   sink MEP can use the timestamp and the receiving time to calculate
   its own one-way delay.  One-way DM function requires that the clocks
   of source MEP and all sink MEPs be synchronized.  So, the on-way DM
   mechanism defined and described in [I-D.frost-mpls-tp-loss-delay] can
   be directly applied to MPLS-TP P2MP LSP.

   Like LM function, there is a specific requirement to support DM
   function in designated egress node of a P2MP LSP.  This requirement
   can be implemented by setting proper P2MP Node Identifier TLV.


4.  P2MP PW analysis

   To be added in a later version of this document.






Xia, et al.             Expires January 28, 2011               [Page 20]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


5.  IANA Considerations

   To be added in a later version of this document.


6.  Security Considerations

   To be added in a later version of this document.


7.  Acknowledgements

   To be added in a later version of this document.


8.  References

8.1.  Normative References

   [I-D.boutros-mpls-tp-loopback]
              Boutros, S., Sivabalan, S., Swallow, G., Ward, D., Bryant,
              S., Pignataro, C., Aggarwal, R., Bitar, N., Vigoureux, M.,
              Busi, I., Levrau, L., and L. Ciavaglia, "Operating MPLS
              Transport Profile LSP in Loopback Mode",
              draft-boutros-mpls-tp-loopback-03 (work in progress),
              March 2010.

   [I-D.dai-mpls-tp-lock-instruct]
              Dai, X., Bo, W., and J. Yang, "MPLS-TP Lock Instruction",
              draft-dai-mpls-tp-lock-instruct-00 (work in progress),
              October 2009.

   [I-D.farrel-mpls-tp-mip-mep-map]
              Farrel, A. and H. Endo, "Handling MPLS-TP OAM Packets
              Targeted at Internal MIPs",
              draft-farrel-mpls-tp-mip-mep-map-02 (work in progress),
              July 2010.

   [I-D.frost-mpls-tp-loss-delay]
              Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for the MPLS Transport Profile",
              draft-frost-mpls-tp-loss-delay-02 (work in progress),
              June 2010.

   [I-D.he-mpls-tp-csf]
              Jia, H., Li, H., and E. Bellagamba, "Indication of Client
              Failure in MPLS-TP", draft-he-mpls-tp-csf-02 (work in
              progress), July 2010.



Xia, et al.             Expires January 28, 2011               [Page 21]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


   [I-D.ietf-mpls-ldp-p2mp]
              Minei, I., Kompella, K., Wijnands, I., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", draft-ietf-mpls-ldp-p2mp-10 (work in progress),
              July 2010.

   [I-D.ietf-mpls-p2mp-lsp-ping]
              Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau,
              T., and S. Saxena, "Detecting Data Plane Failures in
              Point-to-Multipoint Multiprotocol Label Switching (MPLS) -
              Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-10
              (work in progress), March 2010.

   [I-D.ietf-mpls-tp-cc-cv-rdi]
              Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan,
              S., and D. Ward, "Proactive Connection Verification,
              Continuity Check and Remote Defect indication for MPLS
              Transport Profile", draft-ietf-mpls-tp-cc-cv-rdi-01 (work
              in progress), July 2010.

   [I-D.ietf-mpls-tp-fault]
              Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
              Ward, D., Bryant, S., and S. Sivabalan, "MPLS Fault
              Management OAM", draft-ietf-mpls-tp-fault-02 (work in
              progress), July 2010.

   [I-D.ietf-mpls-tp-lsp-ping-bfd-procedures]
              Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher,
              N., and Y. Weingarten, "LSP-Ping and BFD encapsulation
              over ACH", draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00
              (work in progress), March 2010.

   [I-D.ietf-mpls-tp-oam-requirements]
              Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS
              Transport Networks",
              draft-ietf-mpls-tp-oam-requirements-06 (work in progress),
              March 2010.

   [I-D.ietf-pwe3-static-pw-status]
              Martini, L., Swallow, G., and M. Bocci, "Pseudowire Status
              for Static Pseudowires",
              draft-ietf-pwe3-static-pw-status-00 (work in progress),
              February 2010.

   [I-D.nitinb-mpls-tp-lsp-ping-extensions]
              Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "LSP-
              Ping extensions for MPLS-TP",



Xia, et al.             Expires January 28, 2011               [Page 22]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


              draft-nitinb-mpls-tp-lsp-ping-extensions-01 (work in
              progress), February 2010.

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

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
              Operations, Administration, and Maintenance (OAM) in MPLS
              Transport Networks", RFC 5860, May 2010.

8.2.  Informative References

   [I-D.ietf-mpls-tp-oam-analysis]
              Sprecher, N., Bellagamba, E., and Y. Weingarten, "MPLS-TP
              OAM Analysis", draft-ietf-mpls-tp-oam-analysis-02 (work in
              progress), July 2010.

   [I-D.ietf-mpls-tp-oam-framework]
              Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A.,
              Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito,
              V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten,
              Y., and R. Winter, "MPLS-TP OAM Framework",
              draft-ietf-mpls-tp-oam-framework-07 (work in progress),
              July 2010.

   [I-D.koike-ietf-mpls-tp-oam-maintenance-points]
              Paul, M. and Y. Koike, "MPLS-TP OAM Maintenance Points",
              draft-koike-ietf-mpls-tp-oam-maintenance-points-01 (work
              in progress), March 2010.

   [RFC4461]  Yasukawa, S., "Signaling Requirements for Point-to-
              Multipoint Traffic-Engineered MPLS Label Switched Paths
              (LSPs)", RFC 4461, April 2006.

   [RFC4687]  Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
              "Operations and Management (OAM) Requirements for Point-



Xia, et al.             Expires January 28, 2011               [Page 23]


Internet-Draft        P2MP OAM analysis for MPLS-TP            July 2010


              to-Multipoint MPLS Networks", RFC 4687, September 2006.


Authors' Addresses

   Liang Xia
   ZTE Corporation

   Email: xia.liang2@zte.com.cn


   Min Xiao
   ZTE Corporation

   Email: xiao.min2@zte.com.cn


   XueHui Dai
   ZTE Corporation

   Email: dai.xuehui@zte.com.cn


   Jian Yang
   ZTE Corporation

   Email: yang_jian@zte.com.cn
























Xia, et al.             Expires January 28, 2011               [Page 24]