Framework for Point-to-Multipoint MPLS-TP OAM
draft-hmk-mpls-tp-p2mp-oam-framework-03

MPLS Working Group                                        Y.Koike, Ed.
Internet Draft                                               T.Hamano
                                                             M.Namiki
                                                                  NTT
Intended status: Informational

Expires: March 20, 2014                               October 21, 2013

               Framework for Point-to-Multipoint MPLS-TP OAM
                draft-hmk-mpls-tp-p2mp-oam-framework-03.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on March 20, 2014.

Copyright Notice

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

Koike, et al.          Expires March 20, 2014                 [Page 1]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   publication of this document. Please review these documents carefully,
   as they describe your rights and restrictions with respect to this
   document. Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

Abstract

   The MPLS transport profile (MPLS-TP) is being standardized to enable
   carrier-grade packet transport.

   This document discusses and specifies the P2MP framework primarily
   related to OAM and related management in MPLS-TP networks. This
   document mainly refers to RFC5654 and RFC6371. The main focus is on
   the details that are not covered or not clarified in relevant RFCs
   such as RFC5654, RFC5860, RFC5921, RFC5951, RFC6371, and draft-mpls-
   tp-p2mp-framework.

   Note: This I-D was made and updated including the discussions in ITU-
   T SG15, which were described in Liaison Statements such as
   (https://datatracker.ietf.org/liaison/1235/)

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network.

Table of Contents

   1. Introduction ................................................ 3
   2. Conventions used in this document............................ 4
      2.1. Terminology ............................................ 4
      2.2. Definitions ............................................ 5
   3. P2MP OAM and management...................................... 5
      3.1. General aspects of architecture ......................... 5
         3.1.1. Return path........................................ 5
         3.1.2. M-leaves management scenario in P2MP path........... 6

Koike, et al.          Expires March 20, 2014                 [Page 2]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

         3.1.3. Refinement of existing requirements on P2MP transport
         path ..................................................... 7
         3.1.4. Addition and removal of branch tree in P2MP transport
         path ..................................................... 8
      3.2. General aspects of P2MP OAM............................. 8
      3.3. OAM functions for proactive monitoring ................. 11
         3.3.1. Continuity Check and Connectivity Verification(CC-V)11
         3.3.2. Remote Defect Indication.......................... 12
         3.3.3. Alarm Reporting................................... 12
         3.3.4. Lock Reporting.................................... 12
         3.3.5. Packet Loss Measurement........................... 12
         3.3.6. Packet Delay Measurement.......................... 12
         3.3.7. Client Failure Indication ......................... 12
      3.4. OAM functions for on-demand monitoring ................. 12
         3.4.1. Connectivity verification ......................... 12
         3.4.2. Packet loss measurement........................... 13
         3.4.3. Diagnostic tests.................................. 13
         3.4.4. Route Tracing..................................... 13
         3.4.5. Packet delay measurement.......................... 13
      3.5. OAM functions for administration control ............... 13
         3.5.1. Lock Instruct..................................... 13
   4. Layer Models ............................................... 14
   5. Applicable Scenarios........................................ 15
   6. Security Considerations..................................... 15
   7. IANA Considerations ........................................ 15
   8. References ................................................. 15
      8.1. Normative References................................... 15
      8.2. Informative References................................. 15
   9. Acknowledgments ............................................ 16

1. Introduction

   The demand for P2MP traffic is expected to quickly increase due to
   the increase in new services such as IP-TV,compressed & uncompressed
   video distribution, and smart TV. In light of the global trend in
   improving energy efficiency as well as general network cost reduction,
   a point-to-multipoint (P2MP) transport function in MPLS-TP could be
   one of the solutions for providing these services from the
   perspective of efficient use of network resources.

   RFC5654[1] defines the following requirements that are specific to
   P2MP.

Koike, et al.          Expires March 20, 2014                 [Page 3]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   - Traffic-engineered point-to-multipoint (P2MP) transport paths.(item
   6).
   - Unidirectional point-to-multipoint(P2MP) transport paths (item 8)
   - Being capable of using P2MP server (sub)layer capabilities when
   supporting P2MP MPLS-TP transport paths(item 40)
   - The MPLS-TP control plane MUST support establishing all the
   connectivity patterns defined for the MPLS-TP data plane (i.e.
   unidirectional P2MP) including the configuration of protection
   functions and any associated maintenance functions.(item 50)
   - Unidirectional 1+1 protection for P2MP connectivity (item 65 C)
   - Unidirectional 1:n protection for P2MP connectivity(item 67 B)
   - MPLS-TP recovery in a ring MUST protect unidirectional P2MP
   transport paths.(item 95)

   RFC5860 [2] defines MPLS-TP OAM requirements including those for
   unidirectional P2MP transport paths. With a unidirectional P2MP
   transport path, two cases are assumed as per Section 3.3 of
   RFC6371[3]. One is when no return path exists or not used and the
   other is when an "out-of-band" return path exists and used.

   In I-D[4], only a summary of various items specific to MPLS-TP P2MP
   framework. For example, according to the editor's note, this section
   will contain a summary of P2MP OAM, as described in RFC6371 [3],
   which defines the overall OAM architecture for MPLS-TP.

   Therefore, this draft intends to specify details of a P2MP framework
   that complements P2MP requirements and the framework of existing RFCs,
   particularly in terms of OAM, management, and recovery.

   Note: MPLS-TP functions that are applicable specifically to P2MP
   transport paths are outside the scope of RFC5921.

2. Conventions used in this document

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

  2.1. Terminology

   EMS  Element management system

   LSP  Label Switched Path

Koike, et al.          Expires March 20, 2014                 [Page 4]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   NE   Network Element

   NMS  Network Management System

  2.2. Definitions

   None

3. P2MP OAM and management

  3.1. General aspects of architecture

3.1.1. Return path

   The support of P2MP OAM on the data path should be independent of the
   availability of a return path or the mechanism that supports the
   return path. Basically, only unidirectional P2MP is supported in
   MPLS-TP. This means that an "in-band" return path is out of the scope
   of MPLS-TP requirements. In this section, two cases, with out-band
   return path and without return path, are considered basic and the
   requirements that should be met when return paths exist should be
   independently specified in other document, if needed.

   P2MP considerations are described in Section 3.7 of RFC6371. The RFC
   has already described some requirements with out-band return path(s).
   On the other hand, even if there is no return path, most OAM
   requirements in RFC5860 can be met by supporting the management
   interface through which EMS/NMS can retrieve the received OAM packets.

   The "return path" may be considered to be directed to the entity that
   originally requested the measurements because this may not be the
   head end of the P2MP connection. Therefore, the following return path
   should be distinctly differentiated.

      RP-N: A return path to the EMS/NMS through the management
      interface (RP-N) (this case is referred to as that in which no
      return path exists)

      RP-HE: A return path to a head end (root) of a P2MP path using any
      kind of out-of-band path (this case is referred to as that in
      which an out-of-band return path exists)

Koike, et al.          Expires March 20, 2014                 [Page 5]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   The interpretation of return path usually corresponds to RP-HE. These
   two kinds of return paths may be applied at the same time, depending
   on the situations.

3.1.2. M-leaves management scenario in P2MP path

   Generally, a function to monitor only the subset leaves of a P2MP
   transport path is required to appropriately monitor the status of
   P2MP transport paths. The supplemental requirements are as follows.

   1) M-leaves management, which enables NMS to perform OAM functions
        at a set of leaves on a P2MP transport path, must be supported.

   2) M-leaves must be selectable by the operator or administrator
        using NMS.

   3)  M-leaves management should be independently enabled/disabled in
        each OAM function.

   4)  In M-leave monitoring, one scenario should be selected to avoid
        future interoperability problems between related entities (NE,
        EMS, and NMS).

   There are four scenarios considered in MPLS-TP networks that consist
   of NEs, EMS, and NMS.

   In scenario 1, OAM protocol extension is necessary. OAM packets sent
   from the source MEP must include a subset of leaf-MEPs. A sink MEP
   determines if it should be notified of the management process within
   an NE based on the leaf-IDs included in the OAM packet. However, this
   is not supported in RFC6371.

   In scenario 2, OAM packets that are supported in RFC6371 and are
   targeted at all leaves can be utilized. As a result, no extension is
   necessary in the P2MP OAM protocol. On the other hand, a subset of M-
   leave/sink MEPs must be configured at an EMS from an NMS. In addition,
   a pre-configuration of a subset of M-leave/sink MEPs is needed at
   related NEs from the EMS. Only the notification-enabled M-
   leaves/nodes notify the EMS of its monitoring results.

   In scenario 3, OAM packets that are supported in RFC6371 and are
   targeted at all leaves can also be utilized. There is no P2MP OAM
   protocol extension. On the other hand, NMS configuration on M-
   leaves/sink MEPs is needed. In addition, a subset of M-leave/sink
   MEPs must be configured at the EMS from the NMS. However, no pre-
   configuration of a subset of M-leaves/NEs is needed.

