Network Working Group                                    A. D'Alessandro
Internet-Draft                                            Telecom Italia
Intended status: Standards Track                            L. Andersson
Expires: August 30, 2015 January 21, 2016                            Huawei Technologies
                                                                 M. Paul
                                                        Deutsche Telekom
                                                                 S. Ueno
                                                      NTT Communications
                                                                 K. Arai
                                                                Y. Koike
                                                                     NTT
                                                       February 26,
                                                           July 20, 2015

              Temporal and hitless

                    Enhanced path segment monitoring
             draft-ietf-mpls-tp-temporal-hitless-psm-06.txt
             draft-ietf-mpls-tp-temporal-hitless-psm-07.txt

Abstract

   The MPLS transport profile (MPLS-TP) is being has been standardized to enable
   carrier-grade packet transport and complement converged packet
   network deployments.  Among the most attractive features of MPLS-TP
   there are OAM functions, which enable network operators or service
   providers to provide various maintenance characteristics, such as
   fault location, survivability, performance monitoring, monitoring and
   preliminary or in-service in-service/
   out of service measurements.

   One of the most important mechanisms which is common for transport
   network operation is fault location.  A segment monitoring function
   of a transport path is effective in terms of extension of the
   maintenance work and indispensable particularly when the OAM function
   is effective only between end points.  However, the current approach
   defined for MPLS-TP for the segment monitoring (SPME) has some fatal
   drawbacks.  This document elaborates on the problem statement for the
   Sub-path Maintenance Elements (SPMEs) which provides monitoring of a
   portion of a set of transport paths (LSPs or MS-PWs).  Based on the
   problems, this document specifies new requirements to consider a new
   improved mechanism of hitless transport path segment monitoring. monitoring named
   Enhanced Path Segment Monitoring (EPSM).

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 August 30, 2015. January 21, 2016.

Copyright Notice

   Copyright (c) 2015 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.  Conventions used in this document . . . . . . . . . . . . . .   4   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Network objectives for segment monitoring . . . . . . . . . . . . . .   4
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5   4
   5.  OAM functions using supported in segment monitoring . . . . . . . . . . .   9   8
   6.  Further consideration of requirements  Requirements for enhanced
       segmentmonitoring segment monitoring  . . . . . . . .   8
     6.1.  Non intrusive segment monitoring  . . . . . . . . . . . .   9
     6.2.  Single and multiple levels monitoring . .  10
     6.1.  Necessity of on-demand single-level monitoring . . . . .  10
     6.2.  Necessity of on-demand monitoring independent from end-
           to-end . . .   9
     6.3.  EPSM and end-to-end proactive monitoring independence . .  10
     6.4.  Arbitrary segment monitoring  . . . . . . . . . . . . . .  10
     6.3.   Necessity of arbitrary segment monitoring
     6.5.  Fault while EPSM is in place  . . . . . . .  11
     6.4.  Fault during HPSM in case of protection . . . . . . .  12
     6.6.  EPSM maintenance points . .  13
     6.5.  Consideration of maintenance point for HPSM . . . . . . .  14 . . . . . . . .  13
   7.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  14  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15  14
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  15  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16  15

