draft-ietf-mpls-tp-temporal-hitless-psm-07.txt   draft-ietf-mpls-tp-temporal-hitless-psm-08.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: Standards Track L. Andersson
Expires: January 21, 2016 Huawei Technologies Expires: June 4, 2016 Huawei Technologies
M. Paul M. Paul
Deutsche Telekom Deutsche Telekom
S. Ueno S. Ueno
NTT Communications NTT Communications
K. Arai K. Arai
Y. Koike Y. Koike
NTT NTT
July 20, 2015 December 2, 2015
Enhanced path segment monitoring Enhanced path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-07.txt draft-ietf-mpls-tp-temporal-hitless-psm-08.txt
Abstract Abstract
The MPLS transport profile (MPLS-TP) has been standardized to enable The MPLS transport profile (MPLS-TP) has been standardized to enable
carrier-grade packet transport and complement converged packet carrier-grade packet transport and to complement converged packet
network deployments. Among the most attractive features of MPLS-TP network deployments. The most attractive features of MPLS-TP are the
there are OAM functions, which enable network operators or service OAM functions. These functions enable maintenance tools that may be
providers to provide various maintenance characteristics, such as exploited by network operators and service providers for fault
fault location, survivability, performance monitoring and in-service/ location, survivability, performance monitoring, in-service and out-
out of service measurements. of-service measurements.
One of the most important mechanisms which is common for transport One of the most important mechanisms that is common for transport
network operation is fault location. A segment monitoring function network operation is fault localisation. A segment monitoring
of a transport path is effective in terms of extension of the function of a transport path is effective in terms of extension of
maintenance work and indispensable particularly when the OAM function the maintenance work and indispensable, particularly when the OAM
is effective only between end points. However, the current approach function is activated only between end points. However, the current
defined for MPLS-TP for the segment monitoring (SPME) has some approach defined for MPLS-TP of segment monitoring has some
drawbacks. This document elaborates on the problem statement for the drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provides monitoring of a Sub-path Maintenance Elements (SPMEs) which provide monitoring of a
portion of a set of transport paths (LSPs or MS-PWs). Based on the segment of a set of transport paths (LSPs or MS-PWs). Based on the
problems, this document specifies new requirements to consider a new identified problems, this document provides considerations for the
improved mechanism of hitless transport path segment monitoring named specification of new requirements to consider a new improved
mechanism for hitless transport path segment monitoring to be named
Enhanced Path Segment Monitoring (EPSM). 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 January 21, 2016. This Internet-Draft will expire on June 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network objectives for segment monitoring . . . . . . . . . . 4 3. Network objectives for segment monitoring . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. OAM functions supported in segment monitoring . . . . . . . . 8 5. OAM functions supported in segment monitoring . . . . . . . . 8
6. Requirements for enhanced segment monitoring . . . . . . . . 8 6. Requirements for enhanced segment monitoring . . . . . . . . 9
6.1. Non intrusive segment monitoring . . . . . . . . . . . . 9 6.1. Non-intrusive segment monitoring . . . . . . . . . . . . 9
6.2. Single and multiple levels monitoring . . . . . . . . . . 9 6.2. Single and multiple level monitoring . . . . . . . . . . 9
6.3. EPSM and end-to-end proactive monitoring independence . . 10 6.3. EPSM and end-to-end proactive monitoring independence . . 10
6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 11
6.5. Fault while EPSM is in place . . . . . . . . . . . . . . 12 6.5. Fault while EPSM is operational . . . . . . . . . . . . . 12
6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13 6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
A packet transport network enables carriers or service providers to A packet transport network enables carriers and service providers to
use network resources efficiently, reduces operational complexity and use network resources efficiently. It reduces operational complexity
provides carrier-grade network operation. Appropriate maintenance and provides carrier-grade network operation. Appropriate
functions, supporting fault location, survivability, performance maintenance functions that support fault location, survivability,
monitoring and preliminary or in-service measurements, are essential pro-active performance monitoring, pre-service and in-service
to ensure quality and reliability of a network. They are essential measurements, are essential to ensure the quality of service and the
in transport networks and have evolved along with TDM, ATM, SDH and reliability of a network. They are essential in transport networks
OTN. and have evolved along with PDH, ATM, SDH and OTN.
As legacy technologies, also MPLS-TP does not scale when an arbitrary Similar to legacy technologies, MPLS-TP does also not scale when an
number of OAM functions are enabled. 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 a service provider of a
fault or defect affecting services. In addition, to ensure that fault or defect that affects their services. In addition, to ensure
faults or degradations can be localized, operators need a method to that faults or service degradation can be localized, operators need a
analyze or investigate the problem being end-to-end monitoring function to diagnose the detected problem. Using end-to-end
insufficient. In fact using end-to-end OAM monitoring, an operator monitoring for this purpose is insufficient. In fact by using end-
is not able to localize a fault or degrade. to-end OAM monitoring, an operator will not be able to localize a
fault or service degradation accurately.
Thus, a specific segment monitoring function for detailed analysis, Thus, a dedicated segment monitoring function that can focus on a
by selecting and focusing on a specific portion of a transport path, specific segment of a transport path and can provide a detailed
is indispensable to promptly and accurately localize the fault. analysis is indispensable to promptly and accurately localize the
fault.
For MPLS-TP, a path segment monitoring function has been defined to 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 RFC 6371 [RFC6371], the current method for segment monitoring of a
function of a transport path has implications that hinder the usage transport path has implications that hinder the usage in an operator
in an operator network. network.
This document elaborates on the problem statement for the path This document elaborates on the problem statement for the path
segment monitoring function and proposes to consider a new improved segment monitoring function and proposes to consider a new improved
method for segment monitoring, following up the work done in RFC 6371 method for segment monitoring, following up the description in RFC
[RFC6371]. Moreover, this document explains detailed requirements on 6371 [RFC6371]. This document also provides additional detailed
the new temporal and hitless segment monitoring function which are requirements for a new temporary and hitless segment monitoring
not covered in RFC 6371 [RFC6371]. 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
EPSM - Enhanced Path Segment Monitoring EPSM - Enhanced 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 PST - Path Segment Tunnel
TCM - Tandem connection monitoring TCM - Tandem connection monitoring
SDH - Synchronous Digital Hierarchy 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. Network objectives for segment monitoring
There are two required network objectives for MPLS-TP segment There are two network objectives for MPLS-TP segment monitoring
monitoring as described in section 3.8 of RFC 6371 [RFC6371]. described in section 3.8 of RFC 6371 [RFC6371]:
1. The monitoring and maintenance of current transport paths has to 1. The monitoring and maintenance of current transport paths has to
be conducted in-service without traffic disruption. be conducted in-service without traffic disruption.
2. Segment monitoring must not modify the forwarding of the segment 2. Segment monitoring must not modify the forwarding of the segment
portion of the transport path. portion of the transport path.
4. Problem Statement 4. Problem Statement
Sub-Path Maintenance Element (SPME) is defined in RFC 5921 [RFC5921] The Sub-Path Maintenance Element (SPME) function is defined in RFC
to monitor, protect, or manage portions of transport paths, such as 5921 [RFC5921]. It is used to monitor, protect, and/or manage
LSPs in MPLS-TP networks. The SPME is defined between the edges of segments of transport paths, such as LSPs in MPLS-TP networks. The
the portion of the transport path that needs to be monitored, SPME is defined between the edges of the segment of a transport path
protected, or managed. This SPME is created by stacking the shim that needs to be monitored, protected, or managed. This SPME is
header (MPLS header) according to RFC 3031 [RFC3031] and is defined created by stacking the shim header (MPLS header) according to RFC
as the segment where the header is stacked. OAM messages can be 3031 [RFC3031] and is defined as the segment where the header is
initiated at the edge of the SPME and sent to the peer edge of the stacked. OAM messages can be initiated at the edge of the SPME and
SPME or to a MIP along the SPME by setting the TTL value of the label sent to the peer edge of the SPME or to a MIP along the SPME by
stack entry (LSE) and interface identifier value at the corresponding setting the TTL value of the label stack entry (LSE) and interface
hierarchical LSP level in case of per-node model. identifier value at the corresponding hierarchical LSP level in case
of a per-node model.
This method has the following drawbacks, which impact on operation This method has the following drawbacks that impact the operation
costs: costs:
(P-1) Lowering the bandwidth efficiency by increasing the overhead (P-1) It lowers the bandwidth efficiency.
by shim headers stacking
(P-2) Increasing network management complexity, as a new sublayer (P-2) It increases network management complexity, because a new
and new MEPs and MIPs need to be configured for the SPME sublayer and new MEPs and MIPs have to be configured for the SPME.
Problem (P-1) comes from shim headers stacking that increase the Problem (P-1) is caused by the shim headers stacking that increases
overhead. the overhead.
Problem (P-2) is related to identifiers management issue. The Problem (P-2) is related to an identifier management issue. In the
identification of each sub-layer in case of label stacking is case of label stacking the identification of each sub-layer is
required for the segment monitoring in a MPLS-TP network. When SPME required for segment monitoring in a MPLS-TP network. When SPME is
is applied for on-demand OAM functions in MPLS-TP networks in a applied for on-demand OAM functions in MPLS-TP networks in a similar
similar manner to TCM for OTN or Ethernet transport networks, a manner as Tandem Connection Monitoring (TCM) in the Optical Transport
possible rule of differentiating those SPME/TCMs operationally will Networks (OTN) and Ethernet transport networks, a rule for
be necessary at least within an administrative domain. This enforces operationally differentiating those SPME/TCMs will be required; at
operators to create an additional permanent layer identification least within an administrative domain. This forces operators to
policy only for temporal path segment monitoring. Moreover, from the create an additional permanent layer identification policy that will
perspective of operation, increasing the managed addresses and the only be used for temporary path segment monitoring. Additionally,
managed layers is not desirable to keep transport networks as simple from the perspective of operation, increasing the number of managed
as possible. Reducing the managed identifiers and managed sub-layers addresses and managed layers is not desirable in view of keeping the
should be the fundamental direction in designing the architecture. 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 Tandem The analogy for SPME in legacy transport networks is TCM, which is
Connection Monitoring (TCM), which is on-demand and does not change on-demand and does not affect the transport path.
the transport path.
Moreover, using currently defined methods, the temporal setting of Also, using the currently defined methods, temporary setting of SPMEs
SPMEs also causes the following problems due to label stacking: causes the following problems due to additional label stacking:
(P-3) Changing the original condition of transport path by (P-3) The original condition of the transport path is affected by
changing the length of MPLS frames and changing the value of changing the length of MPLS frames and changing the value of
exposed label exposed label.
(P-4) Disrupting client traffic over a transport path, if the SPME (P-4) The client traffic over a transport path is disrupted when
is configured on demand. the SPME is configured on-demand.
Problem (P-3) has impacts on network objective (2). The monitoring Problem (P-3) impacts network objective (2) in Section 3. The
function should monitor the status without changing any conditions of monitoring function should monitor the status without changing any
the targeted monitored segment or transport path. Changing the conditions of the targeted, to be monitored, segment or transport
settings of the original shim header should not be allowed because path. Changing the settings of the original shim header should not
those changes correspond to creating a new portion of the original be allowed because this change corresponds to creating a new segment
transport path, which differs from the original data plane of the original transport path. And this differs from the original
conditions. If the conditions of the transport path change, the data plane conditions. When the conditions of the transport path
measured value or observed data will also change. This may make the change, the measured values or observed data will also change and
monitoring meaningless because the result of the monitoring would no this may make the monitoring meaningless because the result of the
longer reflect the reality of the connection where the original fault measurement would no longer reflect the performance of the connection
or degradation occurred. where the original fault or degradation occurred.
Figure 1 shows an example of SPME setting. In the figure, X means Figure 1 shows an example of SPME settings. In the figure, "X" is
the label value expected on the tail-end node D of the original the label value of the original transport path expected at the tail-
transport path. "210" and "220" are label allocated for SPME. The end of node D. "210" and "220" are label values allocated for SPME.
label values of the original path are modified as well as the values The label values of the original path are modified as well as the
of stacked label. As shown in Figure 1, SPME changes both the length values of the stacked labels. As shown in Figure 1, SPME changes
of MPLS frames and label value(s). This is no longer the monitoring both the length of MPLS frames and the label value(s). This means
of the original transport path but the monitoring of a different that it is no longer monitoring the original transport path but it is
path. Particularly, performance monitoring measurement (e.g. Delay monitoring a different path. In particular, performance monitoring
measurement and packet loss measurement) are sensitive to those measurements (e.g. Delay Measurement and Packet Loss Measurement)
changes. are sensitive to these 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 setting Figure 1: An Example of a SPME settings
Problem (P-4) can be avoided if the operator sets SPMEs in advance Problem (P-4) can be avoided if the operator sets SPMEs in advance
until the end of life of a transport path, which is neither temporal and maintains it until the end of life of a transport path, which is
nor on demand. Furthermore SMPEs cannot be set arbitrarly because neither temporary nor on-demand. Furthermore SMPEs cannot be set
overlapping of path segments is limited to nesting relationship. As arbitrarily because overlapping of path segments is limited to
a result, possible SPME patterns of portions of an original transport nesting relationships. As a result, possible SPME configurations of
path are limited due to the characteristic of SPME shown in Figure 1, segments of an original transport path are limited due to the
even if SPMEs are pre- configured. characteristic of SPME shown in Figure 1, even if SPMEs are pre-
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] seemingly supports the hitless
configuration for monitoring according to the framework document RFC configuration for monitoring according to the framework document RFC
5921 [RFC5921], the reality is that configurating an SPME is 5921 [RFC5921], the reality is that configuration of an SPME is
impossible without violating network objective (2). These concerns impossible without violating network objective (2) in Section 3.
are reported in section 3.8 of RFC 6371 [RFC6371]. These concerns are described in section 3.8 of RFC 6371 [RFC6371].
Moreover, make-before-break approach might not be effective under the Additionally, the make-before-break approach might not be usable in
static model without a control plane because the make-before-break is the static model without a control plane. This is because the make-
a restoration application based on the control plane. So management before-break is a restoration function based on a control plane.
systems should provide support for SPME creation and for coordinated Consequently the management systems should support SPME creation and
traffic switching from original transport path to the SPME. coordinated traffic switching from original transport path to the
SPME.
Other potential risks are also envisaged. Setting up a temporal SPME Other potential risks are also envisaged. Setting up a temporary
will result in the LSRs within the monitoring segment only looking at SPME will result in the LSRs within the monitoring segment only
the added (stacked) labels and not at the labels of the original LSP. looking at the added (stacked) labels and not at the labels of the
This means that problems stemming from incorrect (or unexpected) original LSP. This means that problems stemming from incorrect (or
treatment of labels of the original LSP by the nodes within the unexpected) treatment of labels of the original LSP by the nodes
monitored segment could not be found when setting up SPME. This within the monitored segment can not be identified when setting up
might include hardware problems during label look-up, mis- SPME. This might include hardware problems during label look-up,
configuration etc. Therefore operators have to pay extra attention mis-configuration, etc. Therefore operators have to pay extra
to correctly setting and checking the label values of the original attention to correctly setting and checking the label values of the
LSP in the configuration. Of course, the inversion of this situation original LSP in the configuration. Of course, the reverse of this
is also possible, e.g., incorrect or unexpected treatment of SPME situation is also possible, e.g., an incorrect or unexpected
labels can result in false detection of a fault where none of the treatment of SPME labels can result in false detection of a fault
problem originally existed. where no problem existed originally.
The utility of SPMEs is basically limited to inter-carrier or inter- The utilisation of SPMEs is basically limited to inter-carrier or
domain segment monitoring where they are typically pre-configured or inter-domain segment monitoring where they are typically pre-
pre-instantiated. SPME instantiates a hierarchical transport path configured or pre-instantiated. SPME instantiates a hierarchical
(introducing MPLS label stacking) through which OAM packets can be transport path (introducing MPLS label stacking) through which OAM
sent. SPME construct monitoring function is particularly important packets can be sent. The SPME monitoring function is mainly
mainly for protecting bundles of transport paths and carriers' important for protecting bundles of transport paths and carriers'
carrier solutions. SPME is expected to be mainly used for protection carrier solutions within one administrative domain.
purpose within one administrative domain.
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 bandwidth by label stacking pre-configuration in terms of increasing the bandwidth by label
and managing objects by layer stacking and address management. A on- stacking and increasing the number of managing objects by layer
demand/temporal configuration of SPME is one of the possible stacking and address management. An on-demand/temporary
approaches for minimizing the impact of these issues. However, the configuration of SPME is one of the possible approaches for
current method is unfavorable because the temporal configuration for minimizing the impact of these issues. However, the current
procedure is unfavorable because the temporary configuration for
monitoring can change the condition of the original monitored monitoring can change the condition of the original monitored
transport path. To avoid the drawbacks discussed above, a more transport path. To avoid or minimize the impact of the drawbacks
efficient approach is required for MPLS-TP transport network discussed above, a more efficient approach is required for the
operation to overcome or minimize the impact of the above described operation of an MPLS-TP transport network. A monitoring mechanism,
drawbacks. A monitoring mechanism, named on-demand Enhanced Path named on-demand Enhanced Path Segment Monitoring (EPSM), supporting
Segment Monitoring (EPSM), supporting temporal and hitless path temporary and hitless path segment monitoring is proposed.
segment monitoring is proposed.
5. OAM functions supported in segment monitoring 5. OAM functions supported in segment monitoring
OAM functions that may useful exploited across on-demand EPSM are OAM functions that may usefully be exploited across on-demand EPSM
basically limited to on-demand performance monitoring functions which are basically the on-demand performance monitoring functions which
are defined in OAM framework document RFC 6371 [RFC6371]. Segment are defined in OAM framework document RFC 6371 [RFC6371]. Segment
performance monitoring is used to evaluate the performance and hence performance monitoring is used to verify the performance and hence
the status of transport path segments. The "on-demand" attribute is the status of transport path segments. The "on-demand" attribute is
generally temporal for maintenance operation. generally temporary for maintenance operation.
Packet loss and packet delay are OAM functions strongly required in Packet Loss and Packet Delay measurement are OAM functions strongly
hitless and temporal segment monitoring because these functions are required in hitless and temporary segment monitoring because these
supported only between end points of a transport path. If a defect functions are normally only supported at the end points of a
occurs, it might be quite hard to locate the defect or degradation transport path. If a defect occurs, it might be quite hard to locate
point without using the segment monitoring function. If an operator the defect or degradation point without using the segment monitoring
cannot locate or narrow the cause of the fault, it is quite difficult function. If an operator cannot locate or narrow down the cause of
to take prompt actions to solve the problem. the fault, it is quite difficult to take prompt actions to solve the
problem.
Other on-demand monitoring functions, (e.g. and Delay variation Other on-demand monitoring functions, (e.g. Delay Variation
measurement) are desirable but not as necessary as the previous measurement) are desirable but not as necessary as the functions
mentioned functions. mentioned above.
Regarding out-of-service on-demand performance management functions Regarding out-of-service on-demand performance management functions
(e.g. Throughput measurement), there seems no need for EPSM. (e.g. Throughput measurement) there seems no need for EPSM.
However, OAM functions specifically designed for segment monitoring However, OAM functions specifically designed for segment monitoring
should be developed to satisfy network objective (2) described in should be developed to satisfy network objective (2) described in
section 3. Section 3.
Finally, the solution for EPSM has to cover both per-node model and Finally, the solution for EPSM has to cover both the per-node model
per- interface model which are specified in RFC 6371 [RFC6371]. and the per-interface model as specified in RFC 6371 [RFC6371].
6. Requirements for enhanced segment monitoring 6. Requirements for enhanced segment monitoring
In the following clauses, mandatory (M) and optional (O) requirements In the following sections, mandatory (M) and optional (O)
are for the new segment monitoring function are listed. requirements for the enhanced segment monitoring function are listed.
6.1. Non intrusive segment monitoring 6.1. Non-intrusive segment monitoring
One of the major problem of legacy SPME that has been highlighted in One of the major problems of legacy SPME highlighted in section 4 is
Sec. 4 is that it does not monitor the original transport path and it that it may not monitor the original transport path and it could
could distrupt service traffic when set-up on demand. distrupt service traffic when set-up on demand.
(M1) EPSM must not change the original condition of transport path (M1) EPSM must not change the original condition of transport path
(e.g. must not change the lenght of MPLS frames, the exposed label (e.g. must not change the length of MPLS frames, the exposed
values, etc.) label values, etc.)
(M2) EPSM must be set on demand without traffic dispruption (M2) EPSM must be provisioned on-demand without traffic
disruption.
6.2. Single and multiple levels monitoring 6.2. Single and multiple level monitoring
The new segment monitoring function is supposed to be applied mainly The new enhanced segment monitoring function is supposed to be
for on-demand diagnostic purpose. We can differentiate this applied mainly for on-demand diagnostic purposes. We can
monitoring from the proactive segment monitoring as on-demand multi- differentiate this monitoring from the existing proactive segment
level monitoring. The most serious problem at the moment is that monitoring by referring to is as on-demand multi-level monitoring.
there is no way to localize the degraded portion of a path without Currently the most serious problem is that there is no way to locate
changing the conditions of the original path. Therefore, as a first the degraded segment of a path without changing the conditions of the
step, single layer segment monitoring not affecting the monitored original path. Therefore, as a first step, single layer segment
path is required for a new on-demand and hitless segment monitoring monitoring, not affecting the monitored path, is required for a new
function. A combination of multi-level and simultaneous segment on-demand and hitless segment monitoring function. A combination of
monitoring is the most powerful tool for accurately diagnosing the multi-level and simultaneous segment monitoring is the most powerful
performance of a transport path. However, on field, a single level tool for accurately diagnosing the performance of a transport path.
approach may be enough. However, in the field, a single level approach may be enough.
(M3) Single-level segment monitoring is required (M3) Single-level segment monitoring is required
(O1) Multi-level segment monitoring is desirable (O1) Multi-level segment monitoring is desirable
Figure 2 shows an example of a multi-level on-demand segment Figure 2 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. monit. level 1 *-----------------* <=On-demand segm. mon. level 1
*-------------* <=On-demand segm. monit. level 2 *-------------* <=On-demand segm. mon. level 2
*-* <=On-demand segm. monit. level 3 *-* <=On-demand segm. mon. level 3
Figure 2: Example of multi-level on-demand segment monitoring Figure 2: Example of multi-level on-demand segment monitoring
6.3. EPSM and end-to-end proactive monitoring independence 6.3. EPSM and end-to-end proactive monitoring independence
The necessity of simultaneous monitoring of current end-to-end The need for simultaneously using existing end-to-end proactive
proactive monitoring and new on-demand path segment monitoring is monitoring and the enhanced on-demand path segment monitoring is
here below considered. Normally, the on-demand path segment considered. Normally, the on-demand path segment monitoring is
monitoring is configured in a segment of a maintenance entity of a configured on a segment of a maintenance entity of a transport path.
transport path. In such an environment, on-demand single-level In such an environment, on-demand single-level monitoring should be
monitoring should be done without disrupting pro-active monitoring of performed without disrupting the pro-active monitoring of the
the targeted end- to-end transport path to avoid missing user traffic targeted end-to-end transport path to avoid affecting user traffic
performance monitoring. performance monitoring.
Accordingly, Therefore:
(M4) EPSM shall be established without changing or interfering (M4) EPSM shall be configured without changing or interfering with
with the already in place end-to-end pro-active monitoring of the already in place end-to-end pro-active monitoring of the
transport path 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
+-----------------------------+ <= Proactive E2E monitoring +-----------------------------+ <= Pro-active end-to-end mon.
*------------------* <= On-demand segment monitoring *------------------* <= On-demand segment mon.
Figure 3: Independency between proactive end-to-end monitoring and Figure 3: Independency between proactive end-to-end monitoring and
on-demand segment monitoring on-demand segment monitoring
6.4. Arbitrary segment monitoring 6.4. Arbitrary segment monitoring
The main objective of on-demand segment monitoring is to diagnose the The main objective for enhanced on-demand segment monitoring is to
fault points. One possible realistic diagnostic procedure is to fix diagnose the fault locations. A possible realistic diagnostic
one end point of a segment at the MEP of the transport path under procedure is to fix one end point of a segment at the MEP of the
observation and change progressively the length of the segments. transport path under observation and change progressively the length
This example is shown in Figure 4. of the segments. This example is shown in Figure 4.
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive E2E monitoring +-----------------------------+ <= Pro-active end-to-end mon.
*-----* <= 1st on-demand segment monitoring *-----* <= 1st on-demand segment mon.
*-------* <= 2nd on-demand segment monitoring *-------* <= 2nd on-demand segment mon.
*------------* <= 3rd on-demand segment monitoring *------------* <= 3rd on-demand segment mon.
| | | |
| | | |
*-----------------------* <= 6th on-demand segment monitoring *-----------------------* <= 6th on-demand segment mon.
*-----------------------------*<= 7th on-demand segment monitoring *-----------------------------* <= 7th on-demand segment mon.
Figure 4: A procedure to localize a defect by consecutive on-demand Figure 4: A procedure to localize a defect by consecutive on-demand
segments monitoring segment monitoring
Another possible scenario is depicted in Figure 5. In this case, the Another possible scenario is depicted in Figure 5. In this case, the
operators want to diagnose a transport path from a transit node that operator wants to diagnose a transport path starting at a transit
is located at the middle, because the end nodes(A and E) are located node, because the end nodes(A and E) are located at customer sites
at customer sites and consist of cost effective small box supporting and consist of cost effective small boxes supporting only a subset of
only a subset of OAM functions. In that case, if the source entities OAM functions. In this case, where the source entities of the
of the diagnostic packets are limited to the position of MEPs, on- diagnostic packets are limited to the position of MEPs, on-demand
demand segment monitoring will be ineffective because not all the segment monitoring will be ineffective because not all the segments
segments can be diagnosed (e.g. segment monitoring 3 in Figure 5 is can be diagnosed (e.g. segment monitoring 3 in Figure 5 is not
not available and it is not possible to precisely localize the fault available and it is not possible to determine the fault location
point). exactly).
Accordingly, Therefore:
(M5) EPSM shall be set in an arbitrary segment of a transport path (M5) it shall be possible to provision EPSM on an arbitrary
and diagnostic packets should be inserted/terminated at any of segment of a transport path and diagnostic packets should be
intermediate maintenance points of the original ME. inserted/terminated at any of intermediate maintenance points of
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
+-----------------------------+ <= Proactive E2E monitoring +-----------------------------+ <= Pro-active end-to-end mon.
*-----* <= On-demand segment monitoring 1 *-----* <= On-demand segment mon. 1
*-----------------------*<= On-demand segment monitoring 2 *-----------------------* <= On-demand segment mon. 2
*---------* <= On-demand segment monitoring 3 *---------* <= On-demand segment mon. 3
Figure 5: HSPM is configured at arbitrary segments Figure 5: ESPM configured at arbitrary segments
6.5. Fault while EPSM is in place 6.5. Fault while EPSM is operational
Node or link failures may occur while EPSM is active. In that case, Node or link failures may occur while EPSM 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 EPSM while if the trasport there is no particular requirement for the EPSM function. If the
path is protected, EPSM function should be terminated to avoid transport path is protected, the EPSM function should be terminated
monitoring a new segment when a protection or restoration path is in to avoid monitoring a new segment when a protection or restoration
place. Therefore path is active.
(M5) EPSM function should avoid monitoring an unintended segment Therefore:
when failures occur
The folowing examples are reported for clarification only and shall (M6) the EPSM function should avoid monitoring an unintended
not be intended to restrict any solution for meeting the requirements segment when one or more failures occur
of EPSM. A Protection scenario A is shown in figure 6. In this
scenario, a working LSP and a protection LSP are set. EPSM is set The following examples are provided for clarification only and they
between A and E. Considering a fault happens between nodes B and C, are not intended to restrict any solution for meeting the
the EPSM is not affected by protection and continues in the working requirements of EPSM.
LSP path. As a result, requirement (M5) is satisfied.
Protection scenario A is shown in figure 6. In this scenario a
working LSP and a protection LSP are set-up. EPSM is activated
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
continues on the active LSP path. As a result requirement (M6) is
satisfied.
A - B - C - D - E - F A - B - C - D - E - F
\ / \ /
G - H - I - L G - H - I - L
Where: Where:
- e2e 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-B-G-H-I-L-F
- EPSM: A-E - EPSM: A-E
---------------
Figure 6: Protection scenario A Figure 6: Protection scenario A
Differently, figure 7 shows a scenario where only a portion of a Protection scenario B is shown in figure 7. The difference with
transport path is protected. In this case, when a fault happen scenario A is that only a portion of the transport path is protected.
between node B and C along the working sub-path, traffic is switched In this case, when a fault occurs between nodes B and C on the
to protection sub-path B-G-H-D. In the hypotesis that OAM packets working sub-path B-C-D, traffic will be switched to protection sub-
termination depend only on TTL value of MPLS label header, the target path B-G-H-D. Assuming that OAM packet termination depends only on
node of EPSM changes from E to D due to the difference of hop counts the TTL value of the MPLS label header, the target node of the EPSM
between the working path route (ABCDE: 4 hops) and protection path changes from E to D due to the difference of hop counts between the
route (ABGHDE: 5 hops). As a result, requirement (M5) is not 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
satisfied. satisfied.
A - B - C - D - E - F A - B - C - D - E - F
\ / \ /
G - H G - H
- e2e 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 7: Protection scenario B
6.6. EPSM maintenance points 6.6. EPSM maintenance points
An intermediate maintenance point supporting the EPSM has to be able An intermediate maintenance point supporting the EPSM function has to
to generate and inject OAM packets. Although maintenance points for be able to generate and inject OAM packets. However, maintenance
the EPSM do not necessarily have to coincide with MIPs or MEPs in points for the EPSM do not necessarily have to coincide with MIPs or
terms of the architecture definition, MEPs defined in the architecture.
Therefore:
(M7) The same identifiers for MIPs and/or MEPs should be applied (M7) The same identifiers for MIPs and/or MEPs should be applied
to EPSM maintenance points to EPSM maintenance points
7. Summary 7. Summary
An enhanced monitoring mechanism is required to support temporal and An enhanced path segment monitoring (EPSM) mechanism is required to
hitless segment monitoring which meets the two network objectives provide temporary and hitless segment monitoring. It shall meet the
described in section 3.8 of RFC 6371 [RFC6371] and reported in two network objectives described in section 3.8 of RFC 6371 [RFC6371]
Section 3 of this document. and repeated in Section 3 of this document.
The enhancements should minimize the issues described in Section 4, The enhancements should minimize the problems described in Section 4,
i.e., P-1, P-2, P-3 and P-4. i.e., (P-1), (P-2), (P-3) and (P-4).
The solution for the temporal and hitless segment monitoring has to The solution for the temporary and hitless segment monitoring has to
cover both per-node model and per-interface model which are specified cover both the per-node model and the per-interface model specified
in RFC 6371 [RFC6371]. in RFC 6371 [RFC6371].
The temporal and hitless segment monitoring solutions shall support The temporary and hitless segment monitoring solutions shall support
on-demand Packet Loss Measurement and Packet Delay Measurement on-demand Packet Loss Measurement and Packet Delay Measurement
functions and optionally other performance monitoring /fault functions and optionally other performance monitoring and fault
management functions (e.g. Throughput measurement, Delay variation management functions (e.g. Throughput measurement, Delay variation
measurement, Diagnostic test measurement, etc.). measurement, Diagnostic test, etc.).
8. Security Considerations 8. Security Considerations
The security considerations defined for RFC 6378 apply to this The security considerations defined for RFC 6378 apply to this
document as well. As this is simply a re-use of RFC 6378, there are document as well. As this is simply a re-use of RFC 6378, there are
no new security considerations. no new security considerations.
9. IANA Considerations 9. IANA Considerations
There are no requests for IANA actions in this document. There are no requests for IANA actions in this document.
skipping to change at page 14, line 32 skipping to change at page 14, line 46
publication. publication.
10. Acknowledgements 10. Acknowledgements
The author would like to thank all members (including MPLS-TP The author would like to thank all members (including MPLS-TP
steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
in ITU-T) involved in the definition and specification of MPLS in ITU-T) involved in the definition and specification of MPLS
Transport Profile. Transport Profile.
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, Italo Busi, Maarten Vissers, Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi,
Malcolm Betts, Nurit Sprecher and Jia He for their comments and Maarten Vissers, Jia He and Nurit Sprecher for their comments and
enhancements to the text. enhancements to the text.
11. Normative References 11. 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
skipping to change at page 16, line 4 skipping to change at page 16, line 18
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
Yoshinori Koike Yoshinori Koike
NTT NTT
Email: koike.yoshinori@lab.ntt.co.jp Email: y.koike@vcd.nttbiz.com
 End of changes. 94 change blocks. 
313 lines changed or deleted 332 lines changed or added

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