Network Working Group                                    A. D'Alessandro
Internet-Draft                                            Telecom Italia
Intended status: Standards Track Informational                              L. Andersson
Expires: June 20, December 2, 2016                            Huawei Technologies
                                                                 M. Paul
                                                        Deutsche Telekom
                                                                 S. Ueno
                                                      NTT Communications
                                                                 K. Arai
                                                                Y. Koike
                                                                     NTT
                                                       December 18, 2015

                    Enhanced
                                                            May 31, 2016

                    Hitless path segment monitoring
             draft-ietf-mpls-tp-temporal-hitless-psm-09.txt
             draft-ietf-mpls-tp-temporal-hitless-psm-10.txt

Abstract

   The MPLS transport profile (MPLS-TP) has been standardized to enable
   carrier-grade packet transport and to complement converged packet
   network deployments.  The most attractive features of MPLS-TP are the
   OAM functions.  These functions enable maintenance tools that may be
   exploited by network operators and service providers for fault
   location, survivability, performance monitoring, in-service and out-
   of-service measurements.

   One of the most important mechanisms that is common OAM capabilities for transport network
   operation is fault localisation.  A  An in-service, on-demand segment
   monitoring function of a transport path is effective in terms of extension of
   the maintenance work and indispensable,
   particularly when the OAM service monitoring function is activated only
   between end points.  However, the current segment monitoring approach
   defined for MPLS-TP of segment monitoring MPLS RFC 6371 [RFC6371] has some drawbacks.  This document elaborates on
   provides an analysis of the problem statement existing MPLS-TP OAM mechanisms for the
   Sub-path Maintenance Elements (SPMEs) which provide monitoring of a
   path segment of a set of transport paths (LSPs or MS-PWs).  Based on the
   identified problems, this document monitoring and provides considerations for requirements to guide the
   specification
   development of new requirements OAM tools to consider support a new improved
   mechanism for hitless transport path segment monitoring to be named
   Enhanced Hitless Path Segment
   Monitoring (EPSM). (HPSM).

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 June 20, December 2, 2016.

Copyright Notice

   Copyright (c) 2015 2016 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
   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   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4   3
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Network objectives for segment monitoring  Problem Statement . . . . . . . . . .   4
   4.  Problem Statement . . . . . . . . . . . .   4
   4.  Requirements for hitless segment monitoring . . . . . . . . .   7
     4.1.  Backward compatibility  .   5
   5.  OAM functions supported in segment monitoring . . . . . . . .   8
   6.  Requirements for enhanced segment monitoring . . . . . . . .   9
     6.1.   7
     4.2.  Non-intrusive segment monitoring  . . . . . . . . . . . .   9
     6.2.   8
     4.3.  Multiple segments monitoring  . . . . . . . . . . . . . .   8
     4.4.  Single and multiple level monitoring  . . . . . . . . . .   9
     6.3.  EPSM   8
     4.5.  HPSM and end-to-end proactive monitoring independence . .  10
     6.4.   9
     4.6.  Arbitrary segment monitoring  . . . . . . . . . . . . . .  11
     6.5.  10
     4.7.  Fault while EPSM HPSM is operational . . . . . . . . . . . . .  11
     4.8.  HPSM Manageability  . . . . . . . . . . . . . . . . . . .  12
     6.6.  EPSM maintenance points
     4.9.  Supported OAM functions . . . . . . . . . . . . . . . . .  13
   7.
   5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgements
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   11. References
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   10. References  . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . .  15

   Authors' Addresses .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . .  15 . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   A packet transport network enables carriers and service providers to
   use network resources efficiently.  It reduces operational complexity
   and provides carrier-grade network operation.  Appropriate
   maintenance functions that support fault location, survivability,
   pro-active performance monitoring, pre-service and in-service
   measurements, are essential to ensure the quality of service and the
   reliability of a network.  They are essential in transport networks
   and have evolved along with PDH, ATM, SDH and OTN.

   Similar to legacy technologies, MPLS-TP also does not scale when an
   arbitrary number of OAM functions is enabled.

   According to the MPLS-TP OAM requirements RFC 5860 [RFC5860],
   mechanisms MUST be available for alerting a service provider providers of a
   fault faults
   or defect defects that affects their services.  In addition, to ensure that
   faults or service degradation can be localized, operators need a
   function to diagnose the detected problem.  Using end-to-end
   monitoring for this purpose is insufficient.  In fact by using end-
   to-end OAM monitoring, insufficient in that an operator will
   not be able to localize a fault or service degradation accurately.

   Thus, a dedicated segment monitoring function that can focus on a specific
   segment of a transport path and can provide a detailed analysis is
   indispensable to promptly and accurately localize the fault.  For
   MPLS-TP, a path segment monitoring function has been defined to
   perform this task.  However, as noted in the MPLS-TP OAM Framework
   RFC 6371 [RFC6371], the current method for segment monitoring of a
   transport path has implications that hinder the usage in an operator
   network.

   This document elaborates document, after elaborating on the problem statement for the
   path segment monitoring function and proposes to consider a new improved
   method for segment monitoring, following up the description in RFC
   6371 [RFC6371].  This document also as it is currently defined, provides additional detailed
   requirements for a new temporary and hitless an on-demand segment monitoring function which is not covered in RFC 6371 [RFC6371]. without
   traffic distruption.

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