1.  Introduction

   A packet transport network will enable enables carriers or service providers to
   use network resources efficiently, reduce reduces operational complexity and provide
   provides carrier-grade network operation.  Appropriate maintenance
   functions, supporting fault location, survivability, performance
   monitoring and preliminary or in-service measurements, are essential
   to ensure quality and reliability of a network.  They are essential
   in transport networks and have evolved along with TDM, ATM, SDH and
   OTN.

   Unlike in SDH or OTN networks, where OAM is an inherent part of every
   frame and frames are

   As legacy technologies, also transmitted in idle mode, it is MPLS-TP does not per se
   possible to constantly monitor the status scale when an arbitrary
   number of individual connections
   in packet networks.  Packet-based OAM functions are flexible and
   selectively configurable according to operators' needs. enabled.

   According to the MPLS-TP OAM requirements RFC 5860 [RFC5860],
   mechanisms MUST be available for alerting a service provider of a
   fault or defect affecting the service(s) provided. services.  In addition, to ensure that
   faults or degradations can be localized, operators need a method to
   analyze or investigate the problem.  From the fault
   localization perspective, problem being end-to-end monitoring is
   insufficient.
   Using  In fact using end-to-end OAM monitoring, when one problem occurs in an MPLS-
   TP network, the operator can detect the fault, but
   is not able to localize it. a fault or degrade.

   Thus, a specific segment monitoring function for detailed analysis,
   by selecting and focusing on and selecting a specific portion of a transport path,
   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
   function of a transport path has implications that hinder the usage
   in an operator network.

   This document elaborates on the problem statement for the path
   segment monitoring function and proposes to consider a new improved
   method of the for segment monitoring, following up the work done in RFC 6371
   [RFC6371].  Moreover, this document explains detailed requirements on
   the new temporal and hitless segment monitoring function which are
   not covered in RFC 6371 [RFC6371].

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

      HPSM

      EPSM - Hitless Enhanced 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

      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 indispensable required network objectives for MPLS-TP networks segment
   monitoring as 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.

   It is common in transport networks that network objective (1) is
   mandatory and that regarding network objective (2) the monitoring
   shall not change the forwarding behavior.

