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

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

Abstract

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

   One of the most important mechanisms which that is common for transport
   network operation is fault location. localisation.  A segment monitoring
   function of a transport path is effective in terms of extension of
   the maintenance work and indispensable indispensable, particularly when the OAM
   function is effective activated only between end points.  However, the current
   approach defined for MPLS-TP for the of segment monitoring (SPME) has some
   drawbacks.  This document elaborates on the problem statement for the
   Sub-path Maintenance Elements (SPMEs) which provides provide monitoring of a
   portion
   segment of a set of transport paths (LSPs or MS-PWs).  Based on the
   identified problems, this document specifies provides considerations for the
   specification of new requirements to consider a new improved
   mechanism of for hitless transport path segment monitoring to be 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 January 21, June 4, 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 . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Network objectives for segment monitoring . . . . . . . . . .   4
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4   5
   5.  OAM functions supported in segment monitoring . . . . . . . .   8
   6.  Requirements for enhanced segment monitoring  . . . . . . . .   8   9
     6.1.  Non intrusive  Non-intrusive segment monitoring  . . . . . . . . . . . .   9
     6.2.  Single and multiple levels level monitoring  . . . . . . . . . .   9
     6.3.  EPSM and end-to-end proactive monitoring independence . .  10
     6.4.  Arbitrary segment monitoring  . . . . . . . . . . . . . .  10  11
     6.5.  Fault while EPSM is in place  . operational . . . . . . . . . . . . .  12
     6.6.  EPSM maintenance points . . . . . . . . . . . . . . . . .  13
   7.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  13  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  14  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   A packet transport network enables carriers or and service providers to
   use network resources efficiently, efficiently.  It reduces operational complexity
   and provides carrier-grade network operation.  Appropriate
   maintenance
   functions, supporting functions that support fault location, survivability,
   pro-active performance
   monitoring monitoring, pre-service and preliminary or 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 TDM, PDH, ATM, SDH and OTN.

   As

   Similar to legacy technologies, also MPLS-TP does also not scale when an
   arbitrary number of OAM functions are is 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 that affects their services.  In addition, to ensure
   that faults or degradations service degradation can be localized, operators need a method
   function to
   analyze or investigate diagnose the problem being detected problem.  Using end-to-end
   monitoring for this purpose is insufficient.  In fact by using end-to-end end-
   to-end OAM monitoring, an operator
   is will not be able to localize a
   fault or degrade. service degradation accurately.

   Thus, a specific dedicated segment monitoring function for detailed analysis,
   by selecting and focusing that can focus on a
   specific portion segment of a transport path, 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
   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 for segment monitoring, following up the work done description in RFC
   6371 [RFC6371].  Moreover, this  This document explains also provides additional detailed
   requirements on
   the for a new temporal temporary and hitless segment monitoring
   function which are is 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

      ATM - Asynchronous Transfer Mode

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

      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 required network objectives for MPLS-TP segment monitoring as
   described in section 3.8 of RFC 6371 [RFC6371]. [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 Sub-Path Maintenance Element (SPME) function is defined in RFC
   5921 [RFC5921] [RFC5921].  It is used to monitor, protect, or and/or manage portions
   segments of transport paths, such as LSPs in MPLS-TP networks.  The
   SPME is defined between the edges of the portion segment of the 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 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, which drawbacks that impact on the operation
   costs:

      (P-1) Lowering It lowers the bandwidth efficiency by increasing the overhead
      by shim headers stacking efficiency.

      (P-2) Increasing It increases network management complexity, as because a new
      sublayer and new MEPs and MIPs need have to be configured for the SPME SPME.

   Problem (P-1) comes from is caused by the shim headers stacking that increase increases
   the overhead.

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

   The analogy for SPME in legacy transport networks is Tandem
   Connection Monitoring (TCM), TCM, which is
   on-demand and does not change affect the transport path.

   Moreover,

   Also, using the currently defined methods, the temporal temporary setting of SPMEs also
   causes the following problems due to additional label stacking:

      (P-3) Changing the The original condition of the transport path is affected by
      changing the length of MPLS frames and changing the value of
      exposed label label.

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

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

   Figure 1 shows an example of SPME setting. settings.  In the figure, X means "X" is
   the label value expected on the tail-end node D of the original transport path. path expected at the 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 label. 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 the monitoring
   of the original transport path but the it is
   monitoring of a different path.  Particularly,  In particular, performance monitoring measurement
   measurements (e.g.  Delay
   measurement Measurement and packet loss measurement) Packet Loss Measurement)
   are sensitive to those these changes.

      (Before SPME settings)
       ---     ---     ---     ---     ---
      |   |   |   |   |   |   |   |   |   |
      |   |   |   |   |   |   |   |   |   |
       ---     ---     ---     ---     ---
       A---100--B--110--C--120--D--130--E
        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 settings

   Problem (P-4) can be avoided if the operator sets SPMEs in advance
   and maintains it until the end of life of a transport path, which is
   neither temporal temporary nor on demand. on-demand.  Furthermore SMPEs cannot be set arbitrarly
   arbitrarily because overlapping of path segments is limited to
   nesting relationship. relationships.  As a result, possible SPME patterns configurations of portions
   segments of an original transport path are limited due to the
   characteristic of 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], the reality is that configurating configuration of an SPME is
   impossible without violating network objective (2). (2) in Section 3.
   These concerns are reported described in section 3.8 of RFC 6371 [RFC6371].

   Moreover,

   Additionally, the make-before-break approach might not be effective under usable in
   the static model without a control plane plane.  This is because the make-before-break make-
   before-break is a restoration application function based on the a control plane.  So
   Consequently the management systems should provide support for SPME creation and for
   coordinated traffic switching from original transport path to the
   SPME.

   Other potential risks are also envisaged.  Setting up a temporal temporary
   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 can not be found identified when setting up
   SPME.  This might include hardware problems during label look-up, mis-
   configuration
   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 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 none of the no problem originally existed. existed originally.

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

   To summarize, 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 objects by layer
   stacking and address management.  A on-
   demand/temporal  An on-demand/temporary
   configuration of SPME is one of the possible approaches for
   minimizing the impact of these issues.  However, the current method
   procedure is unfavorable because the temporal temporary configuration for
   monitoring can change 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 MPLS-TP transport network
   operation to overcome or minimize the impact
   operation of the above described
   drawbacks. an MPLS-TP transport network.  A monitoring mechanism,
   named on-demand Enhanced Path Segment Monitoring (EPSM), supporting temporal
   temporary and hitless path segment monitoring is proposed.