2.1.  Terminology

      ATM - Asynchronous Transfer Mode

      EPSM

      HPSM - Enhanced Hitless Path Segment Monitoring

      LSP - Label Switched Path

      LSR - Label Switching Router

      ME - Maintenance Entity

      MEG - Maintenance Entity Group

      MEP - Maintenance Entity Group End Point

      MIP - Maintenance Entity Group Intermediate Point

      OTN - Optical Transport Network

      PDH - Plesiochronous Digital Hierarchy

      PST - Path Segment Tunnel

      TCM - Tandem connection monitoring

      SDH - Synchronous Digital Hierarchy

      SPME - Sub-path Maintenance Element

2.2.  Definitions

   None.

3.  Network objectives for segment monitoring

   There are two network objectives for MPLS-TP segment monitoring
   described in section 3.8 of RFC 6371 [RFC6371]:

   1.  The monitoring and maintenance of current transport paths has to
       be conducted in-service without traffic disruption.

   2.  Segment monitoring must not modify the forwarding of the segment
       portion of the transport path.

4.  Problem Statement

   The

   To monitor (and to protect and/or manage) MPLS-TP network segments a
   Sub-Path Maintenance Element (SPME) function is has been defined in RFC
   5921 [RFC5921].  It is used to monitor, protect, and/or manage
   segments of transport paths, such as LSPs in MPLS-TP networks.  The SPME is defined between the edges of the segment
   of a transport path that needs to be monitored, protected, or
   managed.  This  SPME is created by stacking the shim header (MPLS header)
   according to RFC 3031 [RFC3031] and it is defined as the segment
   where the header is stacked.  OAM messages can be initiated at the
   edge of the SPME and sent to the peer edge of the SPME or to a MIP
   along the SPME by setting the TTL value of the label stack entry
   (LSE) and interface identifier value at the corresponding
   hierarchical LSP level in case of a per-node model.

   This method has the following drawbacks that impact the operation
   costs:

      (P-1) It lowers the bandwidth efficiency.

      (P-2) It increases

   MPLS-TP segment monitoring must satisfy two network management complexity, because a new
      sublayer and new MEPs and MIPs have objectives
   according to section 3.8 of RFC 6371 [RFC6371]:

      (N1) The monitoring and maintenance of current transport paths has
      to be conducted in-service without traffic disruption.

      (N2) Segment monitoring must not modify the forwarding of the
      segment portion of the transport path.

      The SPME function that has been defined in RFC 5921 [RFC5921] has
      the following drawbacks:

      (P1) It increases network management complexity, because a new
      sublayer and new MEPs and MIPs have to be configured for the SPME.

   Problem (P-1) is caused by

      (P2) Original conditions of the shim headers stacking that increases path are changed.

      (P3) The client traffic over a transport path is disrupted if the overhead.
      SPME is configured on-demand.

   Problem (P-2) (P1) is related to an identifier management issue.  In the
   case of label stacking the identification management of each sub-layer is additional sub-
   layer required for segment monitoring in a MPLS-TP network.  When an
   SPME is applied for to administer on-demand OAM functions in MPLS-TP networks in a similar
   manner as Tandem Connection Monitoring (TCM) in the Optical Transport
   Networks (OTN) and Ethernet transport
   networks, a rule for operationally differentiating those SPME/TCMs SPME will be required;
   required at least within an administrative domain.  This forces
   operators to
   create implement at least an additional permanent layer identification policy into the
   management systems that will only be used for temporary on-demand path segment
   monitoring.  Additionally,
   from  From the perspective of operation, increasing the number
   of managed
   addresses layers and managed layers addresses/identifiers is not desirable
   in view of keeping the
   transport networks management systems as simple as possible.  Reducing the number of
   managed identifiers and managed sub-layers should be the fundamental
   objective in designing the architecture.

   The analogy for SPME in legacy transport networks is TCM, which is
   on-demand and does not affect the transport path.

   Also,

   Moreover, using the currently defined methods, temporary on-demand setting of
   SPMEs causes the following problems (P2) and (P3) due to additional label stacking:

      (P-3) The original condition of the transport path is affected by
      changing stacking.

   Problem (P2) arises from the length of fact that MPLS frames and changing the value of exposed label.

      (P-4) The client traffic over a transport path is disrupted when
      the SPME is configured on-demand.

   Problem (P-3) impacts network objective (2) in Section 3. label value and
   MPLS frames length changes.  The monitoring function should monitor
   the status without changing any conditions of the targeted, to be
   monitored, segment or transport path.  Changing the settings of the
   original shim header should not be allowed because this change
   corresponds to creating a new segment of the original transport path.  And this path
   that differs from the original
   data plane conditions. one.  When the conditions of the transport path
   change, the measured values or observed data will also change and
   this may make the monitoring meaningless because the result of the
   measurement would no longer reflect the performance of the connection
   where the original fault or degradation occurred.

   Figure 1 shows  As an example of example,
   setting up an on-demand SPME settings.  In will result in the figure, "X" is LSRs within the label value
   monitoring segment only looking at the added (stacked) labels and not
   at the labels of the original LSP.  This means that problems stemming
   from incorrect (or unexpected) treatment of labels of the original
   LSP by the nodes within the monitored segment cannot be identified
   when setting up SPME.  This might include hardware problems during
   label look-up, mis-configuration, etc.  Therefore operators have to
   pay extra attention to correctly setting and checking the label
   values of the original LSP in the configuration.  Of course, the
   reverse of this situation is also possible, e.g., an incorrect or
   unexpected treatment of SPME labels can result in false detection of
   a fault where no problem existed originally.

   Figure 1 shows an example of SPME settings.  In the figure, "X" is
   the label value of the original transport path expected at the tail-
   end tail-end of node
   D.  "210" and "220" are label values allocated for SPME.  The label
   values of the original path are modified as well as the values of the
   stacked labels.  As shown in Figure 1, SPME changes both the length
   of MPLS frames and the label value(s).  This means that it is no
   longer monitoring the original transport path but it is monitoring a different
   path.  In particular, performance monitoring measurements (e.g.
   Delay Measurement and Packet Loss Measurement) are sensitive to these
   changes.

      (Before SPME settings)
       ---     ---     ---     ---     ---
      |   |   |   |   |   |   |   |   |   |
      |   |   |   |   |   |   |   |   |   |
       ---     ---     ---     ---     ---
        A--100--B--110--C--120--D--130--E  <= transport path
       MEP                             MEP

      (After SPME settings)
       ---     ---     ---     ---     ---
      |   |   |   |   |   |   |   |   |   |
      |   |   |   |   |   |   |   |   |   |
       ---     ---     ---     ---     ---
        A--100--B-----------X---D--130--E  <= transport path
       MEP     \                  /    MEP
                --210--C--220--            <= SPME
               MEP'          MEP'

                      Figure 1: An Example of a SPME settings example

   Problem (P-4) (P3) can be avoided if the operator sets SPMEs in advance and
   maintains it them until the end of life of a transport path, which is
   neither temporary nor path.  But this
   does not support on-demand.  Furthermore SMPEs cannot be set
   arbitrarily because overlapping of path segments is limited to
   nesting relationships.  As a result, possible SPME configurations of
   segments of an original transport path are limited due to the
   characteristic of the SPME shown in Figure 1, even if SPMEs are pre-
   configured.

   Although the make-before-break procedure in the survivability
   document RFC 6372 [RFC6372] seemingly  supports the hitless configuration for monitoring
   according to the framework document RFC 5921 [RFC5921], without
   traffic distruption, the reality is that configuration of an SPME is
   impossible not possible
   without violating network objective (2) in Section 3. (N2).  These concerns are
   described in section 3.8 of RFC 6371 [RFC6371].

   Additionally, the make-before-break approach might not be usable in
   the static model without a control plane.  This is because the make-
   before-break is a restoration function based tipically relies on a
   control plane.
   Consequently the plane and requires additional functionalities for a
   management systems should system to properly support SPME creation and
   coordinated traffic
   switching from the original transport path to the SPME.

   Other potential risks are also envisaged.  Setting up a temporary
   SPME will result in the LSRs within the monitoring segment only
   looking at

   As an example, the added (stacked) labels old and not at the labels of the
   original LSP.  This means that problems stemming from incorrect (or
   unexpected) treatment of labels new transport resources (e.g.  LSP
   tunnels) might compete with each other for resources which they have
   in common.  Depending on availability of resources, this competition
   can cause admission control to prevent the original new LSP by the nodes
   within the monitored segment tunnel from being
   established as this bandwidth accounting deviates from traditional
   (non control plane) management system operation.  While SPMEs can not be identified when setting up
   SPME.  This might include hardware problems during label look-up,
   mis-configuration, etc.  Therefore operators have to pay extra
   attention to correctly setting and checking the label values of the
   original LSP
   applied in any network context (single domain, multi domain, single
   carrier, multi carrier, etc.), the configuration.  Of course, the reverse of this
   situation is also possible, e.g., an incorrect or unexpected
   treatment of SPME labels can result main applications are in false detection of a fault
   where no problem existed originally.

   The utilisation of SPMEs is basically limited to inter-carrier inter-
   carrier or inter-domain segment monitoring where they are typically
   pre- configured or pre-instantiated.  SPME instantiates a
   hierarchical
   transport path (introducing MPLS label stacking) through which OAM
   packets can be sent.  The SPME monitoring function is also mainly
   important for protecting bundles of transport paths and carriers'
   carrier solutions within one an administrative domain.

   The analogy for SPME in other transport technologies is Tandem
   Connection Monitoring (TCM), used in Optical Transport Networks (OTN)
   and Ethernet transport networks, which supports on-demand but does
   not affect the path.  TCM allows the insertion and removal of
   performance monitoring overhead within the frame at intermediate
   points in the network.  It is done such that their insertion and
   removal do not change the conditions of the path.  Though as the OAM
   overhead is part of the frame (designated overhead bytes), it is
   constrained to a pre-defined number of monitoring segments.

   To summarize: the problem statement is that the current sub-path
   maintenance based on a hierarchical LSP (SPME) is problematic for
   pre-configuration in terms of increasing the bandwidth by label
   stacking and increasing the number of managing managed
   objects by layer stacking and address management. identifiers/addresses.  An on-demand/temporary on-demand
   configuration of SPME is one of the possible approaches for
   minimizing the impact of these issues.  However, the current
   procedure is unfavorable unfavourable because the temporary on-demand configuration for
   monitoring can change changes the condition of the original monitored
   transport path.  To
   avoid or minimize the impact of the drawbacks discussed above, a more
   efficient approach is required for the operation of an MPLS-TP
   transport network.  A monitoring mechanism, named on-demand Enhanced Hitless Path
   Segment Monitoring (EPSM), (HPSM), supporting
   temporary and hitless on-demand path segment
   monitoring without traffic disruption is proposed.

