Skip to main content

Temporal and hitless path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8256.
Authors Alessandro D'Alessandro , Manuel Paul , Satoshi Ueno , Yoshinori Koike
Last updated 2013-10-21
Replaces draft-koike-mpls-tp-temporal-hitless-psm
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Waiting for WG Chair Go-Ahead
Associated WG milestone
Aug 2015
Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication
Document shepherd Ross Callon
IESG IESG state Became RFC 8256 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-mpls-tp-temporal-hitless-psm-04
MPLS Working Group                                     A. D'Alessandro
Internet Draft                                          Telecom Italia
                                                               M.Paul
                                                      Deutsche Telekom
Intended status: Informational                                S. Ueno
                                                    NTT Communications
                                                              Y.Koike
                                                                  NTT

Expires: Mar. 20, 2014                                    Oct 21, 2013

               Temporal and hitless path segment monitoring
              draft-ietf-mpls-tp-temporal-hitless-psm-04.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on March 20, 2014.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Koike, et al.          Expires March 20, 2014                 [Page 1]
Internet-Draft        Temporal and hitless PSM            October 2013

   publication of this document. Please review these documents carefully,
   as they describe your rights and restrictions with respect to this
   document. Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

Abstract

   The MPLS transport profile (MPLS-TP) is being standardized to enable
   carrier-grade packet transport and complement converged packet
   network deployments. Among the most attractive features of MPLS-TP
   are OAM functions, which enable network operators or service
   providers to provide various maintenance characteristics, such as
   fault location, survivability, performance monitoring, and
   preliminary or in-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.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network.

Table of Contents

   1. Introduction ................................................ 4
   2. Conventions used in this document............................ 4
      2.1. Terminology ............................................ 5

Koike, et al.           Expires March 20, 2014                 [Page 2]
Internet-Draft        Temporal and hitless PSM            October 2013

      2.2. Definitions ............................................ 5
   3. Network objectives for monitoring............................ 5
   4. Problem statement ........................................... 6
   5. OAM functions using segment monitoring ...................... 10
   6. Further consideration of requirements for enhanced segment
   monitoring .................................................... 10
      6.1. Necessity of on-demand single-level monitoring.......... 11
      6.2. Necessity of on-demand monitoring independent from end-to-end
      proactive monitoring........................................ 11
      6.3. Necessity of arbitrary segment monitoring .............. 12
      6.4. Fault during HPSM in case of protection ................ 13
   7. Summary .................................................... 15
   8. Security Considerations..................................... 16
   9. IANA Considerations ........................................ 16
   10. References ................................................ 16
      10.1. Normative References.................................. 16
      10.2. Informative References................................ 16
   11. Acknowledgments ........................................... 16

Koike, et al.           Expires March 20, 2014                 [Page 3]
Internet-Draft        Temporal and hitless PSM            October 2013

1. Introduction

   A packet transport network will enable carriers or service providers
   to use network resources efficiently, reduce operational complexity
   and provide 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 also transmitted in idle mode, it is not per se
   possible to constantly monitor the status of individual connections
   in packet networks. Packet-based OAM functions are flexible and
   selectively configurable according to operators' needs.

   According to the MPLS-TP OAM requirements [1], mechanisms MUST be
   available for alerting a service provider of a fault or defect
   affecting the service(s) provided. 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,
   end-to-end monitoring is insufficient. 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.

   Thus, a specific segment monitoring function for detailed analysis,
   by 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[5],
   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 segment monitoring, following up the work done in [5].
   Moreover, this document explains detailed requirements on the new
   temporal and hitless segment monitoring function which are not
   covered in [5].

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

Koike, et al.           Expires March 20, 2014                 [Page 4]
Internet-Draft        Temporal and hitless PSM            October 2013

  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

   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 monitoring

   There are two indispensable network objectives for MPLS-TP networks
   as described in section 3.8 of [5].

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

Koike, et al.           Expires March 20, 2014                 [Page 5]
Internet-Draft        Temporal and hitless PSM            October 2013

4. Problem statement

   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 [2]. 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)[3] 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, which are fatal in
   terms of cost and operation.

   (P-1) Increasing the overhead by the stacking of shim header(s)

   (P-2) Increasing the address management complexity, as 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 the available
   bandwidth.

   Problem (P-2) is related to an identifier-management issue. The
   identification of each 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 is applied for on-
   demand OAM functions in MPLS-TP networks in a similar manner to 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 is not
   desirable in terms of simplified operation featured by current
   transport networks. Reducing the managed identifiers and managed
   layers should be the fundamental direction in designing the
   architecture.