Koike, et al.          Expires March 20, 2014                 [Page 6]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   In scenario 4, OAM packets that are supported in RFC6371 and are
   targeted at all leaves can also be utilized. There is no P2MP OAM
   protocol extension. Only NMS configuration on M-leaves/sink MEPs is
   needed. A configuration of a subset of M-leave/sink MEPs at the EMS
   from the NMS is not necessary. No pre-configuration of a subset of M-
   leaves/NEs is needed.

   Considering some negative impacts such as the efficient use of a data
   communication network (DCN), insufficient manageability of network
   element (NE), traffic congestion at EMS/NMS, and heavy load for OAM
   packet processes at EMS/NMS,  scenario 2 is required in MPLS-TP p2mp
   network.

3.1.3. Refinement of existing requirements on P2MP transport path

   MPLS-TP RFCs are sufficiently mature in terms of the requirements and
   framework of MPLS-TP P2P. On the other hand, in terms of MPLS-TP P2MP,
   some parts of MPLS-TP RFCs and Recommendations could be refined and
   clarified.

   (R1) CV requirement of RFC5860

   CV is ambiguously defined in RFC5860 "MPLS-TP OAM requirement".
   According to this definition of RFC5860, it seems to be source-MEP
   oriented and not correct in P2MP.

   Current text: The MPLS-TP OAM toolset MUST provide a function to
   enable 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.

   In unidirectional P2MP, the source MEP cannot determine whether or
   not it is connected to specific End Point(s). Therefore, in P2MP, the
   definition of connectivity verification should be corrected in P2MP
   framework draft and OAM Recommendation as follows.

   Proposed text: The MPLS-TP OAM toolset MUST provide a function to
   enable a sink End Point to determine whether or not it is connected
   to a specific source End Point by means of the expected PW or LSP.

   (R2) CC Requirement of RFC6371

   According to RFC6371, it is assumed that CC means that CC OAM packet
   does not include either a source MEP or destination MEP. Only
   unidirectional P2MP is supported in MPLS-TP, so the continuity of the
   CC OAM packets are received by sink MEPs, and a sink MEP should
   notify the equipment fault management process of the detected defect.
   However, the following current text doesn't correctly describe the