5.  OAM functions supported in needed.

4.  Requirements for hitless segment monitoring

   OAM functions that may usefully be exploited across on-demand EPSM
   are basically

   In the on-demand performance following sections, mandatory (M) and optional (O)
   requirements for the hitless segment monitoring functions which function are defined in OAM framework document RFC 6371 [RFC6371].  Segment
   performance monitoring listed.

4.1.  Backward compatibility

   HPSM is used to verify an additional OAM tool that does not replace SPME.  As such:

      (M1) HSPM MUST be compatible with the performance and hence
   the status of transport path segments.  The "on-demand" attribute is
   generally temporary for maintenance operation.

   Packet Loss and Packet Delay measurement are OAM functions strongly
   required in hitless and temporary segment monitoring because these
   functions are normally only supported at the end points of a
   transport path.  If a defect occurs, it might be quite hard to locate
   the defect or degradation point without using the segment monitoring
   function.  If an operator cannot locate or narrow down the cause usage of
   the fault, it is quite difficult to take prompt actions to solve the
   problem.

   Other on-demand monitoring functions, (e.g.  Delay Variation
   measurement) are desirable but not as necessary as the functions
   mentioned above.

   Regarding out-of-service on-demand performance management functions
   (e.g.  Throughput measurement) there seems no need for EPSM.
   However, OAM functions specifically designed for segment monitoring
   should SPME

      (M2) HSPM SHOULD be developed to satisfy network objective (2) described in
   Section 3.

   Finally, applicable at the solution for EPSM has to cover SPME layer too

      (M3) HSPM MUST support both the per-node model and the per-interface model
      as specified in RFC 6371 [RFC6371].