Koike, et al.           Expires March 20, 2014                 [Page 6]
Internet-Draft        Temporal and hitless PSM            October 2013

   The most familiar example for SPME in 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[2]. 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 [5].

   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 the SPME(s) is needed and more
   efficient for monitoring in MPLS-TP transport network operation.

   However, 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) Changing the condition of the original transport path by
   changing the length of all the MPLS frames and changing label
   value(s)

   (P'-2) Disrupting client traffic over a transport path, if the SPME
   is temporally configured.

   Problem (P'-1) is a fatal problem in terms of intrinsic monitoring.
   As shown in network objective (2), the monitoring function needs to
   monitor the status without changing any conditions of the targeted
   monitored segment or the transport path. If the conditions of the
   transport path change, the measured value or observed data will also
   change. This can 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.

Koike, et al.           Expires March 20, 2014                 [Page 7]
Internet-Draft        Temporal and hitless PSM            October 2013

   Figure 1 shows an example of SPME setting. In the figure, X means the
   one label 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, SPME changes 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 measurement
   and 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
    MEP     \                  /    MEP <= transport path
             --210--C--220--            <= SPME
            MEP'          MEP'

                  Figure 1 : An Example of a SPME setting

   Problem (P'-2) was not fully discussed, although the make-before-
   break procedure in the survivability document [4] seemingly supports
   the hitless configuration for monitoring according to the framework
   document [2]. The reality is the hitless configuration of 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 in MPLS shim header.

   Moreover, this 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 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

Koike, et al.           Expires March 20, 2014                 [Page 8]
Internet-Draft        Temporal and hitless PSM            October 2013

   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 transport networks.

   The 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., 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
   the perspective of monitoring in transport network operation, a
   solution avoiding those issues or minimizing their impact is required.
   Another monitoring mechanism is therefore required that supports
   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).

Koike, et al.           Expires March 20, 2014                 [Page 9]
Internet-Draft        Temporal and hitless PSM            October 2013

5. OAM functions using segment monitoring

   OAM functions in which on-demand HPSM is required are basically
   limited to on-demand monitoring which are defined in OAM framework
   document [5], because those segment monitoring functions are used to
   locate the fault/degraded point or to diagnose the status for
   detailed analyses, especially when a problem occurred. In other words,
   the characteristic of "on-demand" 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 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 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 to solve the
   problem. Therefore, on-demand HPSM for packet loss and packet delay
   measurements are indispensable for transport network operation.

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

   Regarding out-of-service on-demand monitoring functions, such as
   diagnostic tests, there seems no need for HPSM. However, specific
   segment monitoring should be applied to the OAM function of
   diagnostic test, because SPME doesn't meet network objective (2) 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 the issues (P-1)
     and (P-2) described in Section 4.

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

6. Further consideration of requirements for enhanced segment monitoring

Koike, et al.           Expires March 20, 2014                [Page 10]
Internet-Draft        Temporal and hitless PSM            October 2013

  6.1. Necessity of on-demand single-level monitoring

   The new segment monitoring function is supposed to be applied mainly
   for diagnostic purpose on-demand. 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 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 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 a laboratory does not seem to be necessary in
   the field. To summarize, on-demand and in-service (hitless) single-
   level segment monitoring is required, on-demand and in-service 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
      +-----------------------------+   <= End-to-end monitoring
            *------------------*        <= segment monitoring level1
              *-------------*           <= segment monitoring level2
                    *-*                 <= segment monitoring level3

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

  6.2. Necessity of on-demand monitoring independent from 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 necessity of simultaneous monitoring of end-to-end
   current proactive monitoring and new on-demand path segment
   monitoring. Normally, the on-demand path segment monitoring is
   configured in a segment of a maintenance entity of a transport path.
   In this environment, on-demand single-level monitoring should be done
   without disrupting pro-active monitoring of the targeted end-to-end
   transport path.

Koike, et al.           Expires March 20, 2014                [Page 11]
Internet-Draft        Temporal and hitless PSM            October 2013

   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 user traffic. This kind of
   inconvenience should be avoided in the network operations.

   Accordingly, the on-demand single lavel path segment monitoring is
   required without changing or interfering the proactive monitoring of
   the original end-to-end transport 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 segment monitoring

   The main objective of on-demand segment monitoring is to diagnose the
   fault points. One possible 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 and it is not possible
   to localize the fault point).

Koike, et al.           Expires March 20, 2014                [Page 12]
Internet-Draft        Temporal and hitless PSM            October 2013

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

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

   Accordingly, on-demand monitoring of arbitrary segments is mandatory
   in the case in Fig. 5. As a result, on-demand HSPM should be set in
   an arbitrary segment of a transport path and diagnostic packets
   should be inserted from 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 configured in
                            arbitrary segments

  6.4. Fault during HPSM in case of protection

   Node or link failures may occur during the HPSM is activated. In that
   case, the hitless path segment monitoring function should be
   suspended immediately and must not continue the monitoring on a new
   protected or restored path when a protection or restoration for the
   fault path is available. Therefore a solution of HPSM should avoid
   such a situation that a target node of the hitless segment monitoring
   is changed to unintended node when failures occur on the segment.

Koike, et al.           Expires March 20, 2014                [Page 13]
Internet-Draft        Temporal and hitless PSM            October 2013

    Fig.6 and Fig.7 exemplify one of the examples that should be avoided.
   However, this example is just for clarification of the problem that
   should be avoided. It does not intend to restrict any solution for
   meeting the requirements of HPSM. 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 is set
   between A and E. Therefore, considering the case that a fault happens
   between B and C, the HPSM doesn't continue in a protected path. As a
   result, there is no issue.

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

   Where:

   - working LSP: A-B-C-D-E-F
   - protection LSP: A-B-G-H-D-E-F
   - HPSM: A-E
   ---------------

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

   On the other hand, figure 7 shows a scenario where only a portion of
   a transport path has different label assignments (sub-paths). In this
   case, when a fault condition is identified on working sub-path B-C-D,
   the sub-path is switched to protection sub-path B-G-H-D. As a result,
   the target node of HPSM changes from E to D due to the difference of
   hop counts between a route of working path(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.

Koike, et al.           Expires March 20, 2014                [Page 14]
Internet-Draft        Temporal and hitless PSM            October 2013

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

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

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

  6.5. Consideration of maintenance point for HPSM

   An intermediate maintenance point supporting the HPSM has to be able
   to generate and inject OAM packets. Although maintenance points for
   the HPSM do not necessarily have to coincide with MIPs or MEPs in
   terms of the architecture definition, the same identifier for MIPs or
   MEPs could be applied to 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 [5].
   The enhancements should minimize the issues described in Section 4,
   i.e., P-1, P-2, P'-1( and P'-2), to meet those two network objectives.

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

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

   - 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 support several on-demand OAM functions, as follows:
   Mandatory: Packet Loss Measurement and Packet Delay Measurement

Koike, et al.           Expires March 20, 2014                [Page 15]
Internet-Draft        Temporal and hitless PSM            October 2013

   Optional: Connectivity Verification, Diagnostic Tests (Throughput
   test), and Route Tracing.

8. Security Considerations

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

9. IANA Considerations

   There are no IANA actions required by this draft.

10. References

  10.1. Normative References

   [1]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", RFC5860, May 2010

   [2]  Bocci, M., et al., "A Framework for MPLS in Transport Networks",
         RFC5921, July 2010

   [3]  Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
         January 2001

   [4]  Sprecher, N., Farrel, A. , "Multiprotocol Label Switching
         Transport Profile Survivability Framework", RFC6372, September
         2011

   [5]  Busi, I., Dave, A. , "Operations, Administration and
         Maintenance Framework for MPLS-based Transport Networks ",
         RFC6371, February 2011

  10.2. Informative References

   None

11. Acknowledgments

   The author would like to thank all members (including MPLS-TP
   steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
   in ITU-T) involved in the definition and specification of MPLS
   Transport Profile.

   The authors would also like to thank Alexander Vainshtein, Dave Allan,
   Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm

Koike, et al.           Expires March 20, 2014                [Page 16]
Internet-Draft        Temporal and hitless PSM            October 2013

   Betts, Nurit Sprecher and Jia He for their comments and enhancements
   to the text.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Alessandro D'Alessandro
   Telecom Italia
   Email: alessandro.dalessandro@telecomitalia.it

   Manuel Paul
   Deutsche Telekom
   Email:  Manuel.Paul@telekom.de

   Satoshi Ueno
   NTT Communications
   Email: satoshi.ueno@ntt.com

   Yoshinori Koike
   NTT
   Email: koike.yoshinori@lab.ntt.co.jp

Koike, et al.           Expires March 20, 2014                [Page 17]