Koike, et al.          Expires March 20, 2014                 [Page 7]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   unidirectional feature that is specific to P2MP transport path.
   Therefore, the requirement should be modified.

   Current text in RFC: Proactive Continuity Check functions, as
   required in Section 2.2.2 of RFC 5860 [11], are used to detect a loss
   of continuity (LOC) defect between two MEPs in an MEG. Proactive
   Connectivity Verification functions, as required in Section 2.2.3 of
   RFC 5860 [11], are used to detect an unexpected connectivity defect
   between two MEGs (e.g., mismerging or misconnection), as well as
   unexpected connectivity within the MEG with an unexpected MEP.

   Proposed text: Proactive Continuity Check functions, as required in
   Section 2.2.2 of RFC5860, are used to detect a loss of continuity
   (LOC) defect from the source MEP to sink MEP(s). Proactive
   Connectivity Verification functions, as required in Section 2.2.3 of
   RFC5860, are used to detect an unexpected connectivity defect from
   the source MEP to sink MEP(s) (e.g., mismerging or misconnection), as
   well as unexpected connectivity within MEG with an unexpected source
   MEP.

   (R3) Optional requirements on CC-V OAM packets

   In a P2MP transport path, it is highly desirable that in order to
   save OAM bandwidth consumption, CV, when used, be linked with CC into
   CC-V OAM packets.

3.1.4. Addition and removal of branch tree in P2MP transport path

   When additional branches, in other words, additional destination NEs
   (leaves) need to be added to an existing transport path after a
   connection service is provided via the P2MP path, an operator must be
   capable of adding a new branch tree to the P2MP transport path
   flexibly from any point on the path without service interruption. The
   reason is that merging and crossover of the P2MP LSP branch tree must
   be rejected because it is not efficient in terms of network resources.
   As a result, the following requirement must be supported in the MPLS-
   TP P2MP transport path.

  3.2. General aspects of P2MP OAM

   P2MP transport paths are unidirectional; therefore, there is
   generally no in-band return path as in the MPLS-TP transport path per
   se. However, there are basically two approaches for handling OAM
   requirements in P2MP MPLS-TP.

   The first one is used to report the results of the
   monitoring/measurement of OAM packets from the OAM target node to the