6.  Requirements for enhanced segment monitoring

   In the following sections, mandatory (M) and optional (O)
   requirements for the enhanced segment monitoring function are listed.

6.1.

4.2.  Non-intrusive segment monitoring

   One of the major problems of legacy SPME highlighted in section 4 3 is
   that it may not monitor the original transport path and it could
   distrupt disrupt
   service traffic when set-up on demand.

      (M1) EPSM must not

      (M4) HPSM MUST NOT change the original condition conditions of transport
      path (e.g.  must not change the length of MPLS frames, the exposed
      label values, etc.)

      (M2) EPSM must be provisioned

      (M5) HPSM MUST support on-demand provisioning and without traffic
      disruption.

6.2.

4.3.  Multiple segments monitoring

   Along a transport path there may be the need to support
   simultaneously monitoring multiple segments

      (M6) HPSM MUST support configuration of multiple monitoring
      segments along a transport path.

      ---     ---     ---     ---     ---
     |   |   |   |   |   |   |   |   |   |
     | A |   | B |   | C |   | D |   | E |
      ---     ---     ---     ---     ---
   MEP *-------------------------------* MEP <= ME of a transport path
       *------* *----*  *--------------* <=three HPSM monit. instances

        Figure 2: Multi-level on-demand segment monitoring example

