draft-ietf-mpls-tp-temporal-hitless-psm-06.txt   draft-ietf-mpls-tp-temporal-hitless-psm-07.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: August 30, 2015 Huawei Technologies Expires: January 21, 2016 Huawei Technologies
M. Paul M. Paul
Deutsche Telekom Deutsche Telekom
S. Ueno S. Ueno
NTT Communications
K. Arai K. Arai
Y. Koike Y. Koike
NTT NTT
February 26, 2015 July 20, 2015
Temporal and hitless path segment monitoring Enhanced path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-06.txt draft-ietf-mpls-tp-temporal-hitless-psm-07.txt
Abstract Abstract
The MPLS transport profile (MPLS-TP) is being 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 complement converged packet
network deployments. Among the most attractive features of MPLS-TP network deployments. Among the most attractive features of MPLS-TP
are OAM functions, which enable network operators or service there are OAM functions, which enable network operators or service
providers to provide various maintenance characteristics, such as providers to provide various maintenance characteristics, such as
fault location, survivability, performance monitoring, and fault location, survivability, performance monitoring and in-service/
preliminary or in-service measurements. out of service measurements.
One of the most important mechanisms which is common for transport One of the most important mechanisms which is common for transport
network operation is fault location. A segment monitoring function network operation is fault location. A segment monitoring function
of a transport path is effective in terms of extension of the of a transport path is effective in terms of extension of the
maintenance work and indispensable particularly when the OAM function maintenance work and indispensable particularly when the OAM function
is effective only between end points. However, the current approach is effective only between end points. However, the current approach
defined for MPLS-TP for the segment monitoring (SPME) has some fatal defined for MPLS-TP for the segment monitoring (SPME) 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 provides monitoring of a
portion of a set of transport paths (LSPs or MS-PWs). Based on the portion of a set of transport paths (LSPs or MS-PWs). Based on the
problems, this document specifies new requirements to consider a new problems, this document specifies new requirements to consider a new
improved mechanism of hitless transport path segment monitoring. improved mechanism of hitless transport path segment monitoring 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 August 30, 2015. This Internet-Draft will expire on January 21, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 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 monitoring . . . . . . . . . . . . . . 4 3. Network objectives for segment monitoring . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. OAM functions using segment monitoring . . . . . . . . . . . 9 5. OAM functions supported in segment monitoring . . . . . . . . 8
6. Further consideration of requirements for enhanced 6. Requirements for enhanced segment monitoring . . . . . . . . 8
segmentmonitoring . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Non intrusive segment monitoring . . . . . . . . . . . . 9
6.1. Necessity of on-demand single-level monitoring . . . . . 10 6.2. Single and multiple levels monitoring . . . . . . . . . . 9
6.2. Necessity of on-demand monitoring independent from end- 6.3. EPSM and end-to-end proactive monitoring independence . . 10
to-end proactive monitoring . . . . . . . . . . . . . . . 10 6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 10
6.3. Necessity of arbitrary segment monitoring . . . . . . . 11 6.5. Fault while EPSM is in place . . . . . . . . . . . . . . 12
6.4. Fault during HPSM in case of protection . . . . . . . . . 13 6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13
6.5. Consideration of maintenance point for HPSM . . . . . . . 14 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
A packet transport network will enable carriers or service providers A packet transport network enables carriers or service providers to
to use network resources efficiently, reduce operational complexity use network resources efficiently, reduces operational complexity and
and provide carrier-grade network operation. Appropriate maintenance provides carrier-grade network operation. Appropriate maintenance
functions, supporting fault location, survivability, performance functions, supporting fault location, survivability, performance
monitoring and preliminary or in-service measurements, are essential monitoring and preliminary or in-service measurements, are essential
to ensure quality and reliability of a network. They are essential to ensure quality and reliability of a network. They are essential
in transport networks and have evolved along with TDM, ATM, SDH and in transport networks and have evolved along with TDM, ATM, SDH and
OTN. OTN.
Unlike in SDH or OTN networks, where OAM is an inherent part of every As legacy technologies, also MPLS-TP does not scale when an arbitrary
frame and frames are also transmitted in idle mode, it is not per se number of OAM functions are enabled.
possible to constantly monitor the status of individual connections
in packet networks. Packet-based OAM functions are flexible and
selectively configurable according to operators' needs.
According to the MPLS-TP OAM requirements 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 the service(s) provided. In addition, to fault or defect affecting services. In addition, to ensure that
ensure that faults or degradations can be localized, operators need a faults or degradations can be localized, operators need a method to
method to analyze or investigate the problem. From the fault analyze or investigate the problem being end-to-end monitoring
localization perspective, end-to-end monitoring is insufficient. insufficient. In fact using end-to-end OAM monitoring, an operator
Using end-to-end OAM monitoring, when one problem occurs in an MPLS- is not able to localize a fault or degrade.
TP network, the operator can detect the fault, but is not able to
localize it.
Thus, a specific segment monitoring function for detailed analysis, Thus, a specific segment monitoring function for detailed analysis,
by focusing on and selecting a specific portion of a transport path, by selecting and focusing on a specific portion of a transport path,
is indispensable to promptly and accurately localize the fault. 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
function of a transport path has implications that hinder the usage function of a transport path has implications that hinder the usage
in an operator network. in an operator 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 of the segment monitoring, following up the work done in RFC method for segment monitoring, following up the work done in RFC 6371
6371 [RFC6371]. Moreover, this document explains detailed [RFC6371]. Moreover, this document explains detailed requirements on
requirements on the new temporal and hitless segment monitoring the new temporal and hitless segment monitoring function which are
function which are not covered in RFC 6371 [RFC6371]. 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
HPSM - Hitless 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
skipping to change at page 4, line 41 skipping to change at page 4, line 35
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 monitoring 3. Network objectives for segment monitoring
There are two indispensable network objectives for MPLS-TP networks There are two required network objectives for MPLS-TP segment
as described in section 3.8 of RFC 6371 [RFC6371]. monitoring as 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.
It is common in transport networks that network objective (1) is
mandatory and that regarding network objective (2) the monitoring
shall not change the forwarding behavior.
4. Problem Statement 4. Problem Statement
To monitor, protect, or manage portions of transport paths, such as Sub-Path Maintenance Element (SPME) is defined in RFC 5921 [RFC5921]
LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is to monitor, protect, or manage portions of transport paths, such as
defined in RFC 5921 [RFC5921]. The SPME is defined between the edges LSPs in MPLS-TP networks. The SPME is defined between the edges of
of the portion of the transport path that needs to be monitored, the portion of the transport path that needs to be monitored,
protected, or managed. This SPME is created by stacking the shim protected, or managed. This SPME is created by stacking the shim
header (MPLS header) RFC 3031 [RFC3031] and is defined as the segment header (MPLS header) according to RFC 3031 [RFC3031] and is defined
where the header is stacked. OAM messages can be initiated at the as the segment where the header is stacked. OAM messages can be
edge of the SPME and sent to the peer edge of the SPME or to a MIP initiated at the edge of the SPME and sent to the peer edge of the
along the SPME by setting the TTL value of the label stack entry SPME or to a MIP along the SPME by setting the TTL value of the label
(LSE) and interface identifier value at the corresponding stack entry (LSE) and interface identifier value at the corresponding
hierarchical LSP level in case of per-node model. hierarchical LSP level in case of per-node model.
This method has the following general issues, which are fatal in This method has the following drawbacks, which impact on operation
terms of cost and operation. costs:
(P-1) Increasing the overhead by the stacking of shim header(s)
(P-2) Increasing the address management complexity, as new MEPs
and MIPs need to be configured for the SPME in the old MEG
Problem (P-1) leads to decreased efficiency as bandwidth is wasted (P-1) Lowering the bandwidth efficiency by increasing the overhead
only for maintenance purposes. As the size of monitored segments by shim headers stacking
increases, the size of the label stack grows. Moreover, if the
operator wants to monitor the portion of a transport path without
service disruption, one or more SPMEs have to be set in advance until
the end of life of a transport path, which is not temporal or on-
demand. Consuming additional bandwidth permanently for only the
monitoring purpose should be avoided to maximize the available
bandwidth.
Problem (P-2) is related to an identifier-management issue. The (P-2) Increasing network management complexity, as a new sublayer
identification of each layer in case of LSP label stacking is and new MEPs and MIPs need to be configured for the SPME
required in terms of strict sub-layer management for the segment
monitoring in a MPLS-TP network. When SPME/TCM is applied for on-
demand OAM functions in MPLS-TP networks in a similar manner to OTN
or Ethernet transport networks, a possible rule of differentiating
those SPME/TCMs operationally will be necessary at least within an
administrative domain. This enforces operators to create an
additional permanent layer identification policy only for temporal
path segment monitoring. Moreover, from the perspective of
operation, increasing the managed addresses and the managed layer is
not desirable in terms of simplified operation featured by current
transport networks. Reducing the managed identifiers and managed
layers should be the fundamental direction in designing the
architecture.
The most familiar example for SPME in transport networks is Tandem Problem (P-1) comes from shim headers stacking that increase the
Connection Monitoring (TCM), which can for example be used for a overhead.
carrier's carrier solution, as shown in Fig. 17 of the framework
document RFC 5921 [RFC5921]. However, in this case, the SPMEs have
to be pre-configured. If this solution is applied to specific
segment monitoring within one operator domain, all the necessary
specific segments have to be pre-configured. This setting increases
the managed objects as well as the necessary bandwidth, shown as
Problem (P-1) and (P-2). Moreover, as a result of these pre-
configurations, they impose operators to pre-design the structure of
sub-path maintenance elements, which is not preferable in terms of
operators' increased burden. These concerns are summarized in
section 3.8 of RFC 6371 [RFC6371].
Furthermore, in reality, all the possible patterns of path segment Problem (P-2) is related to identifiers management issue. The
cannot be set in SPME, because overlapping of path segments is identification of each sub-layer in case of label stacking is
limited to nesting relationship. As a result, possible SPME patterns required for the segment monitoring in a MPLS-TP network. When SPME
of portions of an original transport path are limited due to the is applied for on-demand OAM functions in MPLS-TP networks in a
characteristic of SPME shown in Figure.1, even if SPMEs are pre- similar manner to TCM for OTN or Ethernet transport networks, a
configured. This restriction is inconvenient when operators have to possible rule of differentiating those SPME/TCMs operationally will
fix issues in an on-demand manner. To avoid these issues, the be necessary at least within an administrative domain. This enforces
temporal and on-demand setting of the SPME(s) is needed and more operators to create an additional permanent layer identification
efficient for monitoring in MPLS-TP transport network operation. policy only for temporal path segment monitoring. Moreover, from the
perspective of operation, increasing the managed addresses and the
managed layers is not desirable to keep transport networks as simple
as possible. Reducing the managed identifiers and managed sub-layers
should be the fundamental direction in designing the architecture.
However, using currently defined methods, the temporal setting of The analogy for SPME in legacy transport networks is Tandem
SPMEs also causes the following problems due to label stacking, which Connection Monitoring (TCM), which is on-demand and does not change
are fatal in terms of intrinsic monitoring and service disruption. the transport path.
(P'-1) Changing the condition of the original transport path by Moreover, using currently defined methods, the temporal setting of
changing the length of all the MPLS frames and changing label SPMEs also causes the following problems due to label stacking:
value(s)
(P'-2) Disrupting client traffic over a transport path, if the (P-3) Changing the original condition of transport path by
SPME is temporally configured. changing the length of MPLS frames and changing the value of
exposed label
Problem (P'-1) is a fatal problem in terms of intrinsic monitoring. (P-4) Disrupting client traffic over a transport path, if the SPME
As shown in network objective (2), the monitoring function needs to is configured on demand.
monitor the status without changing any conditions of the targeted
monitored segment or the transport path. If the conditions of the
transport path change, the measured value or observed data will also
change. This can make the monitoring meaningless because the result
of the monitoring would no longer reflect the reality of the
connection where the original fault or degradation occurred.
Another aspect is that changing the settings of the original shim Problem (P-3) has impacts on network objective (2). The monitoring
header should not be allowed because those changes correspond to function should monitor the status without changing any conditions of
creating a new portion of the original transport path, which differs the targeted monitored segment or transport path. Changing the
from the original data plane conditions. settings of the original shim header should not be allowed because
those changes correspond to creating a new portion of the original
transport path, which differs from the original data plane
conditions. If the conditions of the transport path change, the
measured value or observed data will also change. This may make the
monitoring meaningless because the result of the monitoring would no
longer reflect the reality of the connection where the original fault
or degradation occurred.
Figure 1 shows an example of SPME setting. In the figure, X means Figure 1 shows an example of SPME setting. In the figure, X means
the one label expected on the tail-end node D of the original the label value expected on the tail-end node D of the original
transport path. "210" and "220" are label allocated for SPME. The transport path. "210" and "220" are label allocated for SPME. The
label values of the original path are modified as well as the values label values of the original path are modified as well as the values
of stacked label. As shown in Fig.1, SPME changes the length of all of stacked label. As shown in Figure 1, SPME changes both the length
the MPLS frames and changes label value(s). This is no longer the of MPLS frames and label value(s). This is no longer the monitoring
monitoring of the original transport path but the monitoring of a of the original transport path but the monitoring of a different
different path. Particularly, performance monitoring measurement path. Particularly, performance monitoring measurement (e.g. Delay
(Delay measurement and loss measurement) are sensitive to those measurement and packet loss measurement) are sensitive to those
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 A---100--B-----------X---D--130--E <= transport path
MEP \ / MEP <= transport path 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 setting
Problem (P'-2) was not fully discussed, although the make-before- Problem (P-4) can be avoided if the operator sets SPMEs in advance
break procedure in the survivability document RFC 6371 [RFC6372] until the end of life of a transport path, which is neither temporal
seemingly supports the hitless configuration for monitoring according nor on demand. Furthermore SMPEs cannot be set arbitrarly because
to the framework document RFS 5921 [RFC5921]. The reality is the overlapping of path segments is limited to nesting relationship. As
hitless configuration of SPME is impossible without affecting the a result, possible SPME patterns of portions of an original transport
conditions of the targeted transport path, because the make-before- path are limited due to the characteristic of SPME shown in Figure 1,
break procedure is premised on the change of the inner label value. even if SPMEs are pre- configured.
This means changing one of the settings in MPLS shim header.
Moreover, this might not be effective under the static model without Although the make-before-break procedure in the survivability
a control plane because the make-before-break is a restoration document RFC 6372 [RFC6372] seemingly supports the hitless
application based on the control plane. The removal of SPME whose configuration for monitoring according to the framework document RFC
segment is monitored could have the same impact (disruption of client 5921 [RFC5921], the reality is that configurating an SPME is
traffic) as the creation of an SPME on the same LSP. impossible without violating network objective (2). These concerns
are reported in section 3.8 of RFC 6371 [RFC6371].
Note: (P'-2) will be removed when non-disruptive make-before-break Moreover, make-before-break approach might not be effective under the
(in both with and without Control Plane environment) is specified in static model without a control plane because the make-before-break is
other MPLS-TP documents. However, (P'-2) could be replaced with the a restoration application based on the control plane. So management
following issue. Non-disruptive make-before-break, in other words, systems should provide support for SPME creation and for coordinated
taking an action similar to switching just for monitoring is not an traffic switching from original transport path to the SPME.
ideal operation in transport networks.
The other potential risks are also envisaged. Setting up a temporal Other potential risks are also envisaged. Setting up a temporal SPME
SPME will result in the LSRs within the monitoring segment only will result in the LSRs within the monitoring segment only looking at
looking at the added (stacked) labels and not at the labels of the the added (stacked) labels and not at the labels of the original LSP.
original LSP. This means that problems stemming from incorrect (or This means that problems stemming from incorrect (or unexpected)
unexpected) treatment of labels of the original LSP by the nodes treatment of labels of the original LSP by the nodes within the
within the monitored segment could not be found when setting up SPME. monitored segment could not be found when setting up SPME. This
This might include hardware problems during label look-up, mis- might include hardware problems during label look-up, mis-
configuration etc. Therefore operators have to pay extra attention configuration etc. Therefore operators have to pay extra attention
to correctly setting and checking the label values of the original to correctly setting and checking the label values of the original
LSP in the configuration. Of course, the inversion of this situation LSP in the configuration. Of course, the inversion of this situation
is also possible, .e.g., incorrect or unexpected treatment of SPME is also possible, e.g., incorrect or unexpected treatment of SPME
labels can result in false detection of a fault where none of the labels can result in false detection of a fault where none of the
problem originally existed. problem originally existed.
The utility of SPMEs is basically limited to inter-carrier or inter- The utility of SPMEs is basically limited to inter-carrier or inter-
domain segment monitoring where they are typically pre-configured or domain segment monitoring where they are typically pre-configured or
pre-instantiated. SPME instantiates a hierarchical transport path pre-instantiated. SPME instantiates a hierarchical transport path
(introducing MPLS label stacking) through which OAM packets can be (introducing MPLS label stacking) through which OAM packets can be
sent. SPME construct monitoring function is particularly important sent. SPME construct monitoring function is particularly important
mainly for protecting bundles of transport paths and carriers' mainly for protecting bundles of transport paths and carriers'
carrier solutions. SPME is expected to be mainly used for protection carrier solutions. SPME is expected to be mainly used for protection
purpose 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 bandwidth by label stacking
and managing objects by layer stacking and address management. A on- and managing objects by layer stacking and address management. A on-
demand/temporal configuration of SPME is one of the possible demand/temporal configuration of SPME is one of the possible
approaches for minimizing the impact of these issues. However, the approaches for minimizing the impact of these issues. However, the
current method is unfavorable because the temporal configuration for current method is unfavorable because the temporal configuration for
monitoring can change the condition of the original monitored monitoring can change the condition of the original monitored
transport path( and disrupt the in-service customer traffic). From transport path. To avoid the drawbacks discussed above, a more
the perspective of monitoring in transport network operation, a efficient approach is required for MPLS-TP transport network
solution avoiding those issues or minimizing their impact is operation to overcome or minimize the impact of the above described
required. Another monitoring mechanism is therefore required that drawbacks. A monitoring mechanism, named on-demand Enhanced Path
supports temporal and hitless path segment monitoring. Hereafter it Segment Monitoring (EPSM), supporting temporal and hitless path
is called on-demand hitless path segment monitoring (HPSM). segment monitoring is proposed.
Note: The above sentence "and disrupt the in-service customer 5. OAM functions supported in segment monitoring
traffic" might need to be modified depending on the result of future
discussion about (P'-2).
5. OAM functions using segment monitoring OAM functions that may useful exploited across on-demand EPSM are
basically limited to on-demand performance monitoring functions which
are defined in OAM framework document RFC 6371 [RFC6371]. Segment
performance monitoring is used to evaluate the performance and hence
the status of transport path segments. The "on-demand" attribute is
generally temporal for maintenance operation.
OAM functions in which on-demand HPSM is required are basically Packet loss and packet delay are OAM functions strongly required in
limited to on-demand monitoring which are defined in OAM framework hitless and temporal segment monitoring because these functions are
document RFC 6371 [RFC6371], because those segment monitoring supported only between end points of a transport path. If a defect
functions are used to locate the fault/degraded point or to diagnose occurs, it might be quite hard to locate the defect or degradation
the status for detailed analyses, especially when a problem occurred. point without using the segment monitoring function. If an operator
In other words, the characteristic of "on-demand" is generally cannot locate or narrow the cause of the fault, it is quite difficult
temporal for maintenance operation. Conversely, this could be a good to take prompt actions to solve the problem.
reason that operations should not be based on pre-configuration and
pre-design.
Packet loss and packet delay measurements are OAM functions in which Other on-demand monitoring functions, (e.g. and Delay variation
hitless and temporal segment monitoring are strongly required because measurement) are desirable but not as necessary as the previous
these functions are supported only between end points of a transport mentioned functions.
path. If a fault or defect occurs, there is no way to locate the
defect or degradation point without using the segment monitoring
function. If an operator cannot locate or narrow the cause of the
fault, it is quite difficult to take prompt action to solve the
problem. Therefore, on-demand HPSM for packet loss and packet delay
measurements are indispensable for transport network operation.
Regarding other on-demand monitoring functions path segment Regarding out-of-service on-demand performance management functions
monitoring is desirable, but not as urgent as for packet loss and (e.g. Throughput measurement), there seems no need for EPSM.
packet delay measurements. However, OAM functions specifically designed for segment monitoring
should be developed to satisfy network objective (2) described in
section 3.
Regarding out-of-service on-demand monitoring functions, such as Finally, the solution for EPSM has to cover both per-node model and
diagnostic tests, there seems no need for HPSM. However, specific per- interface model which are specified in RFC 6371 [RFC6371].
segment monitoring should be applied to the OAM function of
diagnostic test, because SPME doesn't meet network objective (2) in
section 3. See section 6.3.
Note: 6. Requirements for enhanced segment monitoring
The solution for temporal and hitless segment monitoring should In the following clauses, mandatory (M) and optional (O) requirements
not be limited to label stacking mechanisms based on pre- are for the new segment monitoring function are listed.
configuration, such as PST/TCM(label stacking), which can cause
the issues (P-1) and (P-2) described in Section 4.
The solution for HPSM has to cover both per-node model and per- 6.1. Non intrusive segment monitoring
interface model which are specified in RFC 6371 [RFC6371].
6. Further consideration of requirements for enhanced segmentmonitoring One of the major problem of legacy SPME that has been highlighted in
Sec. 4 is that it does not monitor the original transport path and it
could distrupt service traffic when set-up on demand.
6.1. Necessity of on-demand single-level monitoring (M1) EPSM must not change the original condition of transport path
(e.g. must not change the lenght of MPLS frames, the exposed label
values, etc.)
(M2) EPSM must be set on demand without traffic dispruption
6.2. Single and multiple levels monitoring
The new segment monitoring function is supposed to be applied mainly The new segment monitoring function is supposed to be applied mainly
for diagnostic purpose on-demand. We can differentiate this for on-demand diagnostic purpose. We can differentiate this
monitoring from the proactive segment monitoring as on-demand multi- monitoring from the proactive segment monitoring as on-demand multi-
level monitoring. The most serious problem at the moment is that level monitoring. The most serious problem at the moment is that
there is no way to localize the degradation point on a path without there is no way to localize the degraded portion of a path without
changing the conditions of the original path. Therefore, as a first changing the conditions of the original path. Therefore, as a first
step, single layer segment monitoring not affecting the monitored step, single layer segment monitoring not affecting the monitored
path is required for a new on-demand and hitless segment monitoring path is required for a new on-demand and hitless segment monitoring
function. function. A combination of multi-level and simultaneous segment
monitoring is the most powerful tool for accurately diagnosing the
performance of a transport path. However, on field, a single level
approach may be enough.
A combination of multi-level and simultaneous monitoring is the most (M3) Single-level segment monitoring is required
powerful tool for accurately diagnosing the performance of a
transport path. However, considering the substantial benefits to
operators, a strict monitoring function which is required in such as
a test environment of a laboratory does not seem to be necessary in
the field. To summarize, on-demand and in-service (hitless) single-
level segment monitoring is required, on-demand and in-service multi-
level segment monitoring is desirable. Figure 2 shows an example of
a multi-level on-demand segment monitoring.
--- --- --- --- --- (O1) Multi-level segment monitoring is desirable
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= End-to-end monitoring
*------------------* <= segment monitoring level1
*-------------* <= segment monitoring level2
*-* <= segment monitoring level3
Figure 2: An Example of a multi-level on-demand segment monitoring Figure 2 shows an example of a multi-level on-demand segment
monitoring.
6.2. Necessity of on-demand monitoring independent from end-to-end --- --- --- --- ---
proactive monitoring | | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
*------------------* <=On-demand segm. monit. level 1
*-------------* <=On-demand segm. monit. level 2
*-* <=On-demand segm. monit. level 3
As multi-level simultaneous monitoring only for on-demand new path Figure 2: Example of multi-level on-demand segment monitoring
segment monitoring was already discussed in section6.1, next we
consider the necessity of simultaneous monitoring of end-to-end
current proactive monitoring and new on-demand path segment
monitoring. Normally, the on-demand path segment monitoring is
configured in a segment of a maintenance entity of a transport path.
In this environment, on-demand single-level monitoring should be done
without disrupting pro-active monitoring of the targeted end- to-end
transport path.
If operators have to disable the pro-active monitoring during the on- 6.3. EPSM and end-to-end proactive monitoring independence
demand hitless path segment monitoring, the network operation system
might miss any performance degradation of user traffic. This kind of
inconvenience should be avoided in the network operations.
Accordingly, the on-demand single lavel path segment monitoring is The necessity of simultaneous monitoring of current end-to-end
required without changing or interfering the proactive monitoring of proactive monitoring and new on-demand path segment monitoring is
the original end-to-end transport path. here below considered. Normally, the on-demand path segment
monitoring is configured in a segment of a maintenance entity of a
transport path. In such an environment, on-demand single-level
monitoring should be done without disrupting pro-active monitoring of
the targeted end- to-end transport path to avoid missing user traffic
performance monitoring.
Accordingly,
(M4) EPSM shall be established without changing or interfering
with the already in place end-to-end pro-active monitoring of
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 +-----------------------------+ <= Proactive E2E monitoring
*------------------* <= On-demand segment monitoring *------------------* <= On-demand segment monitoring
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.3. Necessity of arbitrary segment monitoring 6.4. Arbitrary segment monitoring
The main objective of on-demand segment monitoring is to diagnose the The main objective of on-demand segment monitoring is to diagnose the
fault points. One possible diagnostic procedure is to fix one end fault points. One possible realistic diagnostic procedure is to fix
point of a segment at the MEP of a transport path and change one end point of a segment at the MEP of the transport path under
progressively the length of the segment in order. This example is observation and change progressively the length of the segments.
shown in Fig. 4. This approach is considered as a common and This example is shown in Figure 4.
realistic diagnostic procedure. In this case, one end point of a
segment can be anchored at MEP at any time.
Other scenarios are also considered, one shown in Fig. 5. In this --- --- --- --- ---
case, the operators want to diagnose a transport path from a transit | | | | | | | | | |
node that is located at the middle, because the end nodes(A and E) | A | | B | | C | | D | | E |
are located at customer sites and consist of cost effective small box --- --- --- --- ---
in which a subset of OAM functions are supported. In this case, if MEP MEP <= ME of a transport path
one end point and an originator of the diagnostic packet are limited +-----------------------------+ <= Proactive E2E monitoring
to the position of MEP, on-demand segment monitoring will be *-----* <= 1st on-demand segment monitoring
ineffective because all the segments cannot be diagnosed (For *-------* <= 2nd on-demand segment monitoring
example, segment monitoring 3 in Fig.5 is not available and it is not *------------* <= 3rd on-demand segment monitoring
possible to localize the fault point). | |
| |
*-----------------------* <= 6th on-demand segment monitoring
*-----------------------------*<= 7th on-demand segment monitoring
--- --- --- --- --- Figure 4: A procedure to localize a defect by consecutive on-demand
| | | | | | | | | | segments monitoring
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive E2E monitoring
*-----* <= 1st On-demand segment
monitoring
*-------* <= 2nd On-demand segment
monitoring
*------------* <= 3rd On-demand segment
monitoring
|
|
*-----------------------* <= 6th On-demand segment
monitoring
*-----------------------------*<= 7th On-demand segment
monitoring
Figure 4: One possible procedure to localize a fault point by Another possible scenario is depicted in Figure 5. In this case, the
sequential on-demand segment monitoring operators want to diagnose a transport path from a transit node that
is located at the middle, because the end nodes(A and E) are located
at customer sites and consist of cost effective small box supporting
only a subset of OAM functions. In that case, if the source entities
of the diagnostic packets are limited to the position of MEPs, on-
demand segment monitoring will be ineffective because not all the
segments can be diagnosed (e.g. segment monitoring 3 in Figure 5 is
not available and it is not possible to precisely localize the fault
point).
Accordingly, on-demand monitoring of arbitrary segments is mandatory Accordingly,
in the case in Fig. 5. As a result, on-demand HSPM should be set in
an arbitrary segment of a transport path and diagnostic packets (M5) EPSM shall be set in an arbitrary segment of a transport path
should be inserted from at least any of intermediate maintenance and diagnostic packets should be inserted/terminated at any of
points of the original ME. 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 +-----------------------------+ <= Proactive E2E monitoring
*-----* <= On-demand segment monitoring 1 *-----* <= On-demand segment monitoring 1
*-----------------------*<= On-demand segment monitoring 2 *-----------------------*<= On-demand segment monitoring 2
*---------* <= On-demand segment monitoring 3 *---------* <= On-demand segment monitoring 3
Figure 5: Example where on-demand monitoring has to be configured in Figure 5: HSPM is configured at arbitrary segments
arbitrary segments
6.4. Fault during HPSM in case of protection 6.5. Fault while EPSM is in place
Node or link failures may occur during the HPSM is activated. In Node or link failures may occur while EPSM is active. In that case,
that case, the hitless path segment monitoring function should be if no resiliency mechanism is set-up on the subtended transport path,
suspended immediately and must not continue the monitoring on a new there is no particular requirement for EPSM while if the trasport
protected or restored path when a protection or restoration for the path is protected, EPSM function should be terminated to avoid
fault path is available. Therefore a solution of HPSM should avoid monitoring a new segment when a protection or restoration path is in
such a situation that a target node of the hitless segment monitoring place. Therefore
is changed to unintended node when failures occur on the segment.
Fig.6 and Fig.7 exemplify one of the examples that should be avoided. (M5) EPSM function should avoid monitoring an unintended segment
However, this example is just for clarification of the problem that when failures occur
should be avoided. It does not intend to restrict any solution for
meeting the requirements of HPSM. Protection scenario A is shown in
figure 6. In this scenario, a working LSP and a protection LSP are
separately set, in other words as independent LSPs. HPSM is set
between A and E. Therefore, considering the case that a fault
happens between B and C, the HPSM doesn't continue in a protected
path. As a result, there is no issue.
A - B -- C -- D - E - F The folowing examples are reported for clarification only and shall
\ / not be intended to restrict any solution for meeting the requirements
G - H 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
between A and E. Considering a fault happens between nodes B and C,
the EPSM is not affected by protection and continues in the working
LSP path. As a result, requirement (M5) is satisfied.
Where: A - B - C - D - E - F
\ /
G - H - I - L
Where:
- e2e 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-D-E-F - protection LSP: A-B-G-H-I-L-F
- HPSM: A-E - EPSM: A-E
--------------- ---------------
Figure 6: Protection scenario A having no issue when a fault happens Figure 6: Protection scenario A
on HPSMs
On the other hand, figure 7 shows a scenario where only a portion of Differently, figure 7 shows a scenario where only a portion of a
a transport path has different label assignments (sub-paths). In transport path is protected. In this case, when a fault happen
this case, when a fault condition is identified on working sub-path between node B and C along the working sub-path, traffic is switched
B-C-D, the sub-path is switched to protection sub-path B-G-H-D. As a to protection sub-path B-G-H-D. In the hypotesis that OAM packets
result, the target node of HPSM changes from E to D due to the termination depend only on TTL value of MPLS label header, the target
difference of hop counts between a route of working path(ABCDE: 4 node of EPSM changes from E to D due to the difference of hop counts
hops) and that of protection path(ABGHDE: 5 hops), because the between the working path route (ABCDE: 4 hops) and protection path
forwarding and processing of HPSM OAM packets depend only on TTL route (ABGHDE: 5 hops). As a result, requirement (M5) is not
value of MPLS label header. In this case, some additional mechanisms satisfied.
to notify the fault on working path to the source of HPSM may be
necessary to suspend the monitoring.
A - B -- C -- D - E - F A - B - C - D - E - F
\ / \ /
G - H G - H
- e2e LSP: A-B...D-E-F - e2e LSP: A-B-C-D-E-F
- working sub-path: B-C-D - working sub-path: B-C-D
- protection sub-path: B-G-H-D - protection sub-path: B-G-H-D
- HPSM: A-E - EPSM: A-E
--------------- ---------------
Figure 7: Protection scenario B having an issue when a fault happens Figure 7: Protection scenario B
on HPSM
6.5. Consideration of maintenance point for HPSM 6.6. EPSM maintenance points
An intermediate maintenance point supporting the HPSM has to be able An intermediate maintenance point supporting the EPSM has to be able
to generate and inject OAM packets. Although maintenance points for to generate and inject OAM packets. Although maintenance points for
the HPSM do not necessarily have to coincide with MIPs or MEPs in the EPSM do not necessarily have to coincide with MIPs or MEPs in
terms of the architecture definition, the same identifier for MIPs or terms of the architecture definition,
MEPs could be applied to maintenance points of the HPSM.
(M7) The same identifiers for MIPs and/or MEPs should be applied
to EPSM maintenance points
7. Summary 7. Summary
An enhanced monitoring mechanism is required to support temporal and An enhanced monitoring mechanism is required to support temporal and
hitless segment monitoring which meets the two network objectives hitless segment monitoring which meets the two network objectives
mentioned in Section 3 of this document that are described also in described in section 3.8 of RFC 6371 [RFC6371] and reported in
section 3.8 of RFC 6371 [RFC6371]. Section 3 of this document.
The enhancements should minimize the issues described in Section 4, The enhancements should minimize the issues described in Section 4,
i.e., P-1, P-2, P'-1( and P'-2), to meet those two network i.e., P-1, P-2, P-3 and P-4.
objectives.
The solution for the temporal and hitless segment monitoring has to The solution for the temporal and hitless segment monitoring has to
cover both per-node model and per-interface model which are specified cover both per-node model and per-interface model which are specified
in RFC 6371 [RFC6371]. In addition, the following requirements in RFC 6371 [RFC6371].
should be considered for an enhanced temporal and hitless path
segment monitoring function:
o "On-demand and in-service" single level segment should be done
without changing or interfering any condition of pro-active
monitoring of an original ME of a transport path.
o On-demand and in-service segment monitoring should be able to be
set in an arbitrary segment of a transport path.
The temporal and hitless segment monitoring solutions is applicable The temporal and hitless segment monitoring solutions shall support
to and needs to support several on-demand OAM functions, as follows: on-demand Packet Loss Measurement and Packet Delay Measurement
Mandatory: Packet Loss Measurement and Packet Delay Measurement functions and optionally other performance monitoring /fault
Optional: Connectivity Verification, Diagnostic Tests (Throughput management functions (e.g. Throughput measurement, Delay variation
test), and Route Tracing. measurement, Diagnostic test measurement, 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 15, line 39 skipping to change at page 14, line 39
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, Italo Busi, Maarten Vissers,
Malcolm Betts, Nurit Sprecher and Jia He for their comments and Malcolm Betts, Nurit Sprecher and Jia He 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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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, January 2001. Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
Operations, Administration, and Maintenance (OAM) in MPLS "Requirements for Operations, Administration, and
Transport Networks", RFC 5860, May 2010. Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
Berger, "A Framework for MPLS in Transport Networks", RFC L., and L. Berger, "A Framework for MPLS in Transport
5921, July 2010. Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Maintenance Framework for MPLS-Based Transport Networks", Administration, and Maintenance Framework for MPLS-Based
RFC 6371, September 2011. Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
TP) Survivability Framework", RFC 6372, September 2011. Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<http://www.rfc-editor.org/info/rfc6372>.
Authors' Addresses Authors' Addresses
Alessandro D'Alessandro Alessandro D'Alessandro
Telecom Italia Telecom Italia
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 Manuel Paul
Deutsche Telekom Deutsche Telekom
Email: Manuel.Paul@telekom.de Email: Manuel.Paul@telekom.de
Satoshi Ueno Satoshi Ueno
NTT 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: koike.yoshinori@lab.ntt.co.jp
 End of changes. 98 change blocks. 
384 lines changed or deleted 326 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/