Koike, et al.          Expires March 20, 2014                 [Page 8]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   EMS/NMS when the NMS usually instantiates OAM functions and requires
   the results of OAM monitoring functions. This approach is called RP-N.
   The second approach is the return path to a root (source MEP) of a
   P2MP path using different methods such as a unidirectional p2p
   transport paths, and other technology-layers, such as IP, Ethernet,
   and OTN, when an NE within which a root MEP resides instantiates OAM
   functions or receive results of OAM monitoring functions. This
   approach is called as RP-HE. The following requirements are supported
   in terms of network elements when considering RP-N.

   1. OAM functions of a MEG of a P2MP transport path should be
      configurable using the EMS/NMS.

   2. Source nodes at which the source MEP reside and OAM packets are
      generated should receive OAM related information such as
      enabling/disabling OAM functions and setting/changing OAM
      attributes from the EMS/NMS on a P2MP transport path.

   3. Sink nodes at which targeting MIPs or MEPs reside and OAM packets
      are parsed should report OAM related information such as OAM
      monitoring results and consequent OAM actions to the EMS/NMS.

   4. Each OAM function of a P2MP transport path should be able to be
      independently configured using the EMS/NMS based on the
      classification of OAM functional requirements in RFC5860.

   5. An on-demand OAM function must be able to perform an OAM function
      for only a specific target MIP or MEP as well as all MEPs in a
      P2MP transport path, as specified in Section 3.7 of RFC6371[3].

   6. To manage M leaves(i.e., subset of all leaves) in an on-demand OAM
      function from the EMS/NMS, a unified mechanism must be provided.

      Note: Currently, sending an OAM packet that is targeted at a
      subset of M leaves by using an aggregating mechanism such as an
      OAM packet including several MIP or MEP identifiers is out of the
      scope of RFC6371[3] as described in Section 3.7 of that document.

   7. Mismatches of configuration information between a root MEP and any
      leaf-MEP, at which proactive or on-demand monitoring is enabled,
      should be detected as a configuration mismatch alarm and be
      reported to the EMS/NMS by parsing received OAM packets,
      particularly when a static setting is applied.

   Generally when each OAM function is enabled, as described in Section
   5.1 of RFC6371[3], the source MEP function should be enabled prior to
   the corresponding sink MEPs' function.

Koike, et al.          Expires March 20, 2014                 [Page 9]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   Regarding configuration considerations, the following are additional
   requirements for unidirectional P2MP transport path, particularly
   when RP-HE does not exist.

   8. The configuration of each OAM function between the source MEP and
      sink MEP(s) in an MEG of a transport path should be able to be
      synchronized using the NMS, when a new P2MP transport path is set.

   9. OAM functions of a newly added/deleted branch transport path from
      any point of an existing transport path must be able to be
      configured and enabled/disabled on a newly integrated/combined
      P2MP transport path without affecting client traffic to existing
      end points of the P2MP transport path other than the added/removed
      branch transport path.

   10.The configuration of newly added/removed specific sink MEP(s)to
      the existing source MEP in the MEG in proactive monitoring should
      be able to be synchronized with that of the source MEP by using
      the NMS.

   11.The EMS/NMS should provide a tool for manually configuring
      consistent values of each piece of configuration information to a
      root MEP and all the related leaf MEPs in a MEG of a P2MP
      transport path for both pro-active and on-demand OAM functions.

   12.Mismatches of configuration information between a leaf MEP and any
      other leaf MEP(s) or a root MEP and leaf MEP(s), at which
      proactive monitoring will be enabled, should be able to be
      detected through the configuration management process of the
      EMS/NMS as a configuration mismatch alarm or notification without
      receiving OAM packets from a source MEP(before OAM functions are
      enabled).

      Note: This requirement is not necessary if the EMS/NMS provides a
      tool to manually configure a consistent value of each piece of
      configuration information to a root MEP.

   13.The enabling or disabling of proactive OAM functions and
      configuration mismatch alarms of the OAM functions must be
      independently configurable at each leaf-MEP as well as on all the
      leaf MEPs on a P2MP transport path, considering maintenances or a
      case in which one or more leaf MEPs is newly added or removed
      later.

   14.Mismatches of configuration information between a leaf MEP and any
      other leaf MEP(s) or a root MEP and leaf MEP(s), at which on-

