A framework for Point-to-Multipoint MPLS-TP OAM in case that return paths don't exist
draft-hmk-mpls-tp-p2mp-oam-framework-00

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

Expires: January 8, 2013                                  July 9, 2012

    A framework for Point-to-Multipoint MPLS-TP OAM in case that return
                             paths don't exist
                draft-hmk-mpls-tp-p2mp-oam-framework-00.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 January 8, 2013.

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

Koike, et al.          Expires January X, 2013                [Page 1]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   (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 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 provides texts proposal which should be discussed and
   included in draft-fbb-mpls-tp-p2mp-framework, particularly focusing
   on p2mp OAM framework in case that return paths don't exist. Other
   requirements of p2mp transport path such as protection will also be
   discussed.

   Note: This I-D was made based on the result of discussion in ITU-T
   SG15 which is described in a Liaison Statement: Request advance work
   on the p2mp framework in MPLS-TP
   (https://datatracker.ietf.org/liaison/1163/)

   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 ............................................ 4
   3. P2MP OAM .................................................... 4
      3.1. OAM functions for proactive monitoring ..................5
         3.1.1. Continuity Check and Connectivity Verification..... 5
         3.1.2. Remote Defect Indication........................... 6

Koike, et al.          Expires January 8, 2013                [Page 2]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

         3.1.3. Alarm Reporting.................................... 6
         3.1.4. Lock Reporting..................................... 7
         3.1.5. Packet Loss Measurement............................ 7
         3.1.6. Packet Delay Measurement........................... 7
         3.1.7. Client Failure Indication ..........................7
      3.2. OAM functions for on-demand monitoring ..................7
         3.2.1. Connectivity verification ..........................7
         3.2.2. Packet loss measurement............................ 8
         3.2.3. Diagnostic tests................................... 9
         3.2.4. Route Tracing...................................... 9
         3.2.5. Packet delay measurement........................... 9
      3.3. OAM functions for administration control................ 9
         3.3.1. Lock Instruct...................................... 9
   4. Security Considerations...................................... 9
   5. IANA Considerations ......................................... 9
   6. References .................................................. 9
      6.1. Normative References.................................... 9
      6.2. Informative References................................. 10
   7. Acknowledgments ............................................ 10

1. Introduction

   The demand for P2MP traffic is expected to increase due to the
   increase in new services such as IP-TV and video distribution
   services. Moreover considering the global trend to improve energy
   efficiency, a P2MP transport function in MPLS-TP could be one of the
   solutions to achieve this goal from the perspective of efficient use
   of network resources.

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

   - Traffic-engineered point-to-multipoint (P2MP) transport paths.(item
   6)
   - Unidirectional point-to-multipoint 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 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)

Koike, et al.          Expires January 8, 2013                [Page 3]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   RFC5860[2] defines MPLS-TP OAM requirements including those for
   unidirectional P2MP transport paths. In case of unidirectional P2MP
   transport path, two cased are assumed as per section 3.3 of
   RFC6371[3]. One is when an "out-of-band" return path exists and it is
   used and the other is when any return path does not exist or is not
   use. Missing OAM requirements which are necessary in P2MP transport
   networks are those in the latter case.

   In I-D[4], Operations, Administration and Maintenance (OAM) is
   planned to be specified in clause 4. According to the editor's note,
   this section will contain a summary of point-to-multipoint OAM as
   described in RFC6371[3] that defines the overall OAM architecture for
   MPLS-TP.

   However, considering the missing OAM requirements in case that a
   return paths don't exist, the most appropriate place where they could
   be added is I-D[4]. Therefore, this draft intends to provide texts
   which should be included in OAM section and network management
   section of the I-D[4].

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

   LSP  Label Switched Path

  2.2. Definitions

   None

3. P2MP OAM

   Note: It is proposed that this section be incorporated in section 4
   of I-D[4].

   Unidirectional P2MP is supported in MPLS-TP. This means that "in-
   band" return path is out of scope. In this section, only two cases,

Koike, et al.          Expires January 8, 2013                [Page 4]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   with out-band return path and without return path, are considered and
   requirements should be independently specified, if necessary.

   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, parts of OAM
   requirements in RFC5860 could be met by supporting management
   interface through which EMS/NMS can retrieve the received OAM packets.

   Note: In the following sections, basically additional requirements
   are described function-by-function, which haven't been covered or
   clarified in RFC5860[2] and RFC6371[3] have particularly focused on
   the case that return paths doen't exist.

  3.1. OAM functions for proactive monitoring

3.1.1. Continuity Check and Connectivity Verification

   Continuity Check function enable one or more leaf MEPs on
   unidirectional P2MP transport path to monitor the continuity of OAM
   packets from root MEP and detect one or more loss of continuity(LOC)
   defect between the root MEP and the leaf MEPs. Connectivity
   Verification function enables one or more leaf MEPs on 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)

   Continuity Check and Connectivity Verification MUST be supported in
   case that a return path in a unidirectional P2MP transport path
   doesn't exist. This requirement is already included in section 2.2.3
   of RFC5860[2].

   As described in RFC6371[3], CC-V OAM packets are used for P2MP
   transport path. Defect detection mechanisms in P2MP transport paths
   are the same as those of 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 criteria and exist criteria are also the same as those
   of P2MP transport path in RFC6371[3]. Moreover, consequent actions of
   unidirectional P2MP transport path are also covered in section 5.1.2
   of the RFC[3]

   Regarding configuration consideration, following additional
   requirements on unidirectional P2MP transport path in case that the
   return paths don't exist.

