draft-ietf-mpls-tp-temporal-hitless-psm-05.txt   draft-ietf-mpls-tp-temporal-hitless-psm-06.txt 
MPLS Working Group A. D'Alessandro
Internet Draft Telecom Italia
M.Paul
Deutsche Telekom
Intended status: Informational S. Ueno
NTT Communications
K.Arai
Y.Koike
NTT
Expires: July 30, 2014 January 31, 2014 Network Working Group A. D'Alessandro
Internet-Draft Telecom Italia
Intended status: Standards Track L. Andersson
Expires: August 30, 2015 Huawei Technologies
M. Paul
Deutsche Telekom
S. Ueno
K. Arai
Y. Koike
NTT
February 26, 2015
Temporal and hitless path segment monitoring Temporal and hitless path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-05.txt draft-ietf-mpls-tp-temporal-hitless-psm-06.txt
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with The MPLS transport profile (MPLS-TP) is being standardized to enable
the provisions of BCP 78 and BCP 79. carrier-grade packet transport and complement converged packet
network deployments. Among the most attractive features of MPLS-TP
are OAM functions, which enable network operators or service
providers to provide various maintenance characteristics, such as
fault location, survivability, performance monitoring, and
preliminary or in-service measurements.
Internet-Drafts are working documents of the Internet Engineering One of the most important mechanisms which is common for transport
Task Force (IETF), its areas, and its working groups. Note that network operation is fault location. A segment monitoring function
other groups may also distribute working documents as Internet- of a transport path is effective in terms of extension of the
Drafts. maintenance work and indispensable particularly when the OAM function
is effective only between end points. However, the current approach
defined for MPLS-TP for the segment monitoring (SPME) has some fatal
drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provides monitoring of a
portion of a set of transport paths (LSPs or MS-PWs). Based on the
problems, this document specifies new requirements to consider a new
improved mechanism of hitless transport path segment monitoring.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft is submitted in full conformance with the
http://www.ietf.org/ietf/1id-abstracts.txt provisions of BCP 78 and BCP 79.
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/shadow.html Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
This Internet-Draft will expire on July 30, 2014. Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2011 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.
Abstract
The MPLS transport profile (MPLS-TP) is being standardized to enable
carrier-grade packet transport and complement converged packet
network deployments. Among the most attractive features of MPLS-TP
are OAM functions, which enable network operators or service
providers to provide various maintenance characteristics, such as
fault location, survivability, performance monitoring, and
preliminary or in-service measurements.
One of the most important mechanisms which is common for transport
network operation is fault location. A segment monitoring function
of a transport path is effective in terms of extension of the
maintenance work and indispensable particularly when the OAM
function is effective only between end points. However, the current
approach defined for MPLS-TP for the segment monitoring (SPME) has
some fatal drawbacks. This document elaborates on the problem
statement for the Sub-path Maintenance Elements (SPMEs) which
provides monitoring of a portion of a set of transport paths (LSPs
or MS-PWs). Based on the problems, this document specifies new
requirements to consider a new improved mechanism of hitless
transport path segment monitoring.
This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunications Union
Telecommunications Standardization Sector (ITU-T) effort to include
an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of a
packet transport network.
Table of Contents Table of Contents
1. Introduction ................................................ 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document ............................ 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Terminology ............................................ 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definitions ............................................ 5 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network objectives for monitoring ............................ 5 3. Network objectives for monitoring . . . . . . . . . . . . . . 4
4. Problem statement ........................................... 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. OAM functions using segment monitoring ...................... 10 5. OAM functions using segment monitoring . . . . . . . . . . . 9
6. Further consideration of requirements for enhanced segment 6. Further consideration of requirements for enhanced
monitoring .................................................. 1110 segmentmonitoring . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Necessity of on-demand single-level monitoring.......... 11 6.1. Necessity of on-demand single-level monitoring . . . . . 10
6.2. Necessity of on-demand monitoring independent from end-to- 6.2. Necessity of on-demand monitoring independent from end-
end proactive monitoring .................................. 1211 to-end proactive monitoring . . . . . . . . . . . . . . . 10
6.3. Necessity of arbitrary segment monitoring .............. 12 6.3. Necessity of arbitrary segment monitoring . . . . . . . 11
6.4. Fault during HPSM in case of protection .............. 1413 6.4. Fault during HPSM in case of protection . . . . . . . . . 13
7. Summary .................................................. 1615 6.5. Consideration of maintenance point for HPSM . . . . . . . 14
8. Security Considerations ..................................... 16 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations ........................................ 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References ................................................ 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References .................................. 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References .............................. 1716 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments ......................................... 1716 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
A packet transport network will enable carriers or service providers A packet transport network will enable carriers or service providers
to use network resources efficiently, reduce operational complexity to use network resources efficiently, reduce operational complexity
and provide carrier-grade network operation. Appropriate maintenance and provide 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 Unlike in SDH or OTN networks, where OAM is an inherent part of every
every frame and frames are also transmitted in idle mode, it is not frame and frames are also transmitted in idle mode, it is not per se
per se possible to constantly monitor the status of individual possible to constantly monitor the status of individual connections
connections in packet networks. Packet-based OAM functions are in packet networks. Packet-based OAM functions are flexible and
flexible and selectively configurable according to operators' needs. selectively configurable according to operators' needs.
According to the MPLS-TP OAM requirements [1], mechanisms MUST be According to the MPLS-TP OAM requirements RFC 5860 [RFC5860],
available for alerting a service provider of a fault or defect mechanisms MUST be available for alerting a service provider of a
affecting the service(s) provided. In addition, to ensure that fault or defect affecting the service(s) provided. In addition, to
faults or degradations can be localized, operators need a method to ensure that faults or degradations can be localized, operators need a
analyze or investigate the problem. From the fault localization method to analyze or investigate the problem. From the fault
perspective, end-to-end monitoring is insufficient. Using end-to-end localization perspective, end-to-end monitoring is insufficient.
OAM monitoring, when one problem occurs in an MPLS-TP network, the Using end-to-end OAM monitoring, when one problem occurs in an MPLS-
operator can detect the fault, but is not able to localize it. 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 focusing on and selecting 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[5], perform this task. However, as noted in the MPLS-TP OAM Framework
the current method for segment monitoring function of a transport RFC 6371 [RFC6371], the current method for segment monitoring
path has implications that hinder the usage in an operator network. function of a transport path has implications that hinder the usage
in an operator network.
This document elaborates on the problem statement for the path 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 [5]. method of the segment monitoring, following up the work done in RFC
Moreover, this document explains detailed requirements on the new 6371 [RFC6371]. Moreover, this document explains detailed
temporal and hitless segment monitoring function which are not requirements on the new temporal and hitless segment monitoring
covered in [5]. function which are 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 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.1. Terminology 2.1. Terminology
HPSM Hitless Path Segment Monitoring HPSM - Hitless Path Segment Monitoring
LSP Label Switched Path LSP - Label Switched Path
LSR Label Switching Router LSR - Label Switching Router
ME Maintenance Entity ME - Maintenance Entity
MEG Maintenance Entity Group MEG - Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP - Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP - Maintenance Entity Group Intermediate Point
OTN Optical Transport Network OTN - Optical Transport Network
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 monitoring 3. Network objectives for monitoring
There are two indispensable network objectives for MPLS-TP networks There are two indispensable network objectives for MPLS-TP networks
as described in section 3.8 of [5]. 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 It is common in transport networks that network objective (1) is
mandatory and that regarding network objective (2) the monitoring mandatory and that regarding network objective (2) the monitoring
shall not change the forwarding behavior. shall not change the forwarding behavior.
4. Problem statement 4. Problem Statement
To monitor, protect, or manage portions of transport paths, such as To monitor, protect, or manage portions of transport paths, such as
LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is
defined in [2]. The SPME is defined between the edges of the portion defined in RFC 5921 [RFC5921]. The SPME is defined between the edges
of the transport path that needs to be monitored, protected, or of the portion of the transport path that needs to be monitored,
managed. This SPME is created by stacking the shim header (MPLS protected, or managed. This SPME is created by stacking the shim
header)[3] and is defined as the segment where the header is stacked. header (MPLS header) RFC 3031 [RFC3031] and is defined as the segment
OAM messages can be initiated at the edge of the SPME and sent to where the header is stacked. OAM messages can be initiated at the
the peer edge of the SPME or to a MIP along the SPME by setting the edge of the SPME and sent to the peer edge of the SPME or to a MIP
TTL value of the label stack entry (LSE) and interface identifier along the SPME by setting the TTL value of the label stack entry
value at the corresponding hierarchical LSP level in case of per-node (LSE) and interface identifier value at the corresponding
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 general issues, which are fatal in
terms of cost and operation. terms of cost and operation.
(P-1) Increasing the overhead by the stacking of shim header(s) (P-1) Increasing the overhead by the stacking of shim header(s)
(P-2) Increasing the address management complexity, as new MEPs and (P-2) Increasing the address management complexity, as new MEPs
MIPs need to be configured for the SPME in the old MEG and MIPs need to be configured for the SPME in the old MEG
Problem (P-1) leads to decreased efficiency as bandwidth is wasted Problem (P-1) leads to decreased efficiency as bandwidth is wasted
only for maintenance purposes. As the size of monitored segments only for maintenance purposes. As the size of monitored segments
increases, the size of the label stack grows. Moreover, if the increases, the size of the label stack grows. Moreover, if the
operator wants to monitor the portion of a transport path without operator wants to monitor the portion of a transport path without
service disruption, one or more SPMEs have to be set in advance service disruption, one or more SPMEs have to be set in advance until
until the end of life of a transport path, which is not temporal or the end of life of a transport path, which is not temporal or on-
on-demand. Consuming additional bandwidth permanently for only the demand. Consuming additional bandwidth permanently for only the
monitoring purpose should be avoided to maximize the available monitoring purpose should be avoided to maximize the available
bandwidth. bandwidth.
Problem (P-2) is related to an identifier-management issue. The Problem (P-2) is related to an identifier-management issue. The
identification of each layer in case of LSP label stacking is identification of each layer in case of LSP label stacking is
required in terms of strict sub-layer management for the segment required in terms of strict sub-layer management for the segment
monitoring in a MPLS-TP network. When SPME/TCM is applied for on- 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 demand OAM functions in MPLS-TP networks in a similar manner to OTN
or Ethernet transport networks, a possible rule of differentiating or Ethernet transport networks, a possible rule of differentiating
those SPME/TCMs operationally will be necessary at least within an those SPME/TCMs operationally will be necessary at least within an
administrative domain. This enforces operators to create an administrative domain. This enforces operators to create an
additional permanent layer identification policy only for temporal additional permanent layer identification policy only for temporal
path segment monitoring. Moreover, from the perspective of operation, path segment monitoring. Moreover, from the perspective of
increasing the managed addresses and the managed layer is not operation, increasing the managed addresses and the managed layer is
desirable in terms of simplified operation featured by current not desirable in terms of simplified operation featured by current
transport networks. Reducing the managed identifiers and managed transport networks. Reducing the managed identifiers and managed
layers should be the fundamental direction in designing the layers should be the fundamental direction in designing the
architecture. architecture.
The most familiar example for SPME in transport networks is Tandem The most familiar example for SPME in transport networks is Tandem
Connection Monitoring (TCM), which can for example be used for a Connection Monitoring (TCM), which can for example be used for a
carrier's carrier solution, as shown in Fig. 17 of the framework carrier's carrier solution, as shown in Fig. 17 of the framework
document[2]. However, in this case, the SPMEs have to be pre- document RFC 5921 [RFC5921]. However, in this case, the SPMEs have
configured. If this solution is applied to specific segment to be pre-configured. If this solution is applied to specific
monitoring within one operator domain, all the necessary specific segment monitoring within one operator domain, all the necessary
segments have to be pre-configured. This setting increases the specific segments have to be pre-configured. This setting increases
managed objects as well as the necessary bandwidth, shown as Problem the managed objects as well as the necessary bandwidth, shown as
(P-1) and (P-2). Moreover, as a result of these pre-configurations, Problem (P-1) and (P-2). Moreover, as a result of these pre-
they impose operators to pre-design the structure of sub-path configurations, they impose operators to pre-design the structure of
maintenance elements, which is not preferable in terms of operators' sub-path maintenance elements, which is not preferable in terms of
increased burden. These concerns are summarized in section 3.8 of operators' increased burden. These concerns are summarized in
[5]. section 3.8 of RFC 6371 [RFC6371].
Furthermore, in reality, all the possible patterns of path segment Furthermore, in reality, all the possible patterns of path segment
cannot be set in SPME, because overlapping of path segments is cannot be set in SPME, because overlapping of path segments is
limited to nesting relationship. As a result, possible SPME patterns limited to nesting relationship. As a result, possible SPME patterns
of portions of an original transport path are limited due to the of portions of an original transport path are limited due to the
characteristic of SPME shown in Figure.1, even if SPMEs are pre- characteristic of SPME shown in Figure.1, even if SPMEs are pre-
configured. This restriction is inconvenient when operators have to configured. This restriction is inconvenient when operators have to
fix issues in an on-demand manner. To avoid these issues, the fix issues in an on-demand manner. To avoid these issues, the
temporal and on-demand setting of the SPME(s) is needed and more temporal and on-demand setting of the SPME(s) is needed and more
efficient for monitoring in MPLS-TP transport network operation. efficient for monitoring in MPLS-TP transport network operation.
However, using currently defined methods, the temporal setting of However, using currently defined methods, the temporal setting of
SPMEs also causes the following problems due to label stacking, SPMEs also causes the following problems due to label stacking, which
which are fatal in terms of intrinsic monitoring and service are fatal in terms of intrinsic monitoring and service disruption.
disruption.
(P'-1) Changing the condition of the original transport path by (P'-1) Changing the condition of the original transport path by
changing the length of all the MPLS frames and changing label changing the length of all the MPLS frames and changing label
value(s) value(s)
(P'-2) Disrupting client traffic over a transport path, if the SPME (P'-2) Disrupting client traffic over a transport path, if the
is temporally configured. SPME is temporally configured.
Problem (P'-1) is a fatal problem in terms of intrinsic monitoring. Problem (P'-1) is a fatal problem in terms of intrinsic monitoring.
As shown in network objective (2), the monitoring function needs to As shown in network objective (2), the monitoring function needs to
monitor the status without changing any conditions of the targeted monitor the status without changing any conditions of the targeted
monitored segment or the transport path. If the conditions of the monitored segment or the transport path. If the conditions of the
transport path change, the measured value or observed data will also transport path change, the measured value or observed data will also
change. This can make the monitoring meaningless because the result change. This can make the monitoring meaningless because the result
of the monitoring would no longer reflect the reality of the of the monitoring would no longer reflect the reality of the
connection where the original fault or degradation occurred. connection where the original fault or degradation occurred.
Another aspect is that changing the settings of the original shim Another aspect is that changing the settings of the original shim
header should not be allowed because those changes correspond to header should not be allowed because those changes correspond to
creating a new portion of the original transport path, which differs creating a new portion of the original transport path, which differs
from the original data plane conditions. from the original data plane conditions.
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 one label 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 Fig.1, SPME changes the length of all
the MPLS frames and changes label value(s). This is no longer the the MPLS frames and changes label value(s). This is no longer the
monitoring of the original transport path but the monitoring of a monitoring of the original transport path but the monitoring of a
different path. Particularly, performance monitoring measurement different path. Particularly, performance monitoring measurement
(Delay measurement and loss measurement) are sensitive to those (Delay measurement and 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
MEP \ / MEP <= transport path MEP \ / MEP <= transport path
--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'-2) was not fully discussed, although the make-before-
break procedure in the survivability document [4] seemingly supports break procedure in the survivability document RFC 6371 [RFC6372]
the hitless configuration for monitoring according to the framework seemingly supports the hitless configuration for monitoring according
document [2]. The reality is the hitless configuration of SPME is to the framework document RFS 5921 [RFC5921]. The reality is the
impossible without affecting the conditions of the targeted hitless configuration of SPME is impossible without affecting the
transport path, because the make-before-break procedure is premised conditions of the targeted transport path, because the make-before-
on the change of the inner label value. This means changing one of break procedure is premised on the change of the inner label value.
the settings in MPLS shim header. This means changing one of the settings in MPLS shim header.
Moreover, this might not be effective under the static model without Moreover, this might not be effective under the static model without
a control plane because the make-before-break is a restoration a control plane because the make-before-break is a restoration
application based on the control plane. The removal of SPME whose application based on the control plane. The removal of SPME whose
segment is monitored could have the same impact (disruption of segment is monitored could have the same impact (disruption of client
client traffic) as the creation of an SPME on the same LSP. traffic) as the creation of an SPME on the same LSP.
Note: (P'-2) will be removed when non-disruptive make-before-break Note: (P'-2) will be removed when non-disruptive make-before-break
(in both with and without Control Plane environment) is specified in (in both with and without Control Plane environment) is specified in
other MPLS-TP documents. However, (P'-2) could be replaced with the other MPLS-TP documents. However, (P'-2) could be replaced with the
following issue. Non-disruptive make-before-break, in other words, following issue. Non-disruptive make-before-break, in other words,
taking an action similar to switching just for monitoring is not an taking an action similar to switching just for monitoring is not an
ideal operation in transport networks. ideal operation in transport networks.
The other potential risks are also envisaged. Setting up a temporal The other potential risks are also envisaged. Setting up a temporal
SPME will result in the LSRs within the monitoring segment only SPME will result in the LSRs within the monitoring segment only
looking at the added (stacked) labels and not at the labels of the looking at the added (stacked) labels and not at the labels of the
original LSP. This means that problems stemming from incorrect (or original LSP. This means that problems stemming from incorrect (or
unexpected) treatment of labels of the original LSP by the nodes unexpected) treatment of labels of the original LSP by the nodes
within the monitored segment could not be found when setting up SPME. within the monitored segment could not be found when setting up SPME.
This might include hardware problems during label look-up, mis- This 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( and disrupt the in-service customer traffic). From
the perspective of monitoring in transport network operation, a the perspective of monitoring in transport network operation, a
solution avoiding those issues or minimizing their impact is solution avoiding those issues or minimizing their impact is
required. Another monitoring mechanism is therefore required that required. Another monitoring mechanism is therefore required that
supports temporal and hitless path segment monitoring. Hereafter it supports temporal and hitless path segment monitoring. Hereafter it
is called on-demand hitless path segment monitoring (HPSM). is called on-demand hitless path segment monitoring (HPSM).
Note: The above sentence "and disrupt the in-service customer Note: The above sentence "and disrupt the in-service customer
traffic" might need to be modified depending on the result of future traffic" might need to be modified depending on the result of future
discussion about (P'-2). discussion about (P'-2).
5. OAM functions using segment monitoring 5. OAM functions using segment monitoring
OAM functions in which on-demand HPSM is required are basically OAM functions in which on-demand HPSM is required are basically
limited to on-demand monitoring which are defined in OAM framework limited to on-demand monitoring which are defined in OAM framework
document [5], because those segment monitoring functions are used to document RFC 6371 [RFC6371], because those segment monitoring
locate the fault/degraded point or to diagnose the status for functions are used to locate the fault/degraded point or to diagnose
detailed analyses, especially when a problem occurred. In other the status for detailed analyses, especially when a problem occurred.
words, the characteristic of "on-demand" is generally temporal for In other words, the characteristic of "on-demand" is generally
maintenance operation. Conversely, this could be a good reason that temporal for maintenance operation. Conversely, this could be a good
operations should not be based on pre-configuration and pre-design. reason that operations should not be based on pre-configuration and
pre-design.
Packet loss and packet delay measurements are OAM functions in which Packet loss and packet delay measurements are OAM functions in which
hitless and temporal segment monitoring are strongly required hitless and temporal segment monitoring are strongly required because
because these functions are supported only between end points of a these functions are supported only between end points of a transport
transport path. If a fault or defect occurs, there is no way to path. If a fault or defect occurs, there is no way to locate the
locate the defect or degradation point without using the segment defect or degradation point without using the segment monitoring
monitoring function. If an operator cannot locate or narrow the function. If an operator cannot locate or narrow the cause of the
cause of the fault, it is quite difficult to take prompt action to fault, it is quite difficult to take prompt action to solve the
solve the problem. Therefore, on-demand HPSM for packet loss and problem. Therefore, on-demand HPSM for packet loss and packet delay
packet delay measurements are indispensable for transport network measurements are indispensable for transport network operation.
operation.
Regarding other on-demand monitoring functions path segment Regarding other on-demand monitoring functions path segment
monitoring is desirable, but not as urgent as for packet loss and monitoring is desirable, but not as urgent as for packet loss and
packet delay measurements. packet delay measurements.
Regarding out-of-service on-demand monitoring functions, such as Regarding out-of-service on-demand monitoring functions, such as
diagnostic tests, there seems no need for HPSM. However, specific diagnostic tests, there seems no need for HPSM. However, specific
segment monitoring should be applied to the OAM function of segment monitoring should be applied to the OAM function of
diagnostic test, because SPME doesn't meet network objective (2) in diagnostic test, because SPME doesn't meet network objective (2) in
section 3. See section 6.3. section 3. See section 6.3.
Note: Note:
The solution for temporal and hitless segment monitoring should not The solution for temporal and hitless segment monitoring should
be limited to label stacking mechanisms based on pre-configuration, not be limited to label stacking mechanisms based on pre-
such as PST/TCM(label stacking), which can cause the issues (P-1) configuration, such as PST/TCM(label stacking), which can cause
and (P-2) described in Section 4. the issues (P-1) and (P-2) described in Section 4.
The solution for HPSM has to cover both per-node model and per- The solution for HPSM has to cover both per-node model and per-
interface model which are specified in [5]. interface model which are specified in RFC 6371 [RFC6371].
6. Further consideration of requirements for enhanced segment 6. Further consideration of requirements for enhanced segmentmonitoring
monitoring
6.1. Necessity of on-demand single-level monitoring 6.1. Necessity of on-demand single-level 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 diagnostic purpose on-demand. 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 degradation point on 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 monitoring is the most A combination of multi-level and simultaneous monitoring is the most
powerful tool for accurately diagnosing the performance of a powerful tool for accurately diagnosing the performance of a
transport path. However, considering the substantial benefits to transport path. However, considering the substantial benefits to
operators, a strict monitoring function which is required in such as operators, a strict monitoring function which is required in such as
a test environment of a laboratory does not seem to be necessary in a test environment of a laboratory does not seem to be necessary in
the field. To summarize, on-demand and in-service (hitless) single- the field. To summarize, on-demand and in-service (hitless) single-
level segment monitoring is required, on-demand and in-service level segment monitoring is required, on-demand and in-service multi-
multi-level segment monitoring is desirable. Figure 2 shows an level segment monitoring is desirable. Figure 2 shows an example of
example of a multi-level on-demand segment monitoring. a multi-level on-demand segment monitoring.
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| A | | B | | C | | D | | E | | A | | B | | C | | D | | E |
--- --- --- --- --- --- --- --- --- ---
MEP MEP <= ME of a transport path MEP MEP <= ME of a transport path
+-----------------------------+ <= End-to-end monitoring +-----------------------------+ <= End-to-end monitoring
*------------------* <= segment monitoring level1 *------------------* <= segment monitoring level1
*-------------* <= segment monitoring level2 *-------------* <= segment monitoring level2
*-* <= segment monitoring level3 *-* <= segment monitoring level3
Figure 2 : An Example of a multi-level on-demand segment monitoring Figure 2: An Example of a multi-level on-demand segment monitoring
6.2. Necessity of on-demand monitoring independent from end-to-end 6.2. Necessity of on-demand monitoring independent from end-to-end
proactive monitoring proactive monitoring
As multi-level simultaneous monitoring only for on-demand new path As multi-level simultaneous monitoring only for on-demand new path
segment monitoring was already discussed in section6.1, next we segment monitoring was already discussed in section6.1, next we
consider the necessity of simultaneous monitoring of end-to-end consider the necessity of simultaneous monitoring of end-to-end
current proactive monitoring and new on-demand path segment current proactive monitoring and new on-demand path segment
monitoring. Normally, the on-demand path segment monitoring is monitoring. Normally, the on-demand path segment monitoring is
configured in a segment of a maintenance entity of a transport path. configured in a segment of a maintenance entity of a transport path.
In this environment, on-demand single-level monitoring should be In this environment, on-demand single-level monitoring should be done
done without disrupting pro-active monitoring of the targeted end- without disrupting pro-active monitoring of the targeted end- to-end
to-end transport path. transport path.
If operators have to disable the pro-active monitoring during the If operators have to disable the pro-active monitoring during the on-
on-demand hitless path segment monitoring, the network operation demand hitless path segment monitoring, the network operation system
system might miss any performance degradation of user traffic. This might miss any performance degradation of user traffic. This kind of
kind of inconvenience should be avoided in the network operations. inconvenience should be avoided in the network operations.
Accordingly, the on-demand single lavel path segment monitoring is Accordingly, the on-demand single lavel path segment monitoring is
required without changing or interfering the proactive monitoring of required without changing or interfering the proactive monitoring of
the original end-to-end transport path. the original end-to-end 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.3. Necessity of arbitrary segment monitoring
The main objective of on-demand segment monitoring is to diagnose The main objective of on-demand segment monitoring is to diagnose the
the fault points. One possible diagnostic procedure is to fix one fault points. One possible diagnostic procedure is to fix one end
end point of a segment at the MEP of a transport path and change point of a segment at the MEP of a transport path and change
progressively the length of the segment in order. This example is progressively the length of the segment in order. This example is
shown in Fig. 4. This approach is considered as a common and shown in Fig. 4. This approach is considered as a common and
realistic diagnostic procedure. In this case, one end point of a realistic diagnostic procedure. In this case, one end point of a
segment can be anchored at MEP at any time. segment can be anchored at MEP at any time.
Other scenarios are also considered, one shown in Fig. 5. In this Other scenarios are also considered, one shown in Fig. 5. In this
case, the operators want to diagnose a transport path from a transit 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) 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 are located at customer sites and consist of cost effective small box
box in which a subset of OAM functions are supported. In this case, in which a subset of OAM functions are supported. In this case, if
if one end point and an originator of the diagnostic packet are one end point and an originator of the diagnostic packet are limited
limited to the position of MEP, on-demand segment monitoring will be to the position of MEP, on-demand segment monitoring will be
ineffective because all the segments cannot be diagnosed (For ineffective because all the segments cannot be diagnosed (For
example, segment monitoring 3 in Fig.5 is not available and it is example, segment monitoring 3 in Fig.5 is not available and it is not
not possible to localize the fault point). possible to localize the fault point).
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| 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
*-----* <= 1st On-demand segment *-----* <= 1st On-demand segment
monitoring monitoring
*-------* <= 2nd On-demand segment *-------* <= 2nd On-demand segment
monitoring monitoring
*------------* <= 3rd On-demand segment *------------* <= 3rd On-demand segment
monitoring monitoring
| |
| |
*-----------------------* <= 6th On-demand segment *-----------------------* <= 6th On-demand segment
monitoring monitoring
*-----------------------------*<= 7th On-demand segment *-----------------------------*<= 7th On-demand segment
monitoring monitoring
Figure 4 : One possible procedure to localize a fault point by Figure 4: One possible procedure to localize a fault point by
sequential on-demand segment monitoring sequential on-demand segment monitoring
Accordingly, on-demand monitoring of arbitrary segments is mandatory Accordingly, on-demand monitoring of arbitrary segments is mandatory
in the case in Fig. 5. As a result, on-demand HSPM should be set in 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 an arbitrary segment of a transport path and diagnostic packets
should be inserted from at least any of intermediate maintenance should be inserted from at least any of intermediate maintenance
points of the original ME. 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 Figure 5: Example where on-demand monitoring has to be configured in
in arbitrary segments arbitrary segments
6.4. Fault during HPSM in case of protection 6.4. Fault during HPSM in case of protection
Node or link failures may occur during the HPSM is activated. In Node or link failures may occur during the HPSM is activated. In
that case, the hitless path segment monitoring function should be that case, the hitless path segment monitoring function should be
suspended immediately and must not continue the monitoring on a new suspended immediately and must not continue the monitoring on a new
protected or restored path when a protection or restoration for the protected or restored path when a protection or restoration for the
fault path is available. Therefore a solution of HPSM should avoid fault path is available. Therefore a solution of HPSM should avoid
such a situation that a target node of the hitless segment such a situation that a target node of the hitless segment monitoring
monitoring is changed to unintended node when failures occur on the is changed to unintended node when failures occur on the segment.
segment.
Fig.6 and Fig.7 exemplify one of the examples that should be avoided. Fig.6 and Fig.7 exemplify one of the examples that should be avoided.
However, this example is just for clarification of the problem that However, this example is just for clarification of the problem that
should be avoided. It does not intend to restrict any solution for should be avoided. It does not intend to restrict any solution for
meeting the requirements of HPSM. Protection scenario A is shown in meeting the requirements of HPSM. Protection scenario A is shown in
figure 6. In this scenario, a working LSP and a protection LSP are figure 6. In this scenario, a working LSP and a protection LSP are
separately set, in other words as independent LSPs. HPSM is set separately set, in other words as independent LSPs. HPSM is set
between A and E. Therefore, considering the case that a fault between A and E. Therefore, considering the case that a fault
happens between B and C, the HPSM doesn't continue in a protected happens between B and C, the HPSM doesn't continue in a protected
path. As a result, there is no issue. path. As a result, there is no issue.
A - B -- C -- D - E - F A - B -- C -- D - E - F
\ / \ /
G - H G - H
Where: Where:
- 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-D-E-F
- HPSM: A-E - HPSM: A-E
--------------- ---------------
Figure 6 : Protection scenario A having no issue when a fault Figure 6: Protection scenario A having no issue when a fault happens
happens on HPSM on HPSMs
On the other hand, figure 7 shows a scenario where only a portion of On the other hand, figure 7 shows a scenario where only a portion of
a transport path has different label assignments (sub-paths). In a transport path has different label assignments (sub-paths). In
this case, when a fault condition is identified on working sub-path this case, when a fault condition is identified on working sub-path
B-C-D, the sub-path is switched to protection sub-path B-G-H-D. As a B-C-D, the sub-path is switched to protection sub-path B-G-H-D. As a
result, the target node of HPSM changes from E to D due to the result, the target node of HPSM changes from E to D due to the
difference of hop counts between a route of working path(ABCDE: 4 difference of hop counts between a route of working path(ABCDE: 4
hops) and that of protection path(ABGHDE: 5 hops), because the hops) and that of protection path(ABGHDE: 5 hops), because the
forwarding and processing of HPSM OAM packets depend only on TTL forwarding and processing of HPSM OAM packets depend only on TTL
value of MPLS label header. In this case, some additional mechanisms value of MPLS label header. In this case, some additional mechanisms
to notify the fault on working path to the source of HPSM may be to notify the fault on working path to the source of HPSM may be
necessary to suspend the monitoring. 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...D-E-F
- working sub-path: B-C-D - working sub-path: B-C-D
- protection sub-path: B-G-H-D - protection sub-path: B-G-H-D
- HPSM: A-E - HPSM: A-E
--------------- ---------------
Figure 7 : Protection scenario B having an issue when a fault Figure 7: Protection scenario B having an issue when a fault happens
happens on HPSM on HPSM
6.5. Consideration of maintenance point for HPSM 6.5. Consideration of maintenance point for HPSM
An intermediate maintenance point supporting the HPSM has to be able An intermediate maintenance point supporting the HPSM 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 HPSM do not necessarily have to coincide with MIPs or MEPs in
terms of the architecture definition, the same identifier for MIPs terms of the architecture definition, the same identifier for MIPs or
or MEPs could be applied to maintenance points of the HPSM. MEPs could be applied to maintenance points of the HPSM.
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 mentioned in Section 3 of this document that are described also in
section 3.8 of [5]. section 3.8 of RFC 6371 [RFC6371].
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'-1( and P'-2), to meet those two network
objectives. 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 cover both per-node model and per-interface model which are specified
specified in [5]. In addition, the following requirements should be in RFC 6371 [RFC6371]. In addition, the following requirements
considered for an enhanced temporal and hitless path segment should be considered for an enhanced temporal and hitless path
monitoring function: segment monitoring function:
- "On-demand and in-service" single level segment should be done o "On-demand and in-service" single level segment should be done
without changing or interfering any condition of pro-active without changing or interfering any condition of pro-active
monitoring of an original ME of a transport path. monitoring of an original ME of a transport path.
- On-demand and in-service segment monitoring should be able to be o On-demand and in-service segment monitoring should be able to be
set in an arbitrary segment of a transport path. 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 is applicable
to and needs to support several on-demand OAM functions, as follows: to and needs to support several on-demand OAM functions, as follows:
Mandatory: Packet Loss Measurement and Packet Delay Measurement Mandatory: Packet Loss Measurement and Packet Delay Measurement
Optional: Connectivity Verification, Diagnostic Tests (Throughput Optional: Connectivity Verification, Diagnostic Tests (Throughput
test), and Route Tracing. test), and Route Tracing.
8. Security Considerations 8. Security Considerations
This document does not by itself raise any particular security
considerations.
9. IANA Considerations
There are no IANA actions required by this draft.
10. References
10.1. Normative References
[1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC5860, May 2010
[2] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC5921, July 2010
[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001
[4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching The security considerations defined for RFC 6378 apply to this
Transport Profile Survivability Framework", RFC6372, September document as well. As this is simply a re-use of RFC 6378, there are
2011 no new security considerations.
[5] Busi, I., Dave, A. , "Operations, Administration and 9. IANA Considerations
Maintenance Framework for MPLS-based Transport Networks ",
RFC6371, February 2011
10.2. Informative References There are no requests for IANA actions in this document.
None Note to the RFC Editor - this section can be removed before
publication.
11. Acknowledgments 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, 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.
This document was prepared using 2-Word-v2.0.template.dot. 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
TP) Survivability Framework", RFC 6372, September 2011.
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
Huawei Technologies
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 Communications NTT
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. 151 change blocks. 
416 lines changed or deleted 414 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/