Koike, et al.          Expires March 20, 2014                [Page 10]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

      demand OAM monitoring is enabled, must be detected as a
      configuration management process before conducting OAM functions.

  3.3. OAM functions for proactive monitoring

   The proactive OAM functions are used to detect a fault/defect or to
   automatically reports a change in the status of a transport path.

3.3.1. Continuity Check and Connectivity Verification(CC-V)

   The continuity Check function enables one or more leaf MEPs on a
   unidirectional P2MP transport path to monitor the continuity of OAM
   packets from root MEP and detect one or more loss of continuity(LOC)
   defects between the root MEP and leaf MEPs.

   The connectivity verification function enables one or more leaf MEPs
   on a P2MP transport path to monitor the connectivity of OAM packets
   from a specific root MEP and detect an unexpected connectivity defect
   between two MEGs(two P2MP transport paths)

   As described in Sections 2.2.2 and 2.2.3 of RFC5860[2], CC-V MUST be
   supported even when RP-HE does not exist.

   As described in RFC6371[3], CC-V OAM packets are used for a P2MP
   transport path. Defect detection mechanisms in P2MP transport paths
   are the same as those of the P2MP transport path specified in section
   5.1.1 of RFC6371 [3]. That is, loss of continuity(LoC) defect, mis-
   connectivity defect, period mis-configuration defect and unexpected
   encapsulation defect. Entry and exit criteria are also the same as
   those of the P2MP transport paths in RFC6371 [3]. However, in a P2MP
   transport path, all the leaf MEPs that detect a defect must be
   indentified and differentiated from a normal leaf MEP(s), which does
   not detect a defect.

   Configuration is specified in Section 5.1.3 of RFC6371[3]. The
   following configuration information must be configured: MEG-ID, MEP-
   ID, list of the other MEPs in the MEG that are different between the
   root MEP and leaf MEP, PHB for E-LSP and transmission rate.

   Consequent actions of a unidirectional P2MP transport path are also
   covered in Section 5.1.2 of RFC6371 [3]. Operators should be able to
   enable/disable each consequent action.

   All MEPs inside a MEG need to be configured and retain the
   information when a proactive OAM function is enabled, as described in

Koike, et al.          Expires March 20, 2014                [Page 11]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   Section 5.1.3 of RFC6371[3]. If there is no RP-HE, it is premised
   that the EMS/NMS exists. Therefore, the above parameters are
   statically configured.

3.3.2. Remote Defect Indication

   This OAM function is not available on a P2MP transport path when
   return paths do not exist. This OAM function can be implemented only
   in RP-HE. However, the return path is out of the scope of MPLS-TP
   requirements.

3.3.3. Alarm Reporting

  FFS

3.3.4. Lock Reporting

   For further study(FFS)

3.3.5. Packet Loss Measurement

   FFS

3.3.6. Packet Delay Measurement

   FFS

3.3.7. Client Failure Indication

   FFS

  3.4. OAM functions for on-demand monitoring

3.4.1. Connectivity verification

   The connectivity verification function enables one or more leaf MEPs
   on a P2MP transport path to monitor the connectivity of OAM packets
   from a specific root MEP and detect an unexpected connectivity defect
   between two MEGs (two P2MP transport paths)

   1. Connectivity verification functions MUST be supported when return
      paths in a unidirectional P2MP transport path do not exist.

Koike, et al.          Expires March 20, 2014                [Page 12]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   As described in RFC6371 [3], CC-V OAM packets are used for a P2MP
   transport path. Defect detection mechanisms in P2MP transport paths
   are the same as those of the P2MP transport path specified in section
   5.1 of RFC6371. That is, loss of continuity defect, mis-connectivity
   defect, period mis-configuration defect and unexpected encapsulation
   defect. Entry and exit criteria are also the same as those of the
   P2MP transport path in RFC6371 [3]. Moreover, consequent actions of a
   unidirectional P2MP transport path are also covered in Section 5.1.2
   of the RFC [3]

   Regarding configuration consideration, the following additional
   requirements on a unidirectional P2MP transport path when a return
   path does not exist.

3.4.2. Packet loss measurement

   FFS

