draft-ietf-mpls-tp-temporal-hitless-psm-14.txt   rfc8256.txt 
Network Working Group A. D'Alessandro Internet Engineering Task Force (IETF) A. D'Alessandro
Internet-Draft Telecom Italia Request for Comments: 8256 Telecom Italia
Intended status: Informational L. Andersson Category: Informational L. Andersson
Expires: March 5, 2018 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
S. Ueno S. Ueno
NTT Communications NTT Communications
K. Arai K. Arai
Y. Koike Y. Koike
NTT NTT
September 1, 2017 October 2017
Requirements for hitless MPLS path segment monitoring Requirements for Hitless MPLS Path Segment Monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-14.txt
Abstract Abstract
One of the most important OAM capabilities for transport network One of the most important Operations, Administration, and Maintenance
operation is fault localisation. An in-service, on-demand segment (OAM) capabilities for transport-network operation is fault
monitoring function of a transport path is indispensable, localization. An in-service, on-demand path segment monitoring
particularly when the service monitoring function is activated only function of a transport path is indispensable, particularly when the
between end points. However, the current segment monitoring approach service monitoring function is activated only between endpoints.
defined for MPLS (including the transport profile (MPLS-TP)) in RFC However, the current segment monitoring approach defined for MPLS
6371 "Operations, Administration, and Maintenance Framework for MPLS- (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371
Based Transport Networks" has drawbacks. This document provides an "Operations, Administration, and Maintenance Framework for MPLS-Based
Transport Networks" has drawbacks. This document provides an
analysis of the existing MPLS-TP OAM mechanisms for the path segment analysis of the existing MPLS-TP OAM mechanisms for the path segment
monitoring and provides requirements to guide the development of new monitoring and provides requirements to guide the development of new
OAM tools to support a Hitless Path Segment Monitoring (HPSM). OAM tools to support Hitless Path Segment Monitoring (HPSM).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on March 5, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8256.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements for Hitless Path Segment Monitoring . . . . . . 7 4. Requirements for HPSM . . . . . . . . . . . . . . . . . . . . 8
4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7 4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 8
4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8 4.2. Non-Intrusive Segment Monitoring . . . . . . . . . . . . 8
4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8 4.3. Monitoring Multiple Segments . . . . . . . . . . . . . . 9
4.4. Single and multiple level monitoring . . . . . . . . . . 8 4.4. Monitoring Single and Multiple Levels . . . . . . . . . . 9
4.5. HPSM and end-to-end proactive monitoring independence . . 9 4.5. HPSM and End-to-End Proactive Monitoring Independence . . 10
4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 4.6. Monitoring an Arbitrary Segment . . . . . . . . . . . . . 10
4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11 4.7. Fault while HPSM Is Operational . . . . . . . . . . . . . 11
4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 13
4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13 4.9. Supported OAM Functions . . . . . . . . . . . . . . . . . 13
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], According to the MPLS-TP OAM requirements [RFC5860], mechanisms MUST
mechanisms MUST be available for alerting service providers of faults be available for alerting service providers of faults or defects that
or defects that affects their services. In addition, to ensure that affect their services. In addition, to ensure that faults or service
faults or service degradation can be localized, operators need a degradation can be localized, operators need a function to diagnose
function to diagnose the detected problem. Using end-to-end the detected problem. Using end-to-end monitoring for this purpose
monitoring for this purpose is insufficient in that an operator will is insufficient in that an operator will not be able to localize a
not be able to localize a fault or service degradation accurately. fault or service degradation accurately.
A segment monitoring function that can focus on a specific segment of A segment monitoring function that can focus on a specific segment of
a transport path and that can provide a detailed analysis is a transport path and that can provide a detailed analysis is
indispensable to promptly and accurately localize the fault. A path indispensable to promptly and accurately localize the fault. A
segment monitoring function has been defined to perform this task for function for monitoring path segments has been defined to perform
MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371 this task for MPLS-TP. However, as noted in the MPLS-TP OAM
[RFC6371], the current method for segment monitoring of a transport Framework [RFC6371], the current method for segment monitoring of a
path has implications that hinder the usage in an operator network. transport path has implications that hinder the usage in an operator
network.
This document, after elaborating on the problem statement for the After elaborating on the problem statement for the path segment
path segment monitoring function as it is currently defined, provides monitoring function as it is currently defined, this document
requirements for an on-demand segment monitoring function without provides requirements for an on-demand path segment monitoring
traffic distruption. Further works are required to evaluate how function without traffic disruption. Further works are required to
proposed requirements match with current MPLS architecture and to evaluate how proposed requirements match with current MPLS
identify possibile solutions. architecture and to identify possible solutions.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Terminology 2.1. Terminology
HPSM - Hitless Path Segment Monitoring HPSM - Hitless Path Segment Monitoring
LSP - Label Switched Path LSP - Label Switched Path
LSR - Label Switching Router LSR - Label Switching Router
ME - Maintenance Entity ME - Maintenance Entity
MEG - Maintenance Entity Group MEG - Maintenance Entity Group
MEP - Maintenance Entity Group End Point MEP - Maintenance Entity Group End Point
MIP - Maintenance Entity Group Intermediate Point MIP - Maintenance Entity Group Intermediate Point
OTN - Optical Transport Network OTN - Optical Transport Network
TCM - Tandem connection monitoring TCM - Tandem Connection Monitoring
SPME - Sub-path Maintenance Element SPME - Sub-Path Maintenance Element
3. Problem Statement 3. Problem Statement
To monitor (and to protect and/or manage) MPLS-TP network segments a A Sub-Path Maintenance Element (SPME) function to monitor (and to
Sub-Path Maintenance Element (SPME) function has been defined in RFC protect and/or manage) MPLS-TP network segments is defined in
5921 [RFC5921]. The SPME is defined between the edges of the segment [RFC5921]. The SPME is defined between the edges of the segment of a
of a transport path that needs to be monitored, protected, or transport path that needs to be monitored, protected, or managed.
managed. SPME is created by stacking the shim header (MPLS header) SPME is created by stacking the shim header (MPLS header), according
according to RFC 3031 [RFC3031] and it is defined as the segment to [RFC3031]; it is defined as the segment where the header is
where the header is stacked. OAM messages can be initiated at the stacked. OAM messages can be initiated at the edge of the SPME.
edge of the SPME and sent to the peer edge of the SPME or to a MIP They can be sent to the peer edge of the SPME or to a MIP along the
along the SPME by setting the TTL value of the label stack entry SPME by setting the TTL value of the Label Stack Entry (LSE) and
(LSE) and interface identifier value at the corresponding interface identifier value at the corresponding hierarchical LSP
hierarchical LSP level in case of a per-node model. level in case of a per-node model.
MPLS-TP segment monitoring should satisfy two network objectives According to Section 3.8 of [RFC6371], MPLS-TP segment monitoring
according to section 3.8 of RFC 6371 [RFC6371]: should satisfy two network objectives:
(N1) The monitoring and maintenance of current transport paths has (N1) The monitoring and maintenance of current transport paths has
to be conducted in-service without traffic disruption. to be conducted in-service without traffic disruption.
(N2) Segment monitoring must not modify the forwarding of the (N2) Segment monitoring must not modify the forwarding of the
segment portion of the transport path. segment portion of the transport path.
The SPME function that has been defined in RFC 5921 [RFC5921] has The SPME function that is defined in [RFC5921] has the following
the following drawbacks: drawbacks:
(P1) It increases network management complexity, because a new (P1) It increases network management complexity, because a new sub-
sublayer and new MEPs and MIPs have to be configured for the SPME. layer and new MEPs and MIPs have to be configured for the SPME.
(P2) Original conditions of the path change. (P2) Original conditions of the path change.
(P3) The client traffic over a transport path is disrupted if the (P3) The client traffic over a transport path is disrupted if the
SPME is configured on-demand. SPME is configured on-demand.
Problem (P1) is related to the management of each additional sub- Problem (P1) is related to the management of each additional sub-
layer required for segment monitoring in a MPLS-TP network. When an layer required for segment monitoring in an MPLS-TP network. When an
SPME is applied to administer on-demand OAM functions in MPLS-TP SPME is applied to administer on-demand OAM functions in MPLS-TP
networks, a rule for operationally differentiating those SPME will be networks, a rule for operationally differentiating those SPMEs will
required at least within an administrative domain. This forces be required at least within an administrative domain. This forces
operators to implement at least an additional layer into the operators to implement at least an additional layer into the
management systems that will only be used for on-demand path segment management systems that will only be used for on-demand path segment
monitoring. From the perspective of operation, increasing the number monitoring. From the perspective of operation, increasing the number
of managed layers and managed addresses/identifiers is not desirable of managed layers and managed addresses/identifiers is not desirable
in view of keeping the management systems as simple as possible. in view of keeping the management systems as simple as possible.
Moreover, using the currently defined methods, on-demand setting of Moreover, using the currently defined methods, on-demand setting of
SPMEs causes problems (P2) and (P3) due to additional label stacking. SPMEs causes problems (P2) and (P3) due to additional label stacking.
Problem (P2) arises from the fact that MPLS exposed label value and Problem (P2) arises because the MPLS-exposed label value and MPLS
MPLS frames length changes. The monitoring function should monitor frame length change. The monitoring function should monitor the
the status without changing any condition of the target, to be status without changing any condition of the target segment or of the
monitored, segment or transport path. Changing the settings of the target transport path. Changing the settings of the original shim
original shim header should not be allowed because this change header should not be allowed, because this change corresponds to
corresponds to creating a new segment of the original transport path creating a new segment of the original transport path that differs
that differs from the original one. When the conditions of the path from the original one. When the conditions of the path change, the
change, the measured values or observed data will also change and measured values or observed data will also change. This may make the
this may make the monitoring meaningless because the result of the monitoring meaningless because the result of the measurement would no
measurement would no longer reflect the performance of the connection longer reflect the performance of the connection where the original
where the original fault or degradation occurred. As an example, fault or degradation occurred. As an example, setting up an on-
setting up an on-demand SPME will result in the LSRs within the demand SPME will result in the LSRs within the monitoring segment
monitoring segment only looking at the added (stacked) labels and not only looking at the added (stacked) labels and not at the labels of
at the labels of the original LSP. This means that problems stemming the original LSP. This means that problems stemming from incorrect
from incorrect (or unexpected) treatment of labels of the original (or unexpected) treatment of labels of the original LSP by the nodes
LSP by the nodes within the monitored segment cannot be identified within the monitored segment cannot be identified when setting up
when setting up SPME. This might include hardware problems during SPME. This might include hardware problems during label lookup,
label look-up, mis-configuration, etc. Therefore operators have to misconfiguration, etc. Therefore, operators have to pay extra
pay extra attention to correctly setting and checking the label attention to correctly setting and checking the label values of the
values of the original LSP in the configuration. Of course, the original LSP in the configuration. Of course, the reverse of this
reverse of this situation is also possible, e.g., an incorrect or situation is also possible; for example, an incorrect or unexpected
unexpected treatment of SPME labels can result in false detection of treatment of SPME labels can result in false detection of a fault
a fault where no problem existed originally. where no problem existed originally.
Figure 1 shows an example of SPME settings. In the figure, "X" is 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 of node the label value of the original path expected at the tail end of node
D. "210" and "220" are label values allocated for SPME. The label 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 values of the original path are modified as are the values of the
stacked labels. As shown in Figure 1, SPME changes both the length stacked labels. As shown in Figure 1, SPME changes both the length
of MPLS frames and the label value(s). In particular, performance of MPLS frames and the label value(s). In particular, performance
monitoring measurements (e.g. Delay Measurement and Packet Loss monitoring measurements (e.g., Delay Measurement and Packet Loss
Measurement) are sensitive to these changes. As an example, Measurement) are sensitive to these changes. As an example,
increasing the packet lenght may impact on packet loss due to MTU increasing the packet length may impact packet loss due to MTU
settings, modifying the label stack may introduce packet loss or it settings; modifying the label stack may introduce packet loss, or it
may fix packet loss depending on the configuration status so may fix packet loss depending on the configuration status. Such
modifying network conditions. Such changes influence packets delay changes influence packet delay, too, even if, from a practical point
too even if, from a practical point of view, it is likely that only a of view, it is likely that only a few services will experience a
few services will experience a practical impact. practical impact.
(Before SPME settings) (Before SPME settings)
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
--- --- --- --- --- --- --- --- --- ---
A--100--B--110--C--120--D--130--E <= transport path A--100--B--110--C--120--D--130--E <= transport path
MEP MEP MEP MEP
(After SPME settings) (After SPME settings)
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
--- --- --- --- --- --- --- --- --- ---
A--100--B-----------X---D--130--E <= transport path A--100--B-----------X---D--130--E <= transport path
MEP MEP MEP MEP
210--C--220 <= SPME 210--C--220 <= SPME
MEP' MEP' MEP' MEP'
Figure 1: SPME settings example Figure 1: SPME Settings Example
Problem (P3) can be avoided if the operator sets SPMEs in advance and 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 this maintains them until the end of life of a transport path: but this
does not support on-demand. Furthermore SMPEs cannot be set does not support on-demand. Furthermore, SMPEs cannot be set
arbitrarily because overlapping of path segments is limited to arbitrarily because overlapping of path segments is limited to
nesting relationships. As a result, possible SPME configurations of nesting relationships. As a result, possible SPME configurations of
segments of an original transport path are limited due to the segments of an original transport path are limited due to the
characteristic of the SPME shown in Figure 1, even if SPMEs are pre- characteristic of the SPME shown in Figure 1, even if SPMEs are
configured. preconfigured.
Although the make-before-break procedure in the survivability Although the make-before-break procedure in the survivability
document RFC 6372 [RFC6372] supports configuration for monitoring document [RFC6372] supports configuration for monitoring according to
according to the framework document RFC 5921 [RFC5921], without the framework document [RFC5921], without traffic disruption the
traffic distruption, the configuration of an SPME is not possible configuration of an SPME is not possible without violating the
without violating network objective (N2). These concerns are network objective (N2). These concerns are described in Section 3.8
described in section 3.8 of RFC 6371 [RFC6371]. of [RFC6371].
Additionally, the make-before-break approach typically relies on a Additionally, the make-before-break approach typically relies on a
control plane and requires additional functionalities for a control plane and requires additional functionalities for a
management system to properly support SPME creation and traffic management system to properly support SPME creation and traffic
switching from the original transport path to the SPME. switching from the original transport path to the SPME.
As an example, the old and new transport resources (e.g. LSP As an example, the old and new transport resources (e.g., LSP
tunnels) might compete with each other for resources which they have tunnels) might compete with each other for resources that they have
in common. Depending on availability of resources, this competition in common. Depending on availability of resources, this competition
can cause admission control to prevent the new LSP tunnel from being can cause admission control to prevent the new LSP tunnel from being
established as this bandwidth accounting deviates from traditional established as this bandwidth accounting deviates from the
(non control plane) management system operation. While SPMEs can be traditional (non-control plane) management-system operation. While
applied in any network context (single domain, multi domain, single SPMEs can be applied in any network context (single-domain, multi-
carrier, multi carrier, etc.), the main applications are in inter- domain, single-carrier, multi-carrier, etc.), the main applications
carrier or inter-domain segment monitoring where they are typically are in inter-carrier or inter-domain segment monitoring where they
pre- configured or pre-instantiated. SPME instantiates a are typically preconfigured or pre-instantiated. SPME instantiates a
hierarchical path (introducing MPLS label stacking) through which OAM hierarchical path (introducing MPLS-label stacking) through which OAM
packets can be sent. The SPME monitoring function is also mainly packets can be sent. The SPME monitoring function is also mainly
important for protecting bundles of transport paths and carriers' important for protecting bundles of transport paths and the carriers'
carrier solutions within an administrative domain. carrier solutions within an administrative domain.
The analogy for SPME in other transport technologies is Tandem The analogy for SPME in other transport technologies is Tandem
Connection Monitoring (TCM), used in Optical Transport Networks (OTN) Connection Monitoring (TCM). TCM is used in Optical Transport
and Ethernet transport networks, which supports on-demand but does Networks (OTNs) and Ethernet transport networks. It supports on-
not affect the path. For example in OTN, TCM allows the insertion demand but does not affect the path. For example, in OTNs, TCM
and removal of performance monitoring overhead within the frame at allows the insertion and removal of performance monitoring overhead
intermediate points in the network. It is done such that their within the frame at intermediate points in the network. It is done
insertion and removal do not change the conditions of the path. such that their insertion and removal do not change the conditions of
Though as the OAM overhead is part of the frame (designated overhead the path. Though, as the OAM overhead is part of the frame
bytes), it is constrained to a pre-defined number of monitoring (designated overhead bytes), it is constrained to a predefined number
segments. of monitoring segments.
To summarize: the problem statement is that the current sub-path To summarize: the problem statement is that the current sub-path
maintenance based on a hierarchical LSP (SPME) is problematic for maintenance based on a hierarchical LSP (SPME) is problematic for
pre-configuration in terms of increasing the number of managed preconfiguration in terms of increasing the number of managed objects
objects by layer stacking and identifiers/addresses. An on-demand by layer stacking and identifiers/addresses. An on-demand
configuration of SPME is one of the possible approaches for configuration of SPME is one of the possible approaches for
minimizing the impact of these issues. However, the current minimizing the impact of these issues. However, the current
procedure is unfavourable because the on-demand configuration for procedure is unfavorable because the on-demand configuration for
monitoring changes the condition of the original monitored path. To monitoring changes the condition of the original monitored path. To
avoid or minimize the impact of the drawbacks discussed above, a more avoid or minimize the impact of the drawbacks discussed above, a more
efficient approach is required for the operation of an MPLS-TP efficient approach is required for the operation of an MPLS-TP
transport network. A monitoring mechanism, named Hitless Path transport network. A monitoring mechanism, named "Hitless Path
Segment Monitoring (HPSM), supporting on-demand path segment Segment Monitoring" (HPSM), supporting on-demand path segment
monitoring without traffic disruption is needed. monitoring without traffic disruption is needed.
4. Requirements for Hitless Path Segment Monitoring 4. Requirements for HPSM
In the following sections, mandatory (M) and optional (O) In the following sections, mandatory (M) and optional (O)
requirements for the Hitless Path Segment Monitoring function are requirements for the HPSM function are listed.
listed.
4.1. Backward compatibility 4.1. Backward Compatibility
HPSM would be an additional OAM tool that would not replace SPME. As HPSM would be an additional OAM tool that would not replace SPME. As
such: such:
(M1) HPSM MUST be compatible with the usage of SPME (M1) HPSM MUST be compatible with the usage of SPME.
(O1) HPSM SHOULD be applicable at the SPME layer too (O1) HPSM SHOULD be applicable at the SPME layer 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 (M2) HPSM MUST support both the per-node and per-interface model as
specified in [RFC6371].
One of the major problems of legacy SPME highlighted in section 3 is 4.2. Non-Intrusive Segment Monitoring
One of the major problems of legacy SPME highlighted in Section 3 is
that it may not monitor the original path and it could disrupt that it may not monitor the original path and it could disrupt
service traffic when set-up on demand. service traffic when set up on demand.
(M3) HPSM MUST NOT change the original conditions of transport (M3) HPSM MUST NOT change the original conditions of the transport
path (e.g. must not change the length of MPLS frames, the exposed path (e.g., the length of MPLS frames, the exposed label
label values, etc.) values, etc.).
(M4) HPSM MUST support on-demand provisioning without traffic (M4) HPSM MUST support on-demand provisioning without traffic
disruption. disruption.
4.3. Multiple segments monitoring 4.3. Monitoring Multiple Segments
Along a transport path there may be the need to support Along a transport path, there may be the need to support monitoring
simultaneously monitoring multiple segments multiple segments simultaneously.
(M5) HPSM MUST support configuration of multiple monitoring (M5) HPSM MUST support configuration of multiple monitoring segments
segments along a transport path. along a transport path.
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
*------* *----* *--------------* <=three HPSM monit. instances *------* *----* *--------------* <=three HPSM monit. instances
Figure 2: Multiple HPSM instances example Figure 2: Multiple HPSM Instances Example
4.4. Single and multiple level monitoring 4.4. Monitoring Single and Multiple Levels
HPSM would apply mainly for on-demand diagnostic purposes. With the HPSM would apply mainly for on-demand diagnostic purposes. With the
currently defined approach, the most serious problem is that there is currently defined approach, the most serious problem is that there is
no way to locate the degraded segment of a path without changing the no way to locate the degraded segment of a path without changing the
conditions of the original path. Therefore, as a first step, a conditions of the original path. Therefore, as a first step, a
single level, single segment monitoring, not affecting the monitored single-level, single-segment monitoring not affecting the monitored
path, is required for HPSM. A combination of multi-level and path is required for HPSM. Monitoring simultaneous segments on
simultaneous segments monitoring is the most powerful tool for multiple levels is the most powerful tool for accurately diagnosing
accurately diagnosing the performance of a transport path. However, the performance of a transport path. However, in the field, a
in the field, a single level, multiple segments approach would be single-level, multiple-segment approach would be less complex for
less complex for management and operations. management and operations.
(M6) HPSM MUST support single-level segment monitoring
(O2) HPSM MAY support multi-level segment monitoring. (M6) HPSM MUST support single-level segment monitoring.
Figure 3 shows an example of multi-level HPSM. (O2) HPSM MAY support multi-level segment monitoring.
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
*-----------------* <=On-demand HPSM level 1 *-----------------* <=On-demand HPSM level 1
*-------------* <=On-demand HPSM level 2 *-------------* <=On-demand HPSM level 2
*-* <=On-demand HPSM level 3 *-* <=On-demand HPSM level 3
Figure 3: Multi-level HPSM example Figure 3: Multi-Level HPSM Example
4.5. HPSM and end-to-end proactive monitoring independence 4.5. HPSM and End-to-End Proactive Monitoring Independence
There is a need for simultaneously using existing end-to-end There is a need for simultaneously using existing end-to-end
proactive monitoring and on-demand path segment monitoring. proactive monitoring and on-demand path segment monitoring.
Normally, the on-demand path segment monitoring is configured on a Normally, the on-demand path segment monitoring is configured on a
segment of a maintenance entity of a transport path. In such an segment of a maintenance entity of a transport path. In such an
environment, on-demand single-level monitoring should be performed environment, on-demand single-level monitoring should be performed
without disrupting the pro-active monitoring of the targeted end-to- without disrupting the proactive monitoring of the targeted end-to-
end transport path to avoid affecting user traffic performance end transport path to avoid affecting monitoring of user traffic
monitoring. performance.
(M7) HPSM MUST support the capability of being operated (M7) HPSM MUST support the capability of being operated concurrently
concurrently to, and independently of OAM function operated on the to, and independently of, the OAM function on the end-to-end
end-to-end path path.
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
+-----------------------------+ <= Pro-active end-to-end mon. +-----------------------------+ <= Proactive end-to-end mon.
*------------------* <= On-demand HPSM *------------------* <= On-demand HPSM
Figure 4: Independence between proactive end-to-end monitoring and Figure 4: Independence between Proactive End-to-End Monitoring and
on-demand HPSM On-Demand HPSM
4.6. Arbitrary segment monitoring 4.6. Monitoring an Arbitrary Segment
The main objective for on-demand segment monitoring is to diagnose The main objective for on-demand path segment monitoring is to
the fault locations. A possible realistic diagnostic procedure is to diagnose the fault locations. A possible realistic diagnostic
fix one end point of a segment at the MEP of the transport path under procedure is to fix one endpoint of a segment at the MEP of the
observation and change progressively the length of the segments. It transport path under observation and progressively change the length
is therefore possible to monitoring step by step all the path with a of the segments. It is, therefore, possible to monitor all the
granularity that depends on equipment implementations. For example, paths, step-by-step, with a granularity that depends on equipment
Figure 5 shows the case where the granularity is at interface level implementations. For example, Figure 5 shows the case where the
(i.e. monitoring is at each input interface and output interface of granularity is at the interface level (i.e., monitoring is at each
each piece of equipment). input interface and output interface of each piece of equipment).
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
+-----------------------------+ <= Pro-active end-to-end mon. +-----------------------------+ <= Proactive end-to-end mon.
*-----* <= 1st on-demand HPSM *-----* <= 1st on-demand HPSM
*-------* <= 2nd on-demand HPSM *-------* <= 2nd on-demand HPSM
| | | |
| | | |
*-----------------------* <= 4th on-demand HPSM *-----------------------* <= 4th on-demand HPSM
*-----------------------------* <= 5th on-demand HPSM *-----------------------------* <= 5th on-demand HPSM
Figure 5: Localization of a defect by consecutive on-demand segment Figure 5: Localization of a Defect by Consecutive On-Demand Path
monitoring procedure Segment Monitoring Procedure
Another possible scenario is depicted in Figure 6. In this case, the Another possible scenario is depicted in Figure 6. In this case, the
operator wants to diagnose a transport path starting at a transit operator wants to diagnose a transport path starting at a transit
node, because the end nodes (A and E) are located at customer sites 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. and consist of small boxes supporting only a subset of OAM functions.
In this case, where the source entities of the diagnostic packets are In this case, where the source entities of the diagnostic packets are
limited to the position of MEPs, on-demand segment monitoring will be limited to the position of MEPs, on-demand path segment monitoring
ineffective because not all the segments can be diagnosed (e.g. will be ineffective because not all the segments can be diagnosed
segment monitoring HPSM 3 in Figure 6 is not available and it is not (e.g., segment monitoring HPSM 3 in Figure 6 is not available, and it
possible to determine the fault location exactly). is not possible to determine the fault location exactly).
(M8) It SHALL be possible to provision HPSM on an arbitrary (M8) It SHALL be possible to provision HPSM on an arbitrary segment
segment of a transport path. of a transport path.
--- --- --- --- --- ---
--- | | | | | | --- --- | | | | | | ---
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
+-----------------------------+ <= Pro-active end-to-end mon. +-----------------------------+ <= Proactive end-to-end mon.
*-----* <= On-demand HPSM 1 *-----* <= On-demand HPSM 1
*-----------------------* <= On-demand HPSM 2 *-----------------------* <= On-demand HPSM 2
*---------* <= On-demand HPSM 3 *---------* <= On-demand HPSM 3
Figure 6: HPSM configuration at arbitrary segments Figure 6: HPSM Configuration at Arbitrary Segments
4.7. Fault while HPSM is operational 4.7. Fault while HPSM Is Operational
Node or link failures may occur while HPSM is active. In this case, Node or link failures may occur while HPSM is active. In this case,
if no resiliency mechanism is set-up on the subtended transport path, if no resiliency mechanism is set up on the subtended transport path,
there is no particular requirement for HPSM. If the transport path there is no particular requirement for HPSM. If the transport path
is protected, the HPSM function may bring to monitoring unintended is protected, the HPSM function may monitor unintended segments. The
segments. The following examples are provided for clarification. following examples are provided for clarification.
Protection scenario A is shown in figure 7. In this scenario a Protection scenario A is shown in Figure 7. In this scenario, a
working LSP and a protection LSP are set-up. HPSM is activated working LSP and a protection LSP are set up. HPSM is activated
between nodes A and E. When a fault occurs between nodes B and C, 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 the operation of HPSM is not affected by the protection switch and
continues on the active LSP path. continues on the active LSP.
A - B - C - D - E - F A - B - C - D - E - F
\ / \ /
G - H - I - L G - H - I - L
Where: Where:
- end-to-end LSP: A-B-C-D-E-F - end-to-end LSP: A-B-C-D-E-F
- working LSP: A-B-C-D-E-F - working LSP: A-B-C-D-E-F
- protection LSP: A-G-H-I-L-F - protection LSP: A-G-H-I-L-F
- HPSM: A-E - HPSM: A-E
Figure 7: Protection scenario A Figure 7: Protection Scenario A
Protection scenario B is shown in figure 8. The difference with Protection scenario B is shown in Figure 8. The difference with
scenario A is that only a portion of the transport path is protected. 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 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- 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 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 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 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 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 the operation of HPSM is (A-B-G-H-D-E: 5 hops). In this case, the operation of HPSM is
affected. affected.
A - B - C - D - E - F A - B - C - D - E - F
\ / \ /
G - H G - H
- end-to-end LSP: A-B-C-D-E-F - end-to-end LSP: A-B-C-D-E-F
- working sub-path: B-C-D - working sub-path: B-C-D
- protection sub-path: B-G-H-D - protection sub-path: B-G-H-D
- HPSM: A-E - HPSM: A-E
Figure 8: Protection scenario B Figure 8: Protection Scenario B
(M9) The HPSM SHOULD avoid monitoring an unintended segment when (M9) The HPSM SHOULD avoid monitoring an unintended segment when one
one or more failures occur or more failures occur.
There are potentially different solutions to satisfy such a There are potentially different solutions to satisfy such a
requirement. A possible solution may be to suspend HPSM monitoring requirement. A possible solution may be to suspend HPSM monitoring
until network restoration takes place. Another possible approach may until network restoration takes place. Another possible approach may
be to compare the node/interface ID in the OAM packet with that at be to compare the node/interface ID in the OAM packet with that at
the node reached at TTL termination and if this does not match the node reached at TTL termination and, if this does not match, a
through some means trigger a suspension of HPSM monitoring. The suspension of HPSM monitoring should be triggered. The above
above approaches are valid in any circumstance, both for protected approaches are valid in any circumstance, both for protected and
and unprotected networks LSPs. These examples should not be taken to unprotected networks LSPs. These examples should not be taken to
limit the design of a solution. limit the design of a solution.
4.8. HPSM Manageability 4.8. HPSM Manageability
From managing perspective, increasing the number of managed layers From a managing perspective, increasing the number of managed layers
and managed addresses/identifiers is not desirable in view of keeping and managed addresses/identifiers is not desirable in view of keeping
the management systems as simple as possible. the management systems as simple as possible.
(M10)HPSM SHOULD NOT be based on additional transport layers (e.g. (M10) HPSM SHOULD NOT be based on additional transport layers (e.g.,
hierarchical LSPs) hierarchical LSPs).
(M11) The same identifiers used for MIPs and/or MEPs SHOULD be (M11) The same identifiers used for MIPs and/or MEPs SHOULD be
applied to maintenance points for the HPSM when they are applied to maintenance points for the HPSM when they are
instantiated in the same place along a transport path. instantiated in the same place along a transport path.
Anyway maintenance points for the HPSM may be different from MIPs Maintenance points for the HPSM may be different from the
and MEPs functional components as defined in the OAM framework functional components of MIPs and MEPs as defined in the OAM
document RFC 6371 [RFC6371]. Investigating potential solutions framework document [RFC6371]. Investigating potential
for satisfying proposed HPSM requirements might lead to propose solutions for satisfying HPSM requirements may lead to
new functional components that have to be backward compatible with identifying new functional components; these components need to
MPLS architecture. Solutions are outside the scope of this be backward compatible with MPLS architecture. Solutions are
document. outside the scope of this document.
4.9. Supported OAM functions 4.9. Supported OAM Functions
A maintenance point supporting the HPSM function has to be able to A maintenance point supporting the HPSM function has to be able to
generate and inject OAM packets. OAM functions that may be generate and inject OAM packets. OAM functions that may be
applicable for on-demand HPSM are basically the on-demand performance applicable for on-demand HPSM are basically the on-demand performance
monitoring functions which are defined in the OAM framework document monitoring functions that are defined in the OAM framework document
RFC 6371 [RFC6371]. The "on-demand" attribute is typically temporary [RFC6371]. The "on-demand" attribute is typically temporary for
for maintenance operation. maintenance operation.
(M12) HPSM MUST support Packet Loss and Packet Delay measurement. (M12) HPSM MUST support Packet Loss and Packet Delay measurement.
That because these functions are normally only supported at the end These functions are normally only supported at the endpoints of a
points of a transport path. If a defect occurs, it might be quite transport path. If a defect occurs, it might be quite hard to locate
hard to locate the defect or degradation point without using the the defect or degradation point without using the segment monitoring
segment monitoring function. If an operator cannot locate or narrow function. If an operator cannot locate or narrow down the cause of
down the cause of the fault, it is quite difficult to take prompt the fault, it is quite difficult to take prompt actions to solve the
actions to solve the problem. problem.
Other on-demand monitoring functions (e.g. Delay Variation Other on-demand monitoring functions (e.g., Delay Variation
measurement) are desirable but not as necessary as the functions measurement) are desirable but not as necessary as the functions
mentioned above. mentioned above.
(O3) HPSM MAY support Packet Delay variation, Throughput (O3) HPSM MAY support Packet Delay variation, Throughput
measurement and other performance monitoring and fault management measurement, and other performance monitoring and fault
functions. management functions.
Support of out-of-service on-demand performance management functions Support of out-of-service on-demand performance-management functions
(e.g. Throughput measurement) is not required for HPSM. (e.g., Throughput measurement) is not required for HPSM.
5. Summary 5. Summary
A new hitless path segment monitoring (HPSM) mechanism is required to A new HPSM mechanism is required to provide on-demand path segment
provide on-demand segment monitoring without traffic disruption. It monitoring without traffic disruption. It shall meet the two network
shall meet the two network objectives described in section 3.8 of RFC objectives described in Section 3.8 of [RFC6371] and summarized in
6371 [RFC6371] and summarized in Section 3 of this document. Section 3 of this document.
The mechanism should minimize the problems described in Section 3, The mechanism should minimize the problems described in Section 3,
i.e. (P1), (P2) and (P3). i.e., (P1), (P2), and (P3).
The solution for the on-demand segment monitoring without traffic The solution for the on-demand path segment monitoring without
disruption needs to cover both the per-node model and the per- traffic disruption needs to cover both the per-node model and the
interface model specified in RFC 6371 [RFC6371]. per-interface model specified in [RFC6371].
The on-demand segment monitoring without traffic disruption solution The on-demand path segment monitoring without traffic disruption
needs to support on-demand Packet Loss Measurement and Packet Delay solution needs to support on-demand Packet Loss Measurement and
Measurement functions and optionally other performance monitoring and Packet Delay Measurement functions and optionally other performance
fault management functions (e.g. Throughput measurement, Packet monitoring and fault management functions (e.g., Throughput
Delay variation measurement, Diagnostic test, etc.). measurement, Packet Delay variation measurement, Diagnostic test,
etc.).
6. Security Considerations 6. Security Considerations
Security is a significant requirement of MPLS Transport Profile. The Security is a significant requirement of the MPLS Transport Profile.
document provides a problem statement and requirements to guide the This document provides a problem statement and requirements to guide
development of new OAM tools to support Hitless Path Segment the development of new OAM tools to support HPSM. Such new tools
Monitoring. Such new tools must follow the security considerations must follow the security considerations provided in OAM Requirements
provided in OAM Requirements for MPLS-TP in RFC5860 [RFC5860]. for MPLS-TP in [RFC5860].
7. IANA Considerations 7. IANA Considerations
There are no requests for IANA actions in this document. This document does not require any IANA actions.
Note to the RFC Editor - this section can be removed before
publication.
8. 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 and Nurit Sprecher for their comments and
enhancements to the text.
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, <https://www.rfc- DOI 10.17487/RFC3031, January 2001,
editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and "Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860, Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010, <https://www.rfc- DOI 10.17487/RFC5860, May 2010,
editor.org/info/rfc5860>. <https://www.rfc-editor.org/info/rfc5860>.
10.2. Informative References [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, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>. <https://www.rfc-editor.org/info/rfc5921>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371, Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <https://www.rfc-editor.org/info/rfc6371>. September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372, Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011, <https://www.rfc- DOI 10.17487/RFC6372, September 2011,
editor.org/info/rfc6372>. <https://www.rfc-editor.org/info/rfc6372>.
Contributors
Manuel Paul
Deutsche Telekom AG
Email: manuel.paul@telekom.de
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, and Nurit Sprecher for their comments and
enhancements to the text.
Authors' Addresses Authors' Addresses
Alessandro D'Alessandro Alessandro D'Alessandro
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: alessandro.dalessandro@telecomitalia.it Email: alessandro.dalessandro@telecomitalia.it
Loa Andersson Loa Andersson
Huawei Technologies Huawei Technologies
Email: loa@mail01.huawei.com Email: loa@pi.nu
Satoshi Ueno Satoshi Ueno
NTT Communications NTT Communications
Email: satoshi.ueno@ntt.com Email: ueno@nttv6.jp
Kaoru Arai Kaoru Arai
NTT NTT
Email: arai.kaoru@lab.ntt.co.jp Email: arai.kaoru@lab.ntt.co.jp
Yoshinori Koike Yoshinori Koike
NTT NTT
Email: y.koike@vcd.nttbiz.com Email: y.koike@vcd.nttbiz.com
 End of changes. 115 change blocks. 
328 lines changed or deleted 330 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/