Network Working Group
Internet Engineering Task Force (IETF)                   A. D'Alessandro
Internet-Draft
Request for Comments: 8256                                Telecom Italia
Intended status:
Category: Informational                                     L. Andersson
Expires: March 5, 2018
ISSN: 2070-1721                                      Huawei Technologies
                                                                 S. Ueno
                                                      NTT Communications
                                                                 K. Arai
                                                                Y. Koike
                                                                     NTT
                                                       September 1,
                                                            October 2017

         Requirements for hitless Hitless MPLS path segment monitoring
             draft-ietf-mpls-tp-temporal-hitless-psm-14.txt Path Segment Monitoring

Abstract

   One of the most important OAM Operations, Administration, and Maintenance
   (OAM) capabilities for transport network transport-network operation is fault localisation.
   localization.  An in-service, on-demand path segment monitoring
   function of a transport path is indispensable, particularly when the
   service monitoring function is activated only between end points. endpoints.
   However, the current segment monitoring approach defined for MPLS
   (including the transport profile MPLS Transport Profile (MPLS-TP)) in RFC 6371
   "Operations, Administration, and Maintenance Framework for MPLS-
   Based MPLS-Based
   Transport Networks" has drawbacks.  This document provides an
   analysis of the existing MPLS-TP OAM mechanisms for the path segment
   monitoring and provides requirements to guide the development of new
   OAM tools to support a Hitless Path Segment Monitoring (HPSM).

Status of This Memo

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

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 March 5, 2018.
   https://www.rfc-editor.org/info/rfc8256.

Copyright Notice

   Copyright (c) 2017 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)
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used Used in this document This Document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Requirements for Hitless Path Segment Monitoring HPSM . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Backward compatibility Compatibility  . . . . . . . . . . . . . . . . .   7
     4.2.  Non-intrusive segment monitoring  Non-Intrusive Segment Monitoring  . . . . . . . . . . . .   8
     4.3.  Monitoring Multiple segments monitoring Segments  . . . . . . . . . . . . . .   8
     4.4.  Monitoring Single and multiple level monitoring Multiple Levels . . . . . . . . . .   8
     4.5.  HPSM and end-to-end proactive monitoring independence End-to-End Proactive Monitoring Independence . .   9
     4.6.  Monitoring an Arbitrary segment monitoring  . Segment . . . . . . . . . . . . .  10   9
     4.7.  Fault while HPSM is operational Is Operational . . . . . . . . . . . . .  11
     4.8.  HPSM Manageability  . . . . . . . . . . . . . . . . . . .  12
     4.9.  Supported OAM functions Functions . . . . . . . . . . . . . . . . .  13  12
   5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Contributors  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgements
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . .  14
   10. References . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . .  15
   Acknowledgements  . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], mechanisms MUST
   be available for alerting service providers of faults or defects that affects
   affect 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 that an operator will not be able to localize a
   fault or service degradation accurately.

   A segment monitoring function that can focus on a specific segment of
   a transport path and that can provide a detailed analysis is
   indispensable to promptly and accurately localize the fault.  A path
   segment monitoring
   function for monitoring path segments has been defined to perform
   this task for MPLS-TP.  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, after

   After elaborating on the problem statement for the path segment
   monitoring function as it is currently defined, this document
   provides requirements for an on-demand path segment monitoring
   function without traffic distruption. disruption.  Further works are required to
   evaluate how proposed requirements match with current MPLS
   architecture and to identify possibile possible solutions.

2.  Conventions used Used in this document This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1.  Terminology

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

      TCM - Tandem connection monitoring Connection Monitoring

      SPME - Sub-path Sub-Path Maintenance Element