4.4.  Single and multiple level monitoring

   The new enhanced hitless segment monitoring function is supposed to will be applied mainly
   for on-demand diagnostic purposes.  We can
   differentiate this monitoring from  With the existing proactive segment
   monitoring by referring to is as on-demand multi-level monitoring.
   Currently current defined
   approach, the most serious problem is that there is no way to locate
   the degraded segment of a path without changing the conditions of the
   original path.  Therefore, as a first step, a single level, single layer
   segment monitoring, not affecting the monitored path, is required for
   a new on-demand and hitless segment monitoring function. function without traffic
   disruption.  A combination of multi-level and simultaneous segment segments
   monitoring is the most powerful tool for accurately diagnosing the
   performance of a transport path.  However, in the field, a single level
   level, multiple segments approach may will be enough.

      (M3) Single-level less complex for management
   and operations.

      (M7) HPSM MUST support single-level segment monitoring is required

      (O1) Multi-level HPSM MAY support multi-level segment monitoring is desirable monitoring.

   Figure 2 3 shows an example of multi-level on-demand segment
   monitoring.

      ---     ---     ---     ---     ---
     |   |   |   |   |   |   |   |   |   |
     | A |   | B |   | C |   | D |   | E |
      ---     ---     ---     ---     ---
      MEP                             MEP <= ME of a transport path
              *-----------------*         <=On-demand segm. mon. HPSM level 1
                *-------------*           <=On-demand segm. mon. HPSM level 2
                      *-*                 <=On-demand segm. mon. HPSM level 3

        Figure 2: Example of multi-level 3: Multi-level on-demand segment monitoring