Koike, et al.          Expires January 8, 2013                [Page 5]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   1. EMS/NMS should provide a tool to manually configure consistent
      values on each piece of configuration information (MEG-ID, MEP-ID,
      list of the other MEPs in the MEG, PHB for E-LSPs, transmission
      rate) to a root-MEP and all the related leaf-MEPs in a MEG of a
      P2MP transport path.

   2. Mis-matches of configuration information (MEG-ID, MEP-ID, PHB for
      E-LSPs, transmission rate) between a root MEP and any leaf-MEP at
      which proactive monitoring is enabled, should be detected as a
      configuration mis-match alarm by parsing received CC-VOAM packets.

   3. Mis-matches of configuration information (MEG-ID, MEP-ID, list of
      the other MEPs in the MEG, PHB for E-LSPs, transmission rate)
      between a leaf MEP and any other leaf-MEP, at which proactive
      monitoring are enabled, may be detected through configuration
      management process of EMS/NMS as a configuration mis-match alarm
      without receiving OAM packets from a source MEP.

   4. Configuration information mis-match alarms described in 4 and 5
      may be supported in case that a proactive monitoring is not
      enabled in order to check those mis-matches before monitoring
      functions are enabled.

   5. Enabling or disabling configuration mis-matich alarms must be able
      to be configured at each leaf-MEP independently.

3.1.2. Remote Defect Indication

   This OAM function is not available on P2MP transport path in case
   that return paths don't exist, because this function is implemented
   only on the return path.

3.1.3. Alarm Reporting

   Alarm Reporting functions MUST be supported in case that a return
   path in a unidirectional P2MP transport paths don't exist. This is
   already included in section 2.2.8 of RFC5860[2].

   6. EMS/NMS should provide a tool to manually configure consistent
      values on "hold-off intervals prior to asserting an alarm to the
      management system" and AIS transmission period to all the leaf-
      MEPs in a MEG of a P2MP transport path.

   7. Mis-matches of configuration information (hold-off interval and
      AIS transmission period) between a root MEP and any leaf-MEP at
      which alarm reporting is enabled, should be detected as a
      configuration mis-match alarm by parsing received AIS OAM packets.

Koike, et al.          Expires January 8, 2013                [Page 6]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   8. Mis-matches of configuration information (hold-off interval and
      AIS transmission period) between a leaf MEP and any other leaf-MEP,
      at which alarm reporting is enabled, may be detected through
      configuration management process of EMS/NMS as a configuration
      mis-match alarm without receiving OAM packets from a source MEP.

   9. Configuration information mis-match alarms described in 4 and 5
      may be supported in case that a alarm reporting is not enabled in
      order to check those mis-matches before monitoring functions are
      enabled.

   10.Enabling or disabling configuration information mis-matich alarms
      must be able to be configured at each leaf-MEP independently.

3.1.4. Lock Reporting

   FFS

3.1.5. Packet Loss Measurement

   FFS

3.1.6. Packet Delay Measurement

   FFS

3.1.7. Client Failure Indication

   FFS

  3.2. OAM functions for on-demand monitoring

3.2.1. Connectivity verification

   Connectivity Verification function enables one or more leaf MEPs on
   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)

   11.Connectivity verification functions MUST be supported in case that
      return paths in a unidirectional P2MP transport path don't exist.

Koike, et al.          Expires January 8, 2013                [Page 7]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   As described in RFC6371[3], CC-V OAM packets are used for P2MP
   transport path. Defect detection mechanisms in P2MP transport paths
   are the same as those of 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 criteria and exist criteria are also the same as those
   of P2MP transport path in RFC6371[3]. Moreover, consequent actions of
   unidirectional P2MP transport path are also covered in section 5.1.2
   of the RFC[3]

   Regarding configuration consideration, following additional
   requirements on unidirectional P2MP transport path in case that
   return path doesn't exist.

   12.EMS/NMS should provide a tool to manually configure consistent
      values on each piece of configuration information (MEG-ID, MEP-ID,
      list of the other MEPs in the MEG, PHB for E-LSPs, transmission
      rate) to a root-MEP and all the related leaf-MEPs in a MEG of a
      P2MP transport path.

   13.Mis-matches of configuration information (MEG-ID, MEP-ID, PHB for
      E-LSPs, transmission rate) between a root MEP and any leaf-MEP at
      which proactive monitoring is enabled, should be detected as a
      configuration mis-match alarm by parsing received CC-VOAM packets.

   14.Mis-matches of configuration information (MEG-ID, MEP-ID, list of
      the other MEPs in the MEG, PHB for E-LSPs, transmission rate)
      between a leaf MEP and any other leaf-MEP, at which proactive
      monitoring are enabled, may be detected through configuration
      management process of EMS/NMS as a configuration mis-match alarm
      without receiving OAM packets from a source MEP.

   15.Configuration information mis-match alarms described in 4 and 5
      may be supported in case that a proactive monitoring is not
      enabled in order to check those mis-matches before monitoring
      functions are enabled.

   16.Enabling or disabling configuration mis-matich alarms must be able
      to be configured at each leaf-MEP independently.

3.2.2. Packet loss measurement

   FFS

Koike, et al.          Expires January 8, 2013                [Page 8]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

3.2.3. Diagnostic tests

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

   Other requirements are ffs.

3.2.4. Route Tracing

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

   Other requirements are ffs.

3.2.5. Packet delay measurement

   FFS

  3.3. OAM functions for administration control

3.3.1. Lock Instruct

   FFS.

4. Security Considerations

   This document does not by itself raise any particular security
   considerations.

5. IANA Considerations

   There are no IANA actions required by this draft.

6. References

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

Koike, et al.          Expires January 8, 2013                [Page 9]
Internet-Draft       MPLS-TP p2mp OAM framework              July 2012

   [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-fbb-mpls-tp-p2mp-framework-04,
         June 2012

  6.2. Informative References

   None

7. 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 January 8, 2013               [Page 10]