3.  Problem Statement

   To

   A Sub-Path Maintenance Element (SPME) function to monitor (and to
   protect and/or manage) MPLS-TP network segments a
   Sub-Path Maintenance Element (SPME) function has been is defined in RFC
   5921
   [RFC5921].  The SPME is defined between the edges of the segment of a
   transport path that needs to be monitored, protected, or managed.
   SPME is created by stacking the shim header (MPLS header) header), according
   to RFC 3031 [RFC3031] and [RFC3031]; it is defined as the segment where the header is
   stacked.  OAM messages can be initiated at the edge of the SPME and SPME.
   They can be 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 Label Stack Entry (LSE) and
   interface identifier value at the corresponding hierarchical LSP
   level in case of a per-node model.

   According to Section 3.8 of [RFC6371], MPLS-TP segment monitoring
   should satisfy two network objectives
   according to section 3.8 of RFC 6371 [RFC6371]: objectives:

   (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 is defined in RFC 5921 [RFC5921] has the following
   drawbacks:

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

   (P2)  Original conditions of the path change.

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

   Problem (P1) is related to the management of each additional sub-
   layer required for segment monitoring in a an MPLS-TP network.  When an
   SPME is applied to administer on-demand OAM functions in MPLS-TP
   networks, a rule for operationally differentiating those SPME SPMEs will
   be required at least within an administrative domain.  This forces
   operators to implement at least an additional layer into the
   management systems that will only be used for on-demand path segment
   monitoring.  From the perspective of operation, increasing the number
   of managed layers and managed addresses/identifiers is not desirable
   in view of keeping the management systems as simple as possible.
   Moreover, using the currently defined methods, on-demand setting of
   SPMEs causes problems (P2) and (P3) due to additional label stacking.

   Problem (P2) arises from because the fact that MPLS exposed MPLS-exposed label value and MPLS frames
   frame length changes. change.  The monitoring function should monitor the
   status without changing any condition of the target, to be
   monitored, target segment or of the
   target transport path.  Changing the settings of the original shim
   header should not be allowed allowed, because this change corresponds to
   creating a new segment of the original transport path that differs
   from the original one.  When the conditions of the path change, the
   measured values or observed data will also change and
   this change.  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.  As an example, setting up an on-demand on-
   demand 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 cannot be identified when setting up
   SPME.  This might include hardware problems during label look-up, mis-configuration, lookup,
   misconfiguration, etc.  Therefore  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., possible; for example, 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 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 are the values of the
   stacked labels.  As shown in Figure 1, SPME changes both the length
   of MPLS frames and the label value(s).  In particular, performance
   monitoring measurements (e.g. (e.g., Delay Measurement and Packet Loss
   Measurement) are sensitive to these changes.  As an example,
   increasing the packet lenght length may impact on packet loss due to MTU
   settings,
   settings; modifying the label stack may introduce packet loss loss, or it
   may fix packet loss depending on the configuration status so
   modifying network conditions. status.  Such
   changes influence packets delay
   too packet delay, too, even if, from a practical point
   of view, it is likely that only a few services will experience a
   practical impact.

      (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: SPME settings example Settings Example

   Problem (P3) can be avoided if the operator sets SPMEs in advance and
   maintains them until the end of life of a transport path.  But path: but this
   does not support on-demand.  Furthermore  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.
   preconfigured.

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

   Additionally, the make-before-break approach typically relies on a
   control plane and requires additional functionalities for a
   management system to properly support SPME creation and traffic
   switching from the original transport path to the SPME.

   As an example, the old and new transport resources (e.g. (e.g., LSP
   tunnels) might compete with each other for resources which that they have
   in common.  Depending on availability of resources, this competition
   can cause admission control to prevent the new LSP tunnel from being
   established as this bandwidth accounting deviates from the
   traditional
   (non control (non-control plane) management system management-system operation.  While
   SPMEs can be applied in any network context (single domain, multi (single-domain, multi-
   domain, single
   carrier, multi carrier, single-carrier, multi-carrier, etc.), the main applications
   are in inter-
   carrier inter-carrier or inter-domain segment monitoring where they
   are typically
   pre- configured preconfigured or pre-instantiated.  SPME instantiates a
   hierarchical path (introducing MPLS label 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 the carriers'
   carrier solutions within an administrative domain.

   The analogy for SPME in other transport technologies is Tandem
   Connection Monitoring (TCM), (TCM).  TCM is used in Optical Transport
   Networks (OTN) (OTNs) and Ethernet transport networks, which networks.  It supports on-demand on-
   demand but does not affect the path.  For example example, in OTN, OTNs, 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  Though, as the OAM overhead is part of the frame
   (designated overhead bytes), it is constrained to a pre-defined predefined 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
   preconfiguration in terms of increasing the number of managed objects
   by layer stacking and identifiers/addresses.  An on-demand
   configuration of SPME is one of the possible approaches for
   minimizing the impact of these issues.  However, the current
   procedure is unfavourable unfavorable because the on-demand configuration for
   monitoring changes the condition of the original monitored 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 Hitless "Hitless Path
   Segment Monitoring Monitoring" (HPSM), supporting on-demand path segment
   monitoring without traffic disruption is needed.

4.  Requirements for Hitless Path Segment Monitoring HPSM

   In the following sections, mandatory (M) and optional (O)
   requirements for the Hitless Path Segment Monitoring HPSM function are listed.

4.1.  Backward compatibility Compatibility

   HPSM would be an additional OAM tool that would not replace SPME.  As
   such:

   (M1)  HPSM MUST be compatible with the usage of SPME SPME.

   (O1)  HPSM SHOULD be applicable at the SPME layer too too.

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

4.2.  Non-intrusive segment monitoring  Non-Intrusive Segment Monitoring

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

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

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

4.3.  Monitoring Multiple segments monitoring Segments

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

   (M5)  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: Multiple HPSM instances example Instances Example

4.4.  Monitoring Single and multiple level monitoring Multiple Levels

   HPSM would apply mainly for on-demand diagnostic purposes.  With the
   currently 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 segment monitoring,
   single-level, single-segment monitoring not affecting the monitored
   path,
   path is required for HPSM.  A combination of multi-level and  Monitoring simultaneous segments monitoring on
   multiple levels is the most powerful tool for accurately diagnosing
   the performance of a transport path.  However, in the field, a single
   single- level, multiple segments multiple-segment approach would be less complex for
   management and operations.

   (M6)  HPSM MUST support single-level segment monitoring monitoring.

   (O2)  HPSM MAY support multi-level segment monitoring.

   Figure 3 shows an example of multi-level HPSM.

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

                    Figure 3: Multi-level Multi-Level HPSM example Example

4.5.  HPSM and end-to-end proactive monitoring independence End-to-End Proactive Monitoring Independence

   There is a need for simultaneously using existing end-to-end
   proactive monitoring and on-demand path segment 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 proactive monitoring of the targeted end-to-
   end transport path to avoid affecting monitoring of user traffic performance
   monitoring.
   performance.

      (M7) HPSM MUST support the capability of being operated
      concurrently to, and independently of of, the OAM function operated on the
      end-to-end path path.

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

    Figure 4: Independence between proactive end-to-end monitoring Proactive End-to-End Monitoring and
                              on-demand
                              On-Demand HPSM

4.6.  Monitoring an Arbitrary segment monitoring Segment

   The main objective for on-demand path segment monitoring is to
   diagnose the fault locations.  A possible realistic diagnostic
   procedure is to fix one end point endpoint of a segment at the MEP of the
   transport path under observation and change progressively change the length
   of the segments.  It
   is therefore is, therefore, possible to monitoring step by step monitor all the path
   paths, step-by-step, with a granularity that depends on equipment
   implementations.  For example, Figure 5 shows the case where the
   granularity is at the interface level
   (i.e. (i.e., monitoring is at each
   input interface and output interface of each piece of equipment).

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

     Figure 5: Localization of a defect Defect by consecutive on-demand segment
                           monitoring procedure Consecutive On-Demand Path
                       Segment Monitoring Procedure

   Another possible scenario is depicted in Figure 6.  In this case, the
   operator wants to diagnose a transport path starting at a transit
   node,
   node because the end nodes (A and E) are located at customer sites
   and consist of 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 path segment monitoring
   will be ineffective because not all the segments can be diagnosed (e.g.
   (e.g., segment monitoring HPSM 3 in Figure 6 is not available available, and it
   is not possible to determine the fault location exactly).

      (M8) It SHALL be possible to provision HPSM on an arbitrary
      segment of a transport path.

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

            Figure 6: HPSM configuration Configuration at arbitrary segments Arbitrary Segments

4.7.  Fault while HPSM is operational Is Operational

   Node or link failures may occur while HPSM is active.  In this case,
   if no resiliency mechanism is set-up set up on the subtended transport path,
   there is no particular requirement for HPSM.  If the transport path
   is protected, the HPSM function may bring to monitoring monitor unintended segments.  The
   following examples are provided for clarification.

   Protection scenario A is shown in figure Figure 7.  In this scenario scenario, a
   working LSP and a protection LSP are set-up. set up.  HPSM is activated
   between nodes A and E.  When a fault occurs between nodes B and C,
   the operation of HPSM is not affected by the protection switch and
   continues on the active LSP path. LSP.

      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-G-H-I-L-F
      - HPSM:           A-E

                      Figure 7: Protection scenario Scenario A

   Protection scenario B is shown in figure Figure 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 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).  In this case case, the operation of HPSM is
   affected.

          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
      - HPSM:                A-E

                      Figure 8: Protection scenario Scenario B
   (M9)  The HPSM SHOULD avoid monitoring an unintended segment when one
         or more failures occur occur.

   There are potentially different solutions to satisfy such a
   requirement.  A possible solution may be to suspend HPSM monitoring
   until network restoration takes place.  Another possible approach may
   be to compare the node/interface ID in the OAM packet with that at
   the node reached at TTL termination and and, if this does not match
   through some means trigger match, a
   suspension of HPSM monitoring. monitoring should be triggered.  The above
   approaches are valid in any circumstance, both for protected and
   unprotected networks LSPs.  These examples should not be taken to
   limit the design of a solution.

4.8.  HPSM Manageability

   From a 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.

      (M10)HPSM

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

   (M11) The same identifiers used for MIPs and/or MEPs SHOULD be
         applied to maintenance points for the HPSM when they are
         instantiated in the same place along a transport path.

      Anyway maintenance

         Maintenance points for the HPSM may be different from the
         functional components of MIPs and MEPs functional components as defined in the OAM
         framework document RFC 6371 [RFC6371].  Investigating potential
         solutions for satisfying proposed HPSM requirements might may lead to propose
         identifying new functional components; these components that have need to
         be backward compatible with MPLS architecture.  Solutions are
         outside the scope of this document.

4.9.  Supported OAM functions Functions

   A 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 that are defined in the OAM framework document
   RFC 6371
   [RFC6371].  The "on-demand" attribute is typically temporary for
   maintenance operation.

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

   That because these

   These functions are normally only supported at the end
   points endpoints 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. (e.g., Delay Variation
   measurement) are desirable but not as necessary as the functions
   mentioned above.

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

   Support of out-of-service on-demand performance management performance-management functions
   (e.g.
   (e.g., Throughput measurement) is not required for HPSM.

5.  Summary

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

   The mechanism should minimize the problems described in Section 3,
   i.e.
   i.e., (P1), (P2) (P2), and (P3).

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

   The on-demand path segment monitoring 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. (e.g., Throughput
   measurement, Packet Delay variation measurement, Diagnostic test,
   etc.).

6.  Security Considerations

   Security is a significant requirement of the MPLS Transport Profile.  The
   This document provides a problem statement and requirements to guide
   the development of new OAM tools to support Hitless Path Segment
   Monitoring. HPSM.  Such new tools
   must follow the security considerations provided in OAM Requirements
   for MPLS-TP in RFC5860 [RFC5860].

7.  IANA Considerations

   There are no requests for

   This document does not require any IANA actions in this document.

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

10. actions.

8.  References

10.1.

8.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, <https://www.rfc-
              editor.org/info/rfc2119>.
              <https://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, <https://www.rfc-
              editor.org/info/rfc3031>.
              <https://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, <https://www.rfc-
              editor.org/info/rfc5860>.

10.2.
              <https://www.rfc-editor.org/info/rfc5860>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.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,
              <https://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, <https://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, <https://www.rfc-
              editor.org/info/rfc6372>.

8.
              <https://www.rfc-editor.org/info/rfc6372>.

Contributors

   Manuel Paul
   Deutsche Telekom AG

   Email: manuel.paul@telekom.de

9.

Acknowledgements

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

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 loa@pi.nu

   Satoshi Ueno
   NTT Communications

   Email: satoshi.ueno@ntt.com ueno@nttv6.jp

   Kaoru Arai
   NTT

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

   Yoshinori Koike
   NTT

   Email: y.koike@vcd.nttbiz.com