draft-ietf-mpls-tp-temporal-hitless-psm-09.txt   draft-ietf-mpls-tp-temporal-hitless-psm-10.txt 
Network Working Group A. D'Alessandro Network Working Group A. D'Alessandro
Internet-Draft Telecom Italia Internet-Draft Telecom Italia
Intended status: Standards Track L. Andersson Intended status: Informational L. Andersson
Expires: June 20, 2016 Huawei Technologies Expires: December 2, 2016 Huawei Technologies
M. Paul
Deutsche Telekom
S. Ueno S. Ueno
NTT Communications NTT Communications
K. Arai K. Arai
Y. Koike Y. Koike
NTT NTT
December 18, 2015 May 31, 2016
Enhanced path segment monitoring Hitless path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-09.txt draft-ietf-mpls-tp-temporal-hitless-psm-10.txt
Abstract Abstract
The MPLS transport profile (MPLS-TP) has been standardized to enable One of the most important OAM capabilities for transport network
carrier-grade packet transport and to complement converged packet operation is fault localisation. An in-service, on-demand segment
network deployments. The most attractive features of MPLS-TP are the monitoring function of a transport path is indispensable,
OAM functions. These functions enable maintenance tools that may be particularly when the service monitoring function is activated only
exploited by network operators and service providers for fault between end points. However, the current segment monitoring approach
location, survivability, performance monitoring, in-service and out- defined for MPLS RFC 6371 [RFC6371] has drawbacks. This document
of-service measurements. provides an analysis of the existing MPLS-TP OAM mechanisms for the
path segment monitoring and provides requirements to guide the
One of the most important mechanisms that is common for transport development of new OAM tools to support a Hitless Path Segment
network operation is fault localisation. A segment monitoring Monitoring (HPSM).
function of a transport path is effective in terms of extension of
the maintenance work and indispensable, particularly when the OAM
function is activated only between end points. However, the current
approach defined for MPLS-TP of segment monitoring has some
drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provide monitoring of a
segment of a set of transport paths (LSPs or MS-PWs). Based on the
identified problems, this document provides considerations for the
specification of new requirements to consider a new improved
mechanism for hitless transport path segment monitoring to be named
Enhanced Path Segment Monitoring (EPSM).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 20, 2016. This Internet-Draft will expire on December 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network objectives for segment monitoring . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements for hitless segment monitoring . . . . . . . . . 7
5. OAM functions supported in segment monitoring . . . . . . . . 8 4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7
6. Requirements for enhanced segment monitoring . . . . . . . . 9 4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8
6.1. Non-intrusive segment monitoring . . . . . . . . . . . . 9 4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8
6.2. Single and multiple level monitoring . . . . . . . . . . 9 4.4. Single and multiple level monitoring . . . . . . . . . . 8
6.3. EPSM and end-to-end proactive monitoring independence . . 10 4.5. HPSM and end-to-end proactive monitoring independence . . 9
6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 11 4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10
6.5. Fault while EPSM is operational . . . . . . . . . . . . . 12 4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11
6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
A packet transport network enables carriers and service providers to
use network resources efficiently. It reduces operational complexity
and provides carrier-grade network operation. Appropriate
maintenance functions that support fault location, survivability,
pro-active performance monitoring, pre-service and in-service
measurements, are essential to ensure the quality of service and the
reliability of a network. They are essential in transport networks
and have evolved along with PDH, ATM, SDH and OTN.
Similar to legacy technologies, MPLS-TP also does not scale when an
arbitrary number of OAM functions is enabled.
According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], According to the MPLS-TP OAM requirements RFC 5860 [RFC5860],
mechanisms MUST be available for alerting a service provider of a mechanisms MUST be available for alerting service providers of faults
fault or defect that affects their services. In addition, to ensure or defects that affects their services. In addition, to ensure that
that faults or service degradation can be localized, operators need a faults or service degradation can be localized, operators need a
function to diagnose the detected problem. Using end-to-end function to diagnose the detected problem. Using end-to-end
monitoring for this purpose is insufficient. In fact by using end- monitoring for this purpose is insufficient in that an operator will
to-end OAM monitoring, 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.
Thus, a dedicated segment monitoring function that can focus on a
specific segment of a transport path and can provide a detailed
analysis is indispensable to promptly and accurately localize the
fault.
For MPLS-TP, a path segment monitoring function has been defined to Thus, a segment monitoring function that can focus on a specific
segment of a transport path and can provide a detailed analysis is
indispensable to promptly and accurately localize the fault. For
MPLS-TP, a path segment monitoring function has been defined to
perform this task. However, as noted in the MPLS-TP OAM Framework perform this task. However, as noted in the MPLS-TP OAM Framework
RFC 6371 [RFC6371], the current method for segment monitoring of a RFC 6371 [RFC6371], the current method for segment monitoring of a
transport path has implications that hinder the usage in an operator transport path has implications that hinder the usage in an operator
network. network.
This document elaborates on the problem statement for the path This document, after elaborating on the problem statement for the
segment monitoring function and proposes to consider a new improved path segment monitoring function as it is currently defined, provides
method for segment monitoring, following up the description in RFC requirements for an on-demand segment monitoring function without
6371 [RFC6371]. This document also provides additional detailed traffic distruption.
requirements for a new temporary and hitless segment monitoring
function which is not covered in RFC 6371 [RFC6371].
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.1. Terminology 2.1. Terminology
ATM - Asynchronous Transfer Mode ATM - Asynchronous Transfer Mode
EPSM - Enhanced 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
PDH - Plesiochronous Digital Hierarchy
PST - Path Segment Tunnel
TCM - Tandem connection monitoring TCM - Tandem connection monitoring
SDH - Synchronous Digital Hierarchy
SPME - Sub-path Maintenance Element SPME - Sub-path Maintenance Element
2.2. Definitions 2.2. Definitions
None. None.
3. Network objectives for segment monitoring 3. Problem Statement
There are two network objectives for MPLS-TP segment monitoring
described in section 3.8 of RFC 6371 [RFC6371]:
1. The monitoring and maintenance of current transport paths has to
be conducted in-service without traffic disruption.
2. Segment monitoring must not modify the forwarding of the segment To monitor (and to protect and/or manage) MPLS-TP network segments a
portion of the transport path. Sub-Path Maintenance Element (SPME) function has been defined in RFC
5921 [RFC5921]. The SPME is defined between the edges of the segment
of a transport path that needs to be monitored, protected, or
managed. SPME is created by stacking the shim header (MPLS header)
according to RFC 3031 [RFC3031] and it is defined as the segment
where the header is stacked. OAM messages can be initiated at the
edge of the SPME and sent to the peer edge of the SPME or to a MIP
along the SPME by setting the TTL value of the label stack entry
(LSE) and interface identifier value at the corresponding
hierarchical LSP level in case of a per-node model.
4. Problem Statement MPLS-TP segment monitoring must satisfy two network objectives
according to section 3.8 of RFC 6371 [RFC6371]:
The Sub-Path Maintenance Element (SPME) function is defined in RFC (N1) The monitoring and maintenance of current transport paths has
5921 [RFC5921]. It is used to monitor, protect, and/or manage to be conducted in-service without traffic disruption.
segments of transport paths, such as LSPs in MPLS-TP networks. The
SPME is defined between the edges of the segment of a transport path
that needs to be monitored, protected, or managed. This SPME is
created by stacking the shim header (MPLS header) according to RFC
3031 [RFC3031] and is defined as the segment where the header is
stacked. OAM messages can be initiated at the edge of the SPME and
sent to the peer edge of the SPME or to a MIP along the SPME by
setting the TTL value of the label stack entry (LSE) and interface
identifier value at the corresponding hierarchical LSP level in case
of a per-node model.
This method has the following drawbacks that impact the operation (N2) Segment monitoring must not modify the forwarding of the
costs: segment portion of the transport path.
(P-1) It lowers the bandwidth efficiency. The SPME function that has been defined in RFC 5921 [RFC5921] has
the following drawbacks:
(P-2) It increases network management complexity, because a new (P1) It increases network management complexity, because a new
sublayer and new MEPs and MIPs have to be configured for the SPME. sublayer and new MEPs and MIPs have to be configured for the SPME.
Problem (P-1) is caused by the shim headers stacking that increases (P2) Original conditions of the path are changed.
the overhead.
Problem (P-2) is related to an identifier management issue. In the
case of label stacking the identification of each sub-layer is
required for segment monitoring in a MPLS-TP network. When SPME is
applied for on-demand OAM functions in MPLS-TP networks in a similar
manner as Tandem Connection Monitoring (TCM) in the Optical Transport
Networks (OTN) and Ethernet transport networks, a rule for
operationally differentiating those SPME/TCMs will be required; at
least within an administrative domain. This forces operators to
create an additional permanent layer identification policy that will
only be used for temporary path segment monitoring. Additionally,
from the perspective of operation, increasing the number of managed
addresses and managed layers is not desirable in view of keeping the
transport networks as simple as possible. Reducing the number of
managed identifiers and managed sub-layers should be the fundamental
objective in designing the architecture.
The analogy for SPME in legacy transport networks is TCM, which is
on-demand and does not affect the transport path.
Also, using the currently defined methods, temporary setting of SPMEs (P3) The client traffic over a transport path is disrupted if the
causes the following problems due to additional label stacking: SPME is configured on-demand.
(P-3) The original condition of the transport path is affected by Problem (P1) is related to the management of each additional sub-
changing the length of MPLS frames and changing the value of layer required for segment monitoring in a MPLS-TP network. When an
exposed label. SPME is applied to administer on-demand OAM functions in MPLS-TP
networks, a rule for operationally differentiating those SPME will be
required at least within an administrative domain. This forces
operators to implement at least an additional layer into the
management systems that will only be used for on-demand path segment
monitoring. From the perspective of operation, increasing the number
of managed layers and managed addresses/identifiers is not desirable
in view of keeping the management systems as simple as possible.
(P-4) The client traffic over a transport path is disrupted when Moreover, using the currently defined methods, on-demand setting of
the SPME is configured on-demand. SPMEs causes problems (P2) and (P3) due to additional label stacking.
Problem (P-3) impacts network objective (2) in Section 3. The Problem (P2) arises from the fact that MPLS exposed label value and
monitoring function should monitor the status without changing any MPLS frames length changes. The monitoring function should monitor
conditions of the targeted, to be monitored, segment or transport the status without changing any conditions of the targeted, to be
path. Changing the settings of the original shim header should not monitored, segment or transport path. Changing the settings of the
be allowed because this change corresponds to creating a new segment original shim header should not be allowed because this change
of the original transport path. And this differs from the original corresponds to creating a new segment of the original transport path
data plane conditions. When the conditions of the transport path that differs from the original one. When the conditions of the path
change, the measured values or observed data will also change and change, the measured values or observed data will also change and
this may make the monitoring meaningless because the result of the this may make the monitoring meaningless because the result of the
measurement would no longer reflect the performance of the connection measurement would no longer reflect the performance of the connection
where the original fault or degradation occurred. where the original fault or degradation occurred. As an example,
setting up an on-demand SPME will result in the LSRs within the
monitoring segment only looking at the added (stacked) labels and not
at the labels of the original LSP. This means that problems stemming
from incorrect (or unexpected) treatment of labels of the original
LSP by the nodes within the monitored segment cannot be identified
when setting up SPME. This might include hardware problems during
label look-up, mis-configuration, 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
reverse of this situation is also possible, e.g., an incorrect or
unexpected treatment of SPME labels can result in false detection of
a fault where 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 transport path expected at the tail- the label value of the original path expected at the tail-end of node
end of node D. "210" and "220" are label values allocated for SPME. D. "210" and "220" are label values allocated for SPME. The label
The label values of the original path are modified as well as the values of the original path are modified as well as the values of the
values of the stacked labels. As shown in Figure 1, SPME changes stacked labels. As shown in Figure 1, SPME changes both the length
both the length of MPLS frames and the label value(s). This means of MPLS frames and the label value(s). This means that it is no
that it is no longer monitoring the original transport path but it is longer monitoring the original path but it is monitoring a different
monitoring a different path. In particular, performance monitoring path. In particular, performance monitoring measurements (e.g.
measurements (e.g. Delay Measurement and Packet Loss Measurement) Delay Measurement and Packet Loss Measurement) are sensitive to these
are sensitive to these changes. changes.
(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: An Example of a SPME settings Figure 1: SPME settings example
Problem (P-4) can be avoided if the operator sets SPMEs in advance Problem (P3) can be avoided if the operator sets SPMEs in advance and
and maintains it until the end of life of a transport path, which is maintains them until the end of life of a transport path. But this
neither temporary nor 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 SPME shown in Figure 1, even if SPMEs are pre- characteristic of the SPME shown in Figure 1, even if SPMEs are pre-
configured. configured.
Although the make-before-break procedure in the survivability Although the make-before-break procedure in the survivability
document RFC 6372 [RFC6372] seemingly supports the hitless document RFC 6372 [RFC6372] supports configuration for monitoring
configuration for monitoring according to the framework document RFC according to the framework document RFC 5921 [RFC5921], without
5921 [RFC5921], the reality is that configuration of an SPME is traffic distruption, the configuration of an SPME is not possible
impossible without violating network objective (2) in Section 3. without violating network objective (N2). These concerns are
These concerns are described in section 3.8 of RFC 6371 [RFC6371]. described in section 3.8 of RFC 6371 [RFC6371].
Additionally, the make-before-break approach might not be usable in
the static model without a control plane. This is because the make-
before-break is a restoration function based on a control plane.
Consequently the management systems should support SPME creation and
coordinated traffic switching from original transport path to the
SPME.
Other potential risks are also envisaged. Setting up a temporary Additionally, the make-before-break approach tipically relies on a
SPME will result in the LSRs within the monitoring segment only control plane and requires additional functionalities for a
looking at the added (stacked) labels and not at the labels of the management system to properly support SPME creation and traffic
original LSP. This means that problems stemming from incorrect (or switching from the original transport path to the SPME.
unexpected) treatment of labels of the original LSP by the nodes
within the monitored segment can not be identified 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 reverse of this
situation is also possible, e.g., an incorrect or unexpected
treatment of SPME labels can result in false detection of a fault
where no problem existed originally.
The utilisation of SPMEs is basically limited to inter-carrier or As an example, the old and new transport resources (e.g. LSP
inter-domain segment monitoring where they are typically pre- tunnels) might compete with each other for resources which they have
configured or pre-instantiated. SPME instantiates a hierarchical in common. Depending on availability of resources, this competition
transport path (introducing MPLS label stacking) through which OAM can cause admission control to prevent the new LSP tunnel from being
packets can be sent. The SPME monitoring function is mainly established as this bandwidth accounting deviates from traditional
(non control plane) management system operation. While SPMEs can be
applied in any network context (single domain, multi domain, single
carrier, multi carrier, etc.), the main applications are in inter-
carrier or inter-domain segment monitoring where they are typically
pre- configured or pre-instantiated. SPME instantiates a
hierarchical path (introducing MPLS label stacking) through which OAM
packets can be sent. The SPME monitoring function is also mainly
important for protecting bundles of transport paths and carriers' important for protecting bundles of transport paths and carriers'
carrier solutions within one administrative domain. carrier solutions within an administrative domain.
The analogy for SPME in other transport technologies is Tandem
Connection Monitoring (TCM), used in Optical Transport Networks (OTN)
and Ethernet transport networks, which supports on-demand but does
not affect the path. TCM allows the insertion and removal of
performance monitoring overhead within the frame at intermediate
points in the network. It is done such that their insertion and
removal do not change the conditions of the path. Though as the OAM
overhead is part of the frame (designated overhead bytes), it is
constrained to a pre-defined number 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 bandwidth by label pre-configuration in terms of increasing the number of managed
stacking and increasing the number of managing objects by layer objects by layer stacking and identifiers/addresses. An on-demand
stacking and address management. An on-demand/temporary
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 unfavorable because the temporary configuration for procedure is unfavourable because the on-demand configuration for
monitoring can change the condition of the original monitored monitoring changes the condition of the original monitored path. To
transport path. To avoid or minimize the impact of the drawbacks avoid or minimize the impact of the drawbacks discussed above, a more
discussed above, a more efficient approach is required for the efficient approach is required for the operation of an MPLS-TP
operation of an MPLS-TP transport network. A monitoring mechanism, transport network. A monitoring mechanism, named Hitless Path
named on-demand Enhanced Path Segment Monitoring (EPSM), supporting Segment Monitoring (HPSM), supporting on-demand path segment
temporary and hitless path segment monitoring is proposed. monitoring without traffic disruption is needed.
5. OAM functions supported in segment monitoring
OAM functions that may usefully be exploited across on-demand EPSM 4. Requirements for hitless segment monitoring
are basically the on-demand performance monitoring functions which
are defined in OAM framework document RFC 6371 [RFC6371]. Segment
performance monitoring is used to verify the performance and hence
the status of transport path segments. The "on-demand" attribute is
generally temporary for maintenance operation.
Packet Loss and Packet Delay measurement are OAM functions strongly In the following sections, mandatory (M) and optional (O)
required in hitless and temporary segment monitoring because these requirements for the hitless segment monitoring function are listed.
functions are normally only supported at the end points of a
transport path. If a defect occurs, it might be quite hard to locate
the defect or degradation point without using the segment monitoring
function. If an operator cannot locate or narrow down the cause of
the fault, it is quite difficult to take prompt actions to solve the
problem.
Other on-demand monitoring functions, (e.g. Delay Variation 4.1. Backward compatibility
measurement) are desirable but not as necessary as the functions
mentioned above.
Regarding out-of-service on-demand performance management functions HPSM is an additional OAM tool that does not replace SPME. As such:
(e.g. Throughput measurement) there seems no need for EPSM.
However, OAM functions specifically designed for segment monitoring
should be developed to satisfy network objective (2) described in
Section 3.
Finally, the solution for EPSM has to cover both the per-node model (M1) HSPM MUST be compatible with the usage of SPME
and the per-interface model as specified in RFC 6371 [RFC6371].
6. Requirements for enhanced segment monitoring (M2) HSPM SHOULD be applicable at the SPME layer too
In the following sections, mandatory (M) and optional (O) (M3) HSPM MUST support both the per-node and per-interface model
requirements for the enhanced segment monitoring function are listed. as specified in RFC 6371 [RFC6371].
6.1. Non-intrusive segment monitoring 4.2. Non-intrusive segment monitoring
One of the major problems of legacy SPME highlighted in section 4 is One of the major problems of legacy SPME highlighted in section 3 is
that it may not monitor the original transport path and it could that it may not monitor the original path and it could disrupt
distrupt service traffic when set-up on demand. service traffic when set-up on demand.
(M1) EPSM must not change the original condition of transport path (M4) HPSM MUST NOT change the original conditions of transport
(e.g. must not change the length of MPLS frames, the exposed path (e.g. must not change the length of MPLS frames, the exposed
label values, etc.) label values, etc.)
(M2) EPSM must be provisioned on-demand without traffic (M5) HPSM MUST support on-demand provisioning and without traffic
disruption. disruption.
6.2. Single and multiple level monitoring 4.3. Multiple segments monitoring
The new enhanced segment monitoring function is supposed to be Along a transport path there may be the need to support
applied mainly for on-demand diagnostic purposes. We can simultaneously monitoring multiple segments
differentiate this monitoring from the existing proactive segment
monitoring by referring to is as on-demand multi-level monitoring. (M6) HPSM MUST support configuration of multiple monitoring
Currently the most serious problem is that there is no way to locate segments along a transport path.
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP *-------------------------------* MEP <= ME of a transport path
*------* *----* *--------------* <=three HPSM monit. instances
Figure 2: Multi-level on-demand segment monitoring example
4.4. Single and multiple level monitoring
The new hitless segment monitoring function will be applied mainly
for on-demand diagnostic purposes. With the current defined
approach, the most serious problem is that there is no way to locate
the degraded segment of a path without changing the conditions of the the degraded segment of a path without changing the conditions of the
original path. Therefore, as a first step, single layer segment original path. Therefore, as a first step, a single level, single
monitoring, not affecting the monitored path, is required for a new segment monitoring, not affecting the monitored path, is required for
on-demand and hitless segment monitoring function. A combination of a new on-demand segment monitoring function without traffic
multi-level and simultaneous segment monitoring is the most powerful disruption. A combination of multi-level and simultaneous segments
tool for accurately diagnosing the performance of a transport path. monitoring is the most powerful tool for accurately diagnosing the
However, in the field, a single level approach may be enough. performance of a transport path. However, in the field, a single
level, multiple segments approach will be less complex for management
and operations.
(M3) Single-level segment monitoring is required (M7) HPSM MUST support single-level segment monitoring
(O1) Multi-level segment monitoring is desirable (O1) HPSM MAY support multi-level segment monitoring.
Figure 2 shows an example of multi-level on-demand segment Figure 3 shows an example of multi-level on-demand segment
monitoring. 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 segm. mon. level 1 *-----------------* <=On-demand HPSM level 1
*-------------* <=On-demand segm. mon. level 2 *-------------* <=On-demand HPSM level 2
*-* <=On-demand segm. mon. level 3 *-* <=On-demand HPSM level 3
Figure 2: Example of multi-level on-demand segment monitoring
6.3. EPSM and end-to-end proactive monitoring independence Figure 3: Multi-level on-demand segment monitoring example
The need for simultaneously using existing end-to-end proactive 4.5. HPSM and end-to-end proactive monitoring independence
monitoring and the enhanced on-demand path segment monitoring is
considered. Normally, the on-demand path segment monitoring is
configured on a segment of a maintenance entity of a transport path.
In such an environment, on-demand single-level monitoring should be
performed without disrupting the pro-active monitoring of the
targeted end-to-end transport path to avoid affecting user traffic
performance monitoring.
Therefore: There is a need for simultaneously using existing end-to-end
proactive monitoring and on-demand path segment monitoring.
Normally, the on-demand path segment monitoring is configured on a
segment of a maintenance entity of a transport path. In such an
environment, on-demand single-level monitoring should be performed
without disrupting the pro-active monitoring of the targeted end-to-
end transport path to avoid affecting user traffic performance
monitoring.
(M4) EPSM shall be configured without changing or interfering with (M8) HPSM MUST support the capability to be concurrently and
the already in place end-to-end pro-active monitoring of the independently operated of the OAM function operated on the end-to-
transport path. end 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. +-----------------------------+ <= Pro-active end-to-end mon.
*------------------* <= On-demand segment mon. *------------------* <= On-demand HPSM
Figure 3: Independency between proactive end-to-end monitoring and Figure 4: Independency between proactive end-to-end monitoring and
on-demand segment monitoring on-demand segment monitoring
6.4. Arbitrary segment monitoring 4.6. Arbitrary segment monitoring
The main objective for enhanced on-demand segment monitoring is to The main objective for on-demand segment monitoring is to diagnose
diagnose the fault locations. A possible realistic diagnostic the fault locations. A possible realistic diagnostic procedure is to
procedure is to fix one end point of a segment at the MEP of the fix one end point of a segment at the MEP of the transport path under
transport path under observation and change progressively the length observation and change progressively the length of the segments.
of the segments. This example is shown in Figure 4. This example is shown in Figure 5.
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| 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. +-----------------------------+ <= Pro-active end-to-end mon.
*-----* <= 1st on-demand segment mon. *-----* <= 1st on-demand HPSM
*-------* <= 2nd on-demand segment mon. *-------* <= 2nd on-demand HPSM
*------------* <= 3rd on-demand segment mon.
| | | |
| | | |
*-----------------------* <= 6th on-demand segment mon. *-----------------------* <= 4th on-demand HPSM
*-----------------------------* <= 7th on-demand segment mon. *-----------------------------* <= 5th on-demand HPSM
Figure 4: A procedure to localize a defect by consecutive on-demand Figure 5: Localization of a defect by consecutive on-demand segment
segment monitoring monitoring procedure
Another possible scenario is depicted in Figure 5. 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 cost effective small boxes supporting only a subset of and consist of cost effective small boxes supporting only a subset of
OAM functions. In this case, where the source entities of the OAM functions. In this case, where the source entities of the
diagnostic packets are limited to the position of MEPs, on-demand diagnostic packets are limited to the position of MEPs, on-demand
segment monitoring will be ineffective because not all the segments segment monitoring will be ineffective because not all the segments
can be diagnosed (e.g. segment monitoring 3 in Figure 5 is not can be diagnosed (e.g. segment monitoring HPSM 3 in Figure 6 is not
available and it is not possible to determine the fault location available and it is not possible to determine the fault location
exactly). exactly).
Therefore: (M9) It SHALL be possible to provision HPSM on an arbitrary
(M5) it shall be possible to provision EPSM on an arbitrary
segment of a transport path and diagnostic packets should be segment of a transport path and diagnostic packets should be
inserted/terminated at any of intermediate maintenance points of inserted/terminated at any of intermediate maintenance points of
the original ME. the original ME.
--- --- --- --- --- ---
--- | | | | | | --- --- | | | | | | ---
| 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. +-----------------------------+ <= Pro-active end-to-end mon.
*-----* <= On-demand segment mon. 1 *-----* <= On-demand HPSM 1
*-----------------------* <= On-demand segment mon. 2 *-----------------------* <= On-demand HPSM 2
*---------* <= On-demand segment mon. 3 *---------* <= On-demand HPSM 3
Figure 5: ESPM configured at arbitrary segments Figure 6: HSPM configuration at arbitrary segments
6.5. Fault while EPSM is operational 4.7. Fault while HPSM is operational
Node or link failures may occur while EPSM 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 the EPSM function. If the there is no particular requirement for the HPSM function. If the
transport path is protected, the EPSM function should be terminated transport path is protected, the HPSM function should be terminated
to avoid monitoring a new segment when a protection or restoration to avoid monitoring a new segment when a protection or restoration
path is active. path is active.
Therefore: (M10) The HPSM functions SHOULD avoid monitoring an unintended
(M6) the EPSM function should avoid monitoring an unintended
segment when one or more failures occur segment when one or more failures occur
The following examples are provided for clarification only and they The following examples are provided for clarification only and they
are not intended to restrict any solution for meeting the are not intended to restrict any solution for meeting the
requirements of EPSM. requirements of HPSM.
Protection scenario A is shown in figure 6. 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. EPSM 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 EPSM 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. As a result requirement (M6) is continues on the active LSP path. As a result requirement (M10) is
satisfied. satisfied.
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-B-G-H-I-L-F - protection LSP: A-G-H-I-L-F
- EPSM: A-E - EPSM: A-E
Figure 6: Protection scenario A Figure 7: Protection scenario A
Protection scenario B is shown in figure 7. 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 EPSM 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). As a result requirement (M6) is not (A-B-G-H-D-E: 5 hops). As a result requirement (M10) is not
satisfied. satisfied.
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
- EPSM: A-E - EPSM: A-E
Figure 7: Protection scenario B Figure 8: Protection scenario B
6.6. EPSM maintenance points 4.8. HPSM Manageability
An intermediate maintenance point supporting the EPSM function has to From managing perspective, increasing the number of managed layers
be able to generate and inject OAM packets. However, maintenance and managed addresses/identifiers is not desirable in view of keeping
points for the EPSM do not necessarily have to coincide with MIPs or the management systems as simple as possible.
MEPs defined in the architecture.
Therefore: (M11)HPSM SHOULD NOT be based on additional transport layers (e.g.
hierarchical LSPs)
(M7) The same identifiers for MIPs and/or MEPs should be applied (M12) The same identifiers used for MIPs and/or MEPs SHOULD be
to EPSM maintenance points applied to HPSM maintenance points when they coincide. Anyway
maintenance points for the HPSM do not necessarily have to
coincide with MIPs and MEPs functional components as defined in
the OAM framework document RFC 6371 [RFC6371].
7. Summary 4.9. Supported OAM functions
An enhanced path segment monitoring (EPSM) mechanism is required to An intermediate maintenance point supporting the HPSM function has to
provide temporary and hitless segment monitoring. It shall meet the be able to generate and inject OAM packets. OAM functions that may
two network objectives described in section 3.8 of RFC 6371 [RFC6371] be applicable for on-demand HPSM are basically the on-demand
and repeated in Section 3 of this document. performance monitoring functions which are defined in the OAM
framework document RFC 6371 [RFC6371]. The "on-demand" attribute is
typically temporary for maintenance operation.
The enhancements should minimize the problems described in Section 4, (M13) HPSM MUST support Packet Loss and Packet Delay measurement.
i.e., (P-1), (P-2), (P-3) and (P-4).
The solution for the temporary and hitless segment monitoring has to That because these functions are normally only supported at the end
cover both the per-node model and the per-interface model specified points of a transport path. If a defect occurs, it might be quite
in RFC 6371 [RFC6371]. hard to locate the defect or degradation point without using the
segment monitoring function. If an operator cannot locate or narrow
down the cause of the fault, it is quite difficult to take prompt
actions to solve the problem.
The temporary and hitless segment monitoring solutions shall support Other on-demand monitoring functions (e.g. Delay Variation
on-demand Packet Loss Measurement and Packet Delay Measurement measurement) are desirable but not as necessary as the functions
functions and optionally other performance monitoring and fault mentioned above.
management functions (e.g. Throughput measurement, Delay variation
measurement, Diagnostic test, etc.).
8. Security Considerations (O2) HPSM MAY support Packet Delay variation, Throughput
measurement and other performance monitoring and fault management
functions.
The security considerations defined for RFC 6378 apply to this Support of out-of-service on-demand performance management functions
document as well. As this is simply a re-use of RFC 6378, there are (e.g. Throughput measurement) is not required for HPSM.
no new security considerations.
9. IANA Considerations 5. Summary
A new hitless path segment monitoring (HPSM) mechanism is required to
provide on-demand segment monitoring without traffic disruption. It
shall meet the two network objectives described in section 3.8 of RFC
6371 [RFC6371] and summarized in Section 3 of this document.
The mechanism should minimize the problems described in Section 3,
i.e. (P1), (P2) and (P3).
The solution for the on-demand segment monitoring without traffic
disruption needs to cover both the per-node model and the per-
interface model specified in RFC 6371 [RFC6371].
The on-demand segment monitoring without traffic disruption solution
needs to support on-demand Packet Loss Measurement and Packet Delay
Measurement functions and optionally other performance monitoring and
fault management functions (e.g. Throughput measurement, Packet
Delay variation measurement, Diagnostic test, etc.).
6. Security Considerations
The security considerations defined for MPLS Transport Profile
Framework in RFC 5921 [RFC5921] apply to this document as well. The
document provides the requirements for a new construct for
performance monitoring that will make use of existing OAM tools that
follow the security considerations provided in OAM Requirements for
MPLS-TP in RFC5860 [RFC5860].
7. IANA Considerations
There are no requests for IANA actions in this document. There are no requests for IANA actions in this document.
Note to the RFC Editor - this section can be removed before Note to the RFC Editor - this section can be removed before
publication. publication.
10. Acknowledgements 8. Contributors
The author would like to thank all members (including MPLS-TP Manuel Paul
steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
in ITU-T) involved in the definition and specification of MPLS Deutsche Telekom AG
Transport Profile.
Email: manuel.paul@telekom.de
9. Acknowledgements
The authors would also like to thank Alexander Vainshtein, Dave The authors would also like to thank Alexander Vainshtein, Dave
Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi,
Maarten Vissers, Jia He and Nurit Sprecher for their comments and Maarten Vissers, Jia He and Nurit Sprecher for their comments and
enhancements to the text. enhancements to the text.
11. References 10. References
11.1. Normative References 10.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, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://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, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <http://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, DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>. <http://www.rfc-editor.org/info/rfc5860>.
11.2. Informative References 10.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,
<http://www.rfc-editor.org/info/rfc5921>. <http://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, <http://www.rfc-editor.org/info/rfc6371>. September 2011, <http://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, DOI 10.17487/RFC6372, September 2011,
<http://www.rfc-editor.org/info/rfc6372>. <http://www.rfc-editor.org/info/rfc6372>.
Authors' Addresses Authors' Addresses
Alessandro D'Alessandro Alessandro D'Alessandro
Telecom Italia Telecom Italia
Via Reiss Romoli, 274
Torino 10148
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@mail01.huawei.com
Manuel Paul
Deutsche Telekom
Email: Manuel.Paul@telekom.de
Satoshi Ueno Satoshi Ueno
NTT Communications NTT Communications
Email: satoshi.ueno@ntt.com Email: satoshi.ueno@ntt.com
Kaoru Arai Kaoru Arai
NTT NTT
Email: arai.kaoru@lab.ntt.co.jp Email: arai.kaoru@lab.ntt.co.jp
 End of changes. 108 change blocks. 
358 lines changed or deleted 343 lines changed or added

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