4.  Problem Statement

   To

   Sub-Path Maintenance Element (SPME) is defined in RFC 5921 [RFC5921]
   to monitor, protect, or manage portions of transport paths, such as
   LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is
   defined in RFC 5921 [RFC5921]. networks.  The SPME is defined between the edges of
   the portion of the 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 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 per-node model.

   This method has the following general issues, drawbacks, which are fatal in
   terms of cost and operation. impact on operation
   costs:

      (P-1) Increasing Lowering the overhead bandwidth efficiency by increasing the stacking of overhead
      by shim header(s) headers stacking

      (P-2) Increasing the address network management complexity, as a new sublayer
      and new MEPs and MIPs need to be configured for the SPME in the old MEG

   Problem (P-1) leads to decreased efficiency as bandwidth is wasted
   only for maintenance purposes.  As the size of monitored segments
   increases, the size of the label stack grows.  Moreover, if the
   operator wants to monitor the portion of a transport path without
   service disruption, one or more SPMEs have to be set in advance until
   the end of life of a transport path, which is not temporal or on-
   demand.  Consuming additional bandwidth permanently for only the
   monitoring purpose should be avoided to maximize comes from shim headers stacking that increase the available
   bandwidth.
   overhead.

   Problem (P-2) is related to an identifier-management identifiers management issue.  The
   identification of each layer sub-layer in case of LSP label stacking is
   required in terms of strict sub-layer management for the segment monitoring in a MPLS-TP network.  When SPME/TCM SPME
   is applied for on-
   demand on-demand OAM functions in MPLS-TP networks in a
   similar manner to TCM for OTN or Ethernet transport networks, a
   possible rule of differentiating those SPME/TCMs operationally will
   be necessary at least within an administrative domain.  This enforces
   operators to create an additional permanent layer identification
   policy only for temporal path segment monitoring.  Moreover, from the
   perspective of operation, increasing the managed addresses and the
   managed layer layers is not desirable in terms of simplified operation featured by current to keep transport networks. networks as simple
   as possible.  Reducing the managed identifiers and managed
   layers sub-layers
   should be the fundamental direction in designing the architecture.

   The most familiar example analogy for SPME in legacy transport networks is Tandem
   Connection Monitoring (TCM), which can for example be used for a
   carrier's carrier solution, as shown in Fig. 17 of the framework
   document RFC 5921 [RFC5921].  However, in this case, the SPMEs have
   to be pre-configured.  If this solution is applied to specific
   segment monitoring within one operator domain, all the necessary
   specific segments have to be pre-configured.  This setting increases
   the managed objects as well as the necessary bandwidth, shown as
   Problem (P-1) and (P-2).  Moreover, as a result of these pre-
   configurations, they impose operators to pre-design the structure of
   sub-path maintenance elements, which is not preferable in terms of
   operators' increased burden.  These concerns are summarized in
   section 3.8 of RFC 6371 [RFC6371].

   Furthermore, in reality, all the possible patterns of path segment
   cannot be set in SPME, because overlapping of path segments is
   limited to nesting relationship.  As a result, possible SPME patterns
   of portions of an original transport path are limited due to the
   characteristic of SPME shown in Figure.1, even if SPMEs are pre-
   configured.  This restriction is inconvenient when operators have to
   fix issues in an on-demand manner.  To avoid these issues, the
   temporal and on-demand setting of does not change
   the SPME(s) is needed and more
   efficient for monitoring in MPLS-TP transport network operation.

   However, path.

   Moreover, using currently defined methods, the temporal setting of
   SPMEs also causes the following problems due to label stacking, which
   are fatal in terms of intrinsic monitoring and service disruption.

      (P'-1) stacking:

      (P-3) Changing the original condition of the original transport path by
      changing the length of all the MPLS frames and changing the value of
      exposed label
      value(s)

      (P'-2)

      (P-4) Disrupting client traffic over a transport path, if the SPME
      is temporally configured. configured on demand.

   Problem (P'-1) is a fatal problem in terms of intrinsic monitoring.
   As shown in (P-3) has impacts on network objective (2), the (2).  The monitoring
   function needs to should monitor the status without changing any conditions of
   the targeted monitored segment or the transport path.  Changing the
   settings of the original shim header should not be allowed because
   those changes correspond to creating a new portion of the original
   transport path, which differs from the original data plane
   conditions.  If the conditions of the transport path change, the
   measured value or observed data will also change.  This can may make the
   monitoring meaningless because the result of the monitoring would no
   longer reflect the reality of the connection where the original fault
   or degradation occurred.

   Another aspect is that changing the settings of the original shim
   header should not be allowed because those changes correspond to
   creating a new portion of the original transport path, which differs
   from the original data plane conditions.

   Figure 1 shows an example of SPME setting.  In the figure, X means
   the one label value expected on the tail-end node D of the original
   transport path. "210" and "220" are label allocated for SPME.  The
   label values of the original path are modified as well as the values
   of stacked label.  As shown in Fig.1, Figure 1, SPME changes both the length
   of all
   the MPLS frames and changes label value(s).  This is no longer the monitoring
   of the original transport path but the monitoring of a different
   path.  Particularly, performance monitoring measurement
   (Delay (e.g.  Delay
   measurement and packet loss measurement) are sensitive to those
   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
       A---100--B-----------X---D--130--E  <= transport path
       MEP     \                  /    MEP
                --210--C--220--            <= SPME
               MEP'          MEP'

                  Figure 1: An Example of a SPME setting

   Problem (P-4) can be avoided if the operator sets SPMEs in advance
   until the end of life of a transport path, which is neither temporal
   nor on demand.  Furthermore SMPEs cannot be set arbitrarly because
   overlapping of path segments is limited to nesting relationship.  As
   a result, possible SPME patterns of portions of an original transport
   path
                --210--C--220--            <= SPME
               MEP'          MEP'

                  Figure 1: An Example are limited due to the characteristic of a SPME setting

   Problem (P'-2) was not fully discussed, although shown in Figure 1,
   even if SPMEs are pre- configured.

   Although the make-before-
   break make-before-break procedure in the survivability
   document RFC 6371 6372 [RFC6372] seemingly supports the hitless
   configuration for monitoring according to the framework document RFS RFC
   5921 [RFC5921].  The [RFC5921], the reality is the
   hitless configuration of that configurating an SPME is
   impossible without affecting the
   conditions of the targeted transport path, because the make-before-
   break procedure is premised on the change of the inner label value.
   This means changing one of the settings violating network objective (2).  These concerns
   are reported in MPLS shim header. section 3.8 of RFC 6371 [RFC6371].

   Moreover, this make-before-break approach might not be effective under the
   static model without a control plane because the make-before-break is
   a restoration application based on the control plane.  The removal of  So management
   systems should provide support for SPME whose
   segment is monitored could have the same impact (disruption of client
   traffic) as the creation of an SPME on the same LSP.

   Note: (P'-2) will be removed when non-disruptive make-before-break
   (in both with and without Control Plane environment) is specified in
   other MPLS-TP documents.  However, (P'-2) could be replaced with the
   following issue.  Non-disruptive make-before-break, in other words,
   taking an action similar to switching just for monitoring is not an
   ideal operation in coordinated
   traffic switching from original transport networks.

   The other path to the SPME.

   Other potential risks are also envisaged.  Setting up a temporal SPME
   will result in the LSRs within the 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 could not be found 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 inversion of this situation
   is also possible, .e.g., e.g., incorrect or unexpected treatment of SPME
   labels can result in false detection of a fault where none of the
   problem originally existed.

   The utility of SPMEs is basically limited to 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.  SPME construct monitoring function is particularly important
   mainly for protecting bundles of transport paths and carriers'
   carrier solutions.  SPME is expected to be mainly used for protection
   purpose within one administrative domain.

   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 bandwidth by label stacking
   and managing objects by layer stacking and address management.  A on-
   demand/temporal configuration of SPME is one of the possible
   approaches for minimizing the impact of these issues.  However, the
   current method is unfavorable because the temporal configuration for
   monitoring can change the condition of the original monitored
   transport path( and disrupt the in-service customer traffic).  From path.  To avoid the perspective of monitoring in drawbacks discussed above, a more
   efficient approach is required for MPLS-TP transport network operation, a
   solution avoiding those issues
   operation to overcome or minimizing their minimize the impact is
   required.  Another of the above described
   drawbacks.  A monitoring mechanism is therefore required that
   supports mechanism, named on-demand Enhanced Path
   Segment Monitoring (EPSM), supporting temporal and hitless path
   segment monitoring.  Hereafter it
   is called on-demand hitless path segment monitoring (HPSM).

   Note: The above sentence "and disrupt the in-service customer
   traffic" might need to be modified depending on the result of future
   discussion about (P'-2). is proposed.

5.  OAM functions using supported in segment monitoring

   OAM functions in which that may useful exploited across on-demand HPSM is required EPSM are
   basically limited to on-demand performance monitoring functions which
   are defined in OAM framework document RFC 6371 [RFC6371], because those segment [RFC6371].  Segment
   performance monitoring
   functions are is used to locate evaluate the fault/degraded point or to diagnose performance and hence
   the status for detailed analyses, especially when a problem occurred.
   In other words, the characteristic of transport path segments.  The "on-demand" attribute is
   generally temporal for maintenance operation.  Conversely, this could be a good
   reason that operations should not be based on pre-configuration and
   pre-design.

   Packet loss and packet delay measurements are OAM functions strongly required in which
   hitless and temporal segment monitoring are strongly required because these functions are
   supported only between end points of a transport path.  If a fault or defect
   occurs, there is no way 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 the cause of the fault, it is quite difficult
   to take prompt action actions to solve the problem.  Therefore,

   Other on-demand HPSM for packet loss monitoring functions, (e.g. and packet delay
   measurements Delay variation
   measurement) are indispensable for transport network operation.

   Regarding other on-demand monitoring functions path segment
   monitoring is desirable, desirable but not as urgent necessary as for packet loss and
   packet delay measurements. the previous
   mentioned functions.

   Regarding out-of-service on-demand monitoring functions, such as
   diagnostic tests, performance management functions
   (e.g.  Throughput measurement), there seems no need for HPSM. EPSM.
   However, specific OAM functions specifically designed for segment monitoring
   should be applied developed to the OAM function of
   diagnostic test, because SPME doesn't meet satisfy network objective (2) described in
   section 3.  See section 6.3.

   Note:

      The solution for temporal and hitless segment monitoring should
      not be limited to label stacking mechanisms based on pre-
      configuration, such as PST/TCM(label stacking), which can cause

   Finally, the issues (P-1) and (P-2) described in Section 4.

   The solution for HPSM EPSM has to cover both per-node model and
   per- interface model which are specified in RFC 6371 [RFC6371].

6.  Further consideration of requirements  Requirements for enhanced segmentmonitoring segment monitoring

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

6.1.  Necessity  Non intrusive segment monitoring

   One of on-demand single-level the major problem of legacy SPME that has been highlighted in
   Sec. 4 is that it does not monitor the original transport path and it
   could distrupt service traffic when set-up on demand.

      (M1) EPSM must not change the original condition of transport path
      (e.g. must not change the lenght of MPLS frames, the exposed label
      values, etc.)

      (M2) EPSM must be set on demand without traffic dispruption

6.2.  Single and multiple levels monitoring

   The new segment monitoring function is supposed to be applied mainly
   for on-demand diagnostic purpose on-demand. purpose.  We can differentiate this
   monitoring from the proactive segment monitoring as on-demand multi-
   level monitoring.  The most serious problem at the moment is that
   there is no way to localize the degradation point on degraded portion of a path without
   changing the conditions of the original path.  Therefore, as a first
   step, single layer segment monitoring not affecting the monitored
   path is required for a new on-demand and hitless segment monitoring
   function.  A combination of multi-level and simultaneous segment
   monitoring is the most powerful tool for accurately diagnosing the
   performance of a transport path.  However, considering the substantial benefits to
   operators, a strict monitoring function which is required in such as
   a test environment of on field, a laboratory does not seem to be necessary in
   the field.  To summarize, on-demand and in-service (hitless) single- single level
   approach may be enough.

      (M3) Single-level segment monitoring is required, on-demand and in-service multi-
   level required

      (O1) Multi-level segment monitoring is desirable. desirable

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

     ---     ---     ---     ---     ---
    |   |   |   |   |   |   |   |   |   |
    | A |   | B |   | C |   | D |   | E |
     ---     ---     ---     ---     ---
     MEP                            MEP <= ME of a transport path
         +-----------------------------+   <= End-to-end monitoring
             *------------------*        <= segment monitoring level1       <=On-demand segm. monit. level 1
               *-------------*           <= segment monitoring level2          <=On-demand segm. monit. level 2
                     *-*                 <= segment monitoring level3                <=On-demand segm. monit. level 3

       Figure 2: An Example of a multi-level on-demand segment monitoring

6.2.  Necessity of on-demand monitoring independent from

6.3.  EPSM and end-to-end proactive monitoring

   As multi-level simultaneous monitoring only for on-demand new path
   segment monitoring was already discussed in section6.1, next we
   consider the independence

   The necessity of simultaneous monitoring of end-to-end current end-to-end
   proactive monitoring and new on-demand path segment
   monitoring. monitoring is
   here below considered.  Normally, the on-demand path segment
   monitoring is configured in a segment of a maintenance entity of a
   transport path.  In this such an environment, on-demand single-level
   monitoring should be done without disrupting pro-active monitoring of
   the targeted end- to-end transport path.

   If operators have to disable the pro-active monitoring during the on-
   demand hitless path segment monitoring, the network operation system
   might miss any performance degradation of to avoid missing user traffic.  This kind of
   inconvenience should be avoided in the network operations. traffic
   performance monitoring.

   Accordingly, the on-demand single lavel path segment monitoring is
   required

      (M4) EPSM shall be established without changing or interfering
      with the proactive already in place end-to-end pro-active monitoring of
   the original end-to-end
      transport path. path

     ---     ---     ---     ---     ---
    |   |   |   |   |   |   |   |   |   |
    | A |   | B |   | C |   | D |   | E |
     ---     ---     ---     ---     ---
     MEP                             MEP <= ME of a transport path
       +-----------------------------+   <= Proactive E2E monitoring
             *------------------*        <= On-demand segment monitoring

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

6.3.  Necessity of arbitrary

6.4.  Arbitrary segment monitoring

   The main objective of on-demand segment monitoring is to diagnose the
   fault points.  One possible realistic diagnostic procedure is to fix
   one end point of a segment at the MEP of a transport path and change
   progressively the length of the segment in order.  This example is
   shown in Fig. 4.  This approach is considered as a common and
   realistic diagnostic procedure.  In this case, one end point of a
   segment can be anchored at MEP at any time.

   Other scenarios are also considered, one shown in Fig. 5.  In this
   case, the operators want to diagnose a transport path from a transit
   node that is located at the middle, because the end nodes(A and E)
   are located at customer sites and consist of cost effective small box
   in which a subset of OAM functions are supported.  In this case, if
   one end point and an originator of the diagnostic packet are limited
   to the position of MEP, on-demand segment monitoring will be
   ineffective because all the segments cannot be diagnosed (For
   example, segment monitoring 3 in Fig.5 is not available path under
   observation and it is not
   possible to localize change progressively the fault point). length of the segments.
   This example is shown in Figure 4.

    ---     ---     ---     ---     ---
   |   |   |   |   |   |   |   |   |   |
   | A |   | B |   | C |   | D |   | E |
    ---     ---     ---     ---     ---
    MEP                             MEP <= ME of a transport path
      +-----------------------------+   <= Proactive E2E monitoring
      *-----*                        <= 1st On-demand on-demand segment monitoring
      *-------*                      <= 2nd On-demand on-demand segment monitoring
      *------------*                 <= 3rd On-demand on-demand segment monitoring
           |                                |
           |                                |
      *-----------------------*      <= 6th On-demand on-demand segment monitoring
      *-----------------------------*<= 7th On-demand on-demand segment monitoring

    Figure 4: One possible A procedure to localize a fault point defect by
                  sequential consecutive on-demand segment monitoring

   Accordingly, on-demand monitoring of arbitrary
                            segments monitoring

   Another possible scenario is mandatory depicted in the case in Fig. Figure 5.  As  In this case, the
   operators want to diagnose a result, on-demand HSPM should transport path from a transit node that
   is located at the middle, because the end nodes(A and E) are located
   at customer sites and consist of cost effective small box supporting
   only a subset of OAM functions.  In that case, if 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 3 in Figure 5 is
   not available and it is not possible to precisely localize the fault
   point).

   Accordingly,

      (M5) EPSM shall be set in an arbitrary segment of a transport path
      and diagnostic packets should be inserted from inserted/terminated at least any of
      intermediate maintenance points of the original ME.

              ---     ---     ---
      ---    |   |   |   |   |   |    ---
     | A |   | B |   | C |   | D |   | E |
      ---     ---     ---     ---     ---
      MEP                             MEP <= ME of a transport path
        +-----------------------------+   <= Proactive E2E monitoring
        *-----*                        <= On-demand segment monitoring 1
              *-----------------------*<= On-demand segment monitoring 2
              *---------*              <= On-demand segment monitoring 3

            Figure 5: Example where on-demand monitoring has to be HSPM is configured in at arbitrary segments

6.4.

6.5.  Fault during HPSM while EPSM is in case of protection place

   Node or link failures may occur during the HPSM while EPSM is activated. active.  In that case,
   if no resiliency mechanism is set-up on the hitless subtended transport path,
   there is no particular requirement for EPSM while if the trasport
   path segment monitoring is protected, EPSM function should be
   suspended immediately and must not continue the terminated to avoid
   monitoring on a new
   protected or restored path segment when a protection or restoration for the
   fault path is available. in
   place.  Therefore a solution of HPSM

      (M5) EPSM function should avoid
   such a situation that a target node of the hitless segment monitoring
   is changed to an unintended node segment
      when failures occur on the segment.

   Fig.6 and Fig.7 exemplify one of the

   The folowing examples that should be avoided.
   However, this example is just for clarification of the problem that
   should be avoided.  It does are reported for clarification only and shall
   not intend be intended to restrict any solution for meeting the requirements
   of HPSM. EPSM.  A Protection scenario A is shown in figure 6.  In this
   scenario, a working LSP and a protection LSP are
   separately set, in other words as independent LSPs.  HPSM set.  EPSM is set
   between A and E.  Therefore, considering the case that  Considering a fault happens between nodes B and C,
   the HPSM doesn't continue EPSM is not affected by protection and continues in a protected the working
   LSP path.  As a result, there requirement (M5) is no issue. satisfied.

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

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

                      Figure 6: Protection scenario A having no issue when a fault happens
                                 on HPSMs

   On the other hand,

   Differently, figure 7 shows a scenario where only a portion of a
   transport path has different label assignments (sub-paths). is protected.  In this case, when a fault condition is identified on working sub-path
   B-C-D, happen
   between node B and C along the sub-path working sub-path, traffic is switched
   to protection sub-path B-G-H-D.  As a
   result,  In the hypotesis that OAM packets
   termination depend only on TTL value of MPLS label header, the target
   node of HPSM EPSM changes from E to D due to the difference of hop counts
   between a route of the working path(ABCDE: path route (ABCDE: 4 hops) and that of protection path(ABGHDE: 5 hops), because the
   forwarding and processing of HPSM OAM packets depend only on TTL
   value of MPLS label header.  In this case, some additional mechanisms
   to notify the fault on working path to the source of HPSM may be
   necessary to suspend the monitoring.
   route (ABGHDE: 5 hops).  As a result, requirement (M5) is not
   satisfied.

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

      - e2e LSP: A-B...D-E-F A-B-C-D-E-F
      - working sub-path: B-C-D
      - protection sub-path: B-G-H-D
      - HPSM: EPSM: A-E
      ---------------

                      Figure 7: Protection scenario B having an issue when a fault happens
                                  on HPSM

6.5.  Consideration of

6.6.  EPSM maintenance point for HPSM points

   An intermediate maintenance point supporting the HPSM EPSM has to be able
   to generate and inject OAM packets.  Although maintenance points for
   the HPSM EPSM do not necessarily have to coincide with MIPs or MEPs in
   terms of the architecture definition, the

      (M7) The same identifier identifiers for MIPs or and/or MEPs could should be applied
      to EPSM maintenance points of the HPSM.

7.  Summary

   An enhanced monitoring mechanism is required to support temporal and
   hitless segment monitoring which meets the two network objectives
   mentioned in Section 3 of this document that are
   described also in section 3.8 of RFC 6371 [RFC6371]. [RFC6371] and reported in
   Section 3 of this document.

   The enhancements should minimize the issues described in Section 4,
   i.e., P-1, P-2, P'-1( P-3 and P'-2), to meet those two network
   objectives. P-4.

   The solution for the temporal and hitless segment monitoring has to
   cover both per-node model and per-interface model which are specified
   in RFC 6371 [RFC6371].  In addition, the following requirements
   should be considered for an enhanced temporal and hitless path
   segment monitoring function:

   o  "On-demand and in-service" single level segment should be done
      without changing or interfering any condition of pro-active
      monitoring of an original ME of a transport path.

   o  On-demand and in-service segment monitoring should be able to be
      set in an arbitrary segment of a transport path.

   The temporal and hitless segment monitoring solutions is applicable
   to and needs to shall support several
   on-demand OAM functions, as follows:
   Mandatory: Packet Loss Measurement and Packet Delay Measurement
   Optional: Connectivity Verification, Diagnostic Tests (Throughput
   test),
   functions and Route Tracing. optionally other performance monitoring /fault
   management functions (e.g.  Throughput measurement, Delay variation
   measurement, Diagnostic test measurement, etc.).

8.  Security Considerations

   The security considerations defined for RFC 6378 apply to this
   document as well.  As this is simply a re-use of RFC 6378, there are
   no new security considerations.

9.  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.  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, Italo Busi, Maarten Vissers,
   Malcolm Betts, Nurit Sprecher and Jia He for their comments and
   enhancements to the text.

11.  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. 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. 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. 2010,
              <http://www.rfc-editor.org/info/rfc5860>.

   [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. 2010,
              <http://www.rfc-editor.org/info/rfc5921>.

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

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

Authors' Addresses

   Alessandro D'Alessandro
   Telecom Italia

   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: koike.yoshinori@lab.ntt.co.jp