3.4.3. Diagnostic tests

      Diagnostic test functions MUST be supported when a return path in
      a unidirectional P2MP transport path doesn't exist.

   Other requirements are ffs.

3.4.4. Route Tracing

      Route tracing function MUST be supported when a return path in a
      unidirectional P2MP transport path doesn't exist.

   Other requirements are ffs.

3.4.5. Packet delay measurement

   FFS

  3.5. OAM functions for administration control

3.5.1. Lock Instruct

   FFS.

Koike, et al.          Expires March 20, 2014                [Page 13]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

4. Layer Models

   Generally, MPLS-TP technology consists of two technical basis: one is
   LSP and the other is Pseudowire (PW). In PW, two types of multi-segment
   PW are supported: one is single-segment PW(SS-PW) and multi-segment
   PW(MS-SW). Considering the combination of those technologies, there
   are a few types of combinations considered in layering models of
   MPLS-TP. Fig.1 shows those examples.

                  ------------     ------------     ------------
   Channel layer | P2P SS-PW  |   |  P2MP MS-PW|   | P2MP MS-PW |
                  ------------     ------------     ------------
   Path layer    | P2MP LSP   |   |  P2P LSP   |   | P2MP LSP   |
                  ------------     ------------     ------------
   Server layer  | P2P any    |   |  P2P any   |   |  P2P any   |
                  ------------     ------------     ------------
                    Model 1          Moldel 2         Model 3

             Figure 1 : Examples of Layer models in P2MP MPLS-T

In principal, server layer is provided by any technologies such as
Etherent, OTN and MPLS-TP in P2P link. On the other hand, channel layer
and path layer are provided by PW and LSP and both technologies support
P2MP as well as P2P in current MPLS technology. From the perspective,
Three possible models are described in Fig.1.

There are still some discussion on which model should be adopted in
MPLS-TP. The key issue is on some ambiguity of the boundary of PW
function and LSP function. This OAM framework draft firstly focuses ons
Model 1, in which P2P SS-PW is applied in a channel layer and P2MP LSP
is applied in a path layer. Model 2 and Model 3 are for further study.
Regarding P2MP PW, as shown in [4], P2MP PW survivability has not been
discussed yet. P2MP PW requirements are being developed in [5].

Koike, et al.          Expires March 20, 2014                [Page 14]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

5. Applicable Scenarios

 P2MP MPLS-TP LSP could be applied not only to point to multi-point
topology networks, but also to p2mp portions which constructs multi-
point to multi-point services. Those requirements are being developed in
[6]. OAM functions described in this document can be utilized for
meeting those requirements.

6. Security Considerations

   This document does not raise any particular security considerations.

7. IANA Considerations

   There are no IANA actions required by this draft.

8. References

  8.1. Normative References

   [1]  Niven-Jenkins, B., et all, "Requirements of an MPLS Transport
         Profile", RFC5654, September 2009

   [2]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", RFC5860, May 2010

   [3]  Busi, I., Dave, A. , "Operations, Administration and
         Maintenance Framework for MPLS-based Transport Networks ",
         RFC6371, September 2011

   [4]  Frost, Dan.,et all, "A Framework for Point-to-Multipoint MPLS
         in Transport Networks", draft-mpls-tp-p2mp-framework-04,
         October 2013

  8.2. Informative References

   [5]  Bocci, M., Heron, G., and Y. Kamite, "Requirements and
   Framework for Point-to-Multipoint Pseudowires over MPLS PSNs", draft-
   ietf-pwe3-p2mp-pw-requirements-05 (work in progress), September 2011.

   [6]  Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., and L.
   Jin, "Framework and Requirements for Virtual Private Multicast

Koike, et al.          Expires March 20, 2014                [Page 15]
Internet-Draft       MPLS-TP p2mp OAM framework           October 2013

   Service (VPMS)", draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in
   progress), October 2012

9. Acknowledgments

   The author would like to thank all members (including MPLS-TP
   steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
   in ITU-T) involved in the definition and specification of MPLS
   Transport Profile.

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

Authors' Addresses

   Takafumi Hamano
   NTT
   hamano.takafumi@lab.ntt.co.jp

   Masatoshi Namiki
   NTT
   namiki.masatoshi@lab.ntt.co.jp

   Yoshinori Koike
   NTT
   Email: koike.yoshinori@lab.ntt.co.jp

Koike, et al.          Expires March 20, 2014                [Page 16]