5.  OAM functions supported in segment monitoring

   OAM functions that may useful usefully be exploited across on-demand EPSM
   are basically limited to the on-demand performance monitoring functions which
   are defined in OAM framework document RFC 6371 [RFC6371].  Segment
   performance monitoring is used to evaluate verify the performance and hence
   the status of transport path segments.  The "on-demand" attribute is
   generally temporal temporary for maintenance operation.

   Packet loss Loss and packet delay Packet Delay measurement are OAM functions strongly
   required in hitless and temporal temporary segment monitoring because these
   functions are
   supported normally only between 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 of
   the fault, it is quite difficult to take prompt actions to solve the
   problem.

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

   Regarding out-of-service on-demand performance management functions
   (e.g.  Throughput measurement), measurement) there seems no need for EPSM.
   However, OAM functions specifically designed for segment monitoring
   should be developed to satisfy network objective (2) described in
   section
   Section 3.

   Finally, the solution for EPSM has to cover both the per-node model
   and
   per- interface the per-interface model which are as specified in RFC 6371 [RFC6371].

6.  Requirements for enhanced segment monitoring

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

6.1.  Non intrusive  Non-intrusive segment monitoring

   One of the major problem problems of legacy SPME that has been highlighted in
   Sec. section 4 is
   that it does may 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 length of MPLS frames, the exposed
      label values, etc.)

      (M2) EPSM must be set on demand provisioned on-demand without traffic dispruption
      disruption.