6.3.  EPSM example

4.5.  HPSM and end-to-end proactive monitoring independence

   The

   There is a need for simultaneously using existing end-to-end
   proactive monitoring and the enhanced on-demand path segment monitoring is
   considered. monitoring.
   Normally, the on-demand path segment monitoring is configured on a
   segment of a maintenance entity of a transport path.  In such an
   environment, on-demand single-level monitoring should be performed
   without disrupting the pro-active monitoring of the targeted end-to-end end-to-
   end transport path to avoid affecting user traffic performance
   monitoring.

   Therefore:

      (M4) EPSM shall be configured without changing or interfering with

      (M8) HPSM MUST support the already in place end-to-end pro-active monitoring capability to be concurrently and
      independently operated of the
      transport path. OAM function operated on the end-to-
      end path

     ---     ---     ---     ---     ---
    |   |   |   |   |   |   |   |   |   |
    | A |   | B |   | C |   | D |   | E |
     ---     ---     ---     ---     ---
     MEP                             MEP <= ME of a transport path
       +-----------------------------+   <= Pro-active end-to-end mon.
             *------------------*        <= On-demand segment mon. HPSM

    Figure 3: 4: Independency between proactive end-to-end monitoring and
                       on-demand segment monitoring

6.4.

4.6.  Arbitrary segment monitoring

   The main objective for enhanced on-demand segment monitoring is to diagnose
   the fault locations.  A possible realistic diagnostic procedure is to
   fix one end point of a segment at the MEP of the transport path under
   observation and change progressively the length of the segments.
   This example is shown in Figure 4. 5.

       ---     ---     ---     ---     ---
      |   |   |   |   |   |   |   |   |   |
      | A |   | B |   | C |   | D |   | E |
       ---     ---     ---     ---     ---
       MEP                             MEP <= ME of a transport path
         +-----------------------------+   <= Pro-active end-to-end mon.
         *-----*                           <= 1st on-demand segment mon. HPSM
         *-------*                         <= 2nd on-demand segment mon.
         *------------*                    <= 3rd on-demand segment mon. HPSM
              |                                |
              |                                |
         *-----------------------*         <= 6th 4th on-demand segment mon. HPSM
         *-----------------------------*   <= 7th 5th on-demand segment mon. HPSM

    Figure 4: A procedure to localize 5: Localization of a defect by consecutive on-demand segment
                           monitoring procedure

   Another possible scenario is depicted in Figure 5. 6.  In this case, the
   operator wants to diagnose a transport path starting at a transit
   node, because the end nodes(A nodes (A and E) are located at customer sites
   and consist of cost effective small boxes supporting only a subset of
   OAM functions.  In this case, where the source entities of the
   diagnostic packets are limited to the position of MEPs, on-demand
   segment monitoring will be ineffective because not all the segments
   can be diagnosed (e.g. segment monitoring HPSM 3 in Figure 5 6 is not
   available and it is not possible to determine the fault location
   exactly).

   Therefore:

      (M5) it shall

      (M9) It SHALL be possible to provision EPSM HPSM on an arbitrary
      segment of a transport path and diagnostic packets should be
      inserted/terminated at any of intermediate maintenance points of
      the original ME.

              ---     ---     ---
      ---    |   |   |   |   |   |    ---
     | A |   | B |   | C |   | D |   | E |
      ---     ---     ---     ---     ---
      MEP                             MEP <= ME of a transport path
        +-----------------------------+   <= Pro-active end-to-end mon.
        *-----*                           <= On-demand segment mon. HPSM 1
              *-----------------------*   <= On-demand segment mon. HPSM 2
              *---------*                 <= On-demand segment mon. HPSM 3

            Figure 5: ESPM configured 6: HSPM configuration at arbitrary segments

6.5.

4.7.  Fault while EPSM HPSM is operational

   Node or link failures may occur while EPSM HPSM is active.  In this case,
   if no resiliency mechanism is set-up on the subtended transport path,
   there is no particular requirement for the EPSM HPSM function.  If the
   transport path is protected, the EPSM HPSM function should be terminated
   to avoid monitoring a new segment when a protection or restoration
   path is active.

   Therefore:

      (M6) the EPSM function should

      (M10) The HPSM functions SHOULD avoid monitoring an unintended
      segment when one or more failures occur

   The following examples are provided for clarification only and they
   are not intended to restrict any solution for meeting the
   requirements of EPSM. HPSM.

   Protection scenario A is shown in figure 6. 7.  In this scenario a
   working LSP and a protection LSP are set-up.  EPSM  HPSM is activated
   between nodes A and E.  When a fault occurs between nodes B and C,
   the operation of EPSM HPSM is not affected by the protection switch and
   continues on the active LSP path.  As a result requirement (M6) (M10) is
   satisfied.

      A - B - C - D - E - F
        \               /
          G - H - I - L

      Where:
      - end-to-end LSP: A-B-C-D-E-F
      - working LSP:    A-B-C-D-E-F
      - protection LSP: A-B-G-H-I-L-F A-G-H-I-L-F
      - EPSM:           A-E

                      Figure 6: 7: Protection scenario A

   Protection scenario B is shown in figure 7. 8.  The difference with
   scenario A is that only a portion of the transport path is protected.
   In this case, when a fault occurs between nodes B and C on the
   working sub-path B-C-D, traffic will be switched to protection sub-
   path B-G-H-D.  Assuming that OAM packet termination depends only on
   the TTL value of the MPLS label header, the target node of the EPSM HPSM
   changes from E to D due to the difference of hop counts between the
   working path route (A-B-C-D-E: 4 hops) and protection path route
   (A-B-G-H-D-E: 5 hops).  As a result requirement (M6) (M10) is not
   satisfied.

          A - B - C - D - E - F
                \     /
                 G - H

      - end-to-end LSP:      A-B-C-D-E-F
      - working sub-path:    B-C-D
      - protection sub-path: B-G-H-D
      - EPSM:                A-E

                      Figure 7: 8: Protection scenario B

6.6.  EPSM

4.8.  HPSM Manageability

   From managing perspective, increasing the number of managed layers
   and managed addresses/identifiers is not desirable in view of keeping
   the management systems as simple as possible.

      (M11)HPSM SHOULD NOT be based on additional transport layers (e.g.
      hierarchical LSPs)

      (M12) The same identifiers used for MIPs and/or MEPs SHOULD be
      applied to HPSM maintenance points when they coincide.  Anyway
      maintenance points for the HPSM do not necessarily have to
      coincide with MIPs and MEPs functional components as defined in
      the OAM framework document RFC 6371 [RFC6371].

4.9.  Supported OAM functions

   An intermediate maintenance point supporting the HPSM function has to
   be able to generate and inject OAM packets.  OAM functions that may
   be applicable for on-demand HPSM are basically the on-demand
   performance monitoring functions which are defined in the OAM
   framework document RFC 6371 [RFC6371].  The "on-demand" attribute is
   typically temporary for maintenance operation.

      (M13) HPSM MUST support Packet Loss and Packet Delay measurement.

   That because these functions are normally only supported at the end
   points

   An intermediate maintenance of a transport path.  If a defect occurs, it might be quite
   hard to locate the defect or degradation point supporting without using the EPSM function has
   segment monitoring function.  If an operator cannot locate or narrow
   down the cause of the fault, it is quite difficult to
   be able take prompt
   actions to generate and inject OAM packets.  However, maintenance
   points for solve the EPSM do problem.

   Other on-demand monitoring functions (e.g.  Delay Variation
   measurement) are desirable but not necessarily have to coincide with MIPs or
   MEPs defined in as necessary as the architecture.

   Therefore:

      (M7) The same identifiers functions
   mentioned above.

      (O2) HPSM MAY support Packet Delay variation, Throughput
      measurement and other performance monitoring and fault management
      functions.

   Support of out-of-service on-demand performance management functions
   (e.g.  Throughput measurement) is not required for MIPs and/or MEPs should be applied
      to EPSM maintenance points

7. HPSM.

5.  Summary

   An enhanced

   A new hitless path segment monitoring (EPSM) (HPSM) mechanism is required to
   provide temporary and hitless on-demand segment monitoring. monitoring without traffic disruption.  It
   shall meet the two network objectives described in section 3.8 of RFC
   6371 [RFC6371] and repeated summarized in Section 3 of this document.

   The enhancements mechanism should minimize the problems described in Section 4,
   i.e., (P-1), (P-2), (P-3) 3,
   i.e. (P1), (P2) and (P-4). (P3).

   The solution for the temporary and hitless on-demand segment monitoring has without traffic
   disruption needs to cover both the per-node model and the per-interface per-
   interface model specified in RFC 6371 [RFC6371].

   The temporary and hitless on-demand segment monitoring solutions shall without traffic disruption solution
   needs to support on-demand Packet Loss Measurement and Packet Delay
   Measurement functions and optionally other performance monitoring and
   fault management functions (e.g.  Throughput measurement, Packet
   Delay variation measurement, Diagnostic test, etc.).

8.

6.  Security Considerations

   The security considerations defined for MPLS Transport Profile
   Framework in RFC 6378 5921 [RFC5921] apply to this document as well.  As this is simply  The
   document provides the requirements for a re-use of RFC 6378, there are
   no new construct for
   performance monitoring that will make use of existing OAM tools that
   follow the security considerations.

9. considerations provided in OAM Requirements for
   MPLS-TP in RFC5860 [RFC5860].

7.  IANA Considerations

   There are no requests for IANA actions in this document.

   Note to the RFC Editor - this section can be removed before
   publication.

10.

8.  Contributors

   Manuel Paul

   Deutsche Telekom AG

   Email: manuel.paul@telekom.de

9.  Acknowledgements

   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.

   The authors would also like to thank Alexander Vainshtein, Dave
   Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi,
   Maarten Vissers, Jia He and Nurit Sprecher for their comments and
   enhancements to the text.

11.

10.  References

11.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <http://www.rfc-editor.org/info/rfc3031>.

   [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
              "Requirements for Operations, Administration, and
              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
              DOI 10.17487/RFC5860, May 2010,
              <http://www.rfc-editor.org/info/rfc5860>.

11.2.

10.2.  Informative References

   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
              L., and L. Berger, "A Framework for MPLS in Transport
              Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
              <http://www.rfc-editor.org/info/rfc5921>.

   [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
              Administration, and Maintenance Framework for MPLS-Based
              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
              September 2011, <http://www.rfc-editor.org/info/rfc6371>.

   [RFC6372]  Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
              Profile (MPLS-TP) Survivability Framework", RFC 6372,
              DOI 10.17487/RFC6372, September 2011,
              <http://www.rfc-editor.org/info/rfc6372>.

Authors' Addresses

   Alessandro D'Alessandro
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148
   Italy

   Email: alessandro.dalessandro@telecomitalia.it

   Loa Andersson
   Huawei Technologies

   Email: loa@mail01.huawei.com

   Manuel Paul
   Deutsche Telekom

   Email: Manuel.Paul@telekom.de
   Satoshi Ueno
   NTT Communications

   Email: satoshi.ueno@ntt.com

   Kaoru Arai
   NTT

   Email: arai.kaoru@lab.ntt.co.jp

   Yoshinori Koike
   NTT

   Email: y.koike@vcd.nttbiz.com