6.2.  Single and multiple levels level monitoring

   The new enhanced segment monitoring function is supposed to be
   applied mainly for on-demand diagnostic purpose. purposes.  We can
   differentiate this monitoring from the existing proactive segment
   monitoring by referring to is as on-demand multi-
   level multi-level monitoring.  The
   Currently the most serious problem at the moment is that there is no way to localize locate
   the degraded portion segment of a path without changing the conditions of the
   original path.  Therefore, as a first step, single layer segment monitoring
   monitoring, not affecting the monitored
   path 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, on in the field, a single level approach may be enough.

      (M3) Single-level segment monitoring is required

      (O1) Multi-level segment monitoring is 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
             *------------------*
              *-----------------*         <=On-demand segm. monit. mon. level 1
                *-------------*           <=On-demand segm. monit. mon. level 2
                      *-*                 <=On-demand segm. monit. mon. level 3

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

6.3.  EPSM and end-to-end proactive monitoring independence

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

   Accordingly,

   Therefore:

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

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

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

6.4.  Arbitrary segment monitoring

   The main objective of for enhanced on-demand segment monitoring is to
   diagnose the fault points.  One 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.

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

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

   Another possible scenario is depicted in Figure 5.  In this case, the
   operators want
   operator wants to diagnose a transport path from starting at a transit node that
   is located at the middle,
   node, because the end nodes(A and E) are located at customer sites
   and consist of cost effective small box boxes supporting only a subset of
   OAM functions.  In that this case, if where the source entities of the
   diagnostic packets are limited to the position of MEPs, on-
   demand 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 determine the fault
   point).

   Accordingly, location
   exactly).

   Therefore:

      (M5) EPSM it shall be set in possible to provision EPSM 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
        +-----------------------------+   <= Proactive E2E monitoring Pro-active end-to-end mon.
        *-----*                           <= On-demand segment monitoring mon. 1
              *-----------------------*<=
              *-----------------------*   <= On-demand segment monitoring mon. 2
              *---------*                 <= On-demand segment monitoring mon. 3

              Figure 5: HSPM is ESPM configured at arbitrary segments

6.5.  Fault while EPSM is in place operational

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

      (M5) active.

   Therefore:

      (M6) the EPSM function should avoid monitoring an unintended
      segment when one or more failures occur

   The folowing following examples are reported provided for clarification only and shall they
   are not be intended to restrict any solution for meeting the
   requirements of EPSM.  A

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

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

      Where:
      - e2e 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
      - EPSM:           A-E
      ---------------

                      Figure 6: Protection scenario A

   Differently,

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

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

      - e2e 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: Protection scenario B

6.6.  EPSM maintenance points

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

   Therefore:

      (M7) The same identifiers for MIPs and/or MEPs should be applied
      to EPSM maintenance points

7.  Summary

   An enhanced path segment monitoring (EPSM) mechanism is required to support temporal
   provide temporary and hitless segment monitoring which meets monitoring.  It shall meet the
   two network objectives described in section 3.8 of RFC 6371 [RFC6371]
   and reported repeated in Section 3 of this document.

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

   The solution for the temporal temporary and hitless segment monitoring has to
   cover both the per-node model and the per-interface model which are specified
   in RFC 6371 [RFC6371].

   The temporal temporary and hitless segment monitoring solutions shall support
   on-demand Packet Loss Measurement and Packet Delay Measurement
   functions and optionally other performance monitoring /fault and fault
   management functions (e.g.  Throughput measurement, Delay variation
   measurement, Diagnostic test measurement, test, 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, Malcolm Betts, Italo Busi,
   Maarten Vissers,
   Malcolm Betts, Nurit Sprecher and Jia He and Nurit Sprecher 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,
              <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>.

   [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

   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 y.koike@vcd.nttbiz.com