draft-ietf-mpls-tp-temporal-hitless-psm-04.txt   draft-ietf-mpls-tp-temporal-hitless-psm-05.txt 
MPLS Working Group A. D'Alessandro MPLS Working Group A. D'Alessandro
Internet Draft Telecom Italia Internet Draft Telecom Italia
M.Paul M.Paul
Deutsche Telekom Deutsche Telekom
Intended status: Informational S. Ueno Intended status: Informational S. Ueno
NTT Communications NTT Communications
K.Arai
Y.Koike Y.Koike
NTT NTT
Expires: Mar. 20, 2014 Oct 21, 2013 Expires: July 30, 2014 January 31, 2014
Temporal and hitless path segment monitoring Temporal and hitless path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-04.txt draft-ietf-mpls-tp-temporal-hitless-psm-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 20, 2014. This Internet-Draft will expire on July 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 carefully, publication of this document. Please review these documents
as they describe your rights and restrictions with respect to this carefully, as they describe your rights and restrictions with respect
document. Code Components extracted from this document must include to this document. Code Components extracted from this document must
Simplified BSD License text as described in Section 4.e of the Trust include Simplified BSD License text as described in Section 4.e of
Legal Provisions and are provided without warranty as described in the Trust Legal Provisions and are provided without warranty as
the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
The MPLS transport profile (MPLS-TP) is being standardized to enable The MPLS transport profile (MPLS-TP) is being 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 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
preliminary or in-service measurements. preliminary or in-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 of network operation is fault location. A segment monitoring function
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
is effective only between end points. However, the current approach function is effective only between end points. However, the current
defined for MPLS-TP for the segment monitoring (SPME) has some fatal approach defined for MPLS-TP for the segment monitoring (SPME) has
drawbacks. This document elaborates on the problem statement for the some fatal drawbacks. This document elaborates on the problem
Sub-path Maintenance Elements (SPMEs) which provides monitoring of a statement for the Sub-path Maintenance Elements (SPMEs) which
portion of a set of transport paths (LSPs or MS-PWs). Based on the provides monitoring of a portion of a set of transport paths (LSPs
problems, this document specifies new requirements to consider a new or MS-PWs). Based on the problems, this document specifies new
improved mechanism of hitless transport path segment monitoring. 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 This document is a product of a joint Internet Engineering Task
(IETF) / International Telecommunications Union Telecommunications Force (IETF) / International Telecommunications Union
Standardization Sector (ITU-T) effort to include an MPLS Transport Telecommunications Standardization Sector (ITU-T) effort to include
Profile within the IETF MPLS and PWE3 architectures to support the an MPLS Transport Profile within the IETF MPLS and PWE3
capabilities and functionalities of a packet transport network. architectures to support the capabilities and functionalities of a
packet transport network.
Table of Contents Table of Contents
1. Introduction ................................................ 4 1. Introduction ................................................ 4
2. Conventions used in this document............................ 4 2. Conventions used in this document ............................ 4
2.1. Terminology ............................................ 5 2.1. Terminology ............................................ 5
2.2. Definitions ............................................ 5 2.2. Definitions ............................................ 5
3. Network objectives for monitoring............................ 5 3. Network objectives for monitoring ............................ 5
4. Problem statement ........................................... 6 4. Problem statement ........................................... 6
5. OAM functions using segment monitoring ...................... 10 5. OAM functions using segment monitoring ...................... 10
6. Further consideration of requirements for enhanced segment 6. Further consideration of requirements for enhanced segment
monitoring .................................................... 10 monitoring .................................................. 1110
6.1. Necessity of on-demand single-level monitoring.......... 11 6.1. Necessity of on-demand single-level monitoring.......... 11
6.2. Necessity of on-demand monitoring independent from end-to-end 6.2. Necessity of on-demand monitoring independent from end-to-
proactive monitoring........................................ 11 end proactive monitoring .................................. 1211
6.3. Necessity of arbitrary segment monitoring .............. 12 6.3. Necessity of arbitrary segment monitoring .............. 12
6.4. Fault during HPSM in case of protection ................ 13 6.4. Fault during HPSM in case of protection .............. 1413
7. Summary .................................................... 15 7. Summary .................................................. 1615
8. Security Considerations..................................... 16 8. Security Considerations ..................................... 16
9. IANA Considerations ........................................ 16 9. IANA Considerations ........................................ 16
10. References ................................................ 16 10. References ................................................ 16
10.1. Normative References.................................. 16 10.1. Normative References .................................. 16
10.2. Informative References................................ 16 10.2. Informative References .............................. 1716
11. Acknowledgments ........................................... 16 11. Acknowledgments ......................................... 1716
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 in to ensure quality and reliability of a network. They are essential
transport networks and have evolved along with TDM, ATM, SDH and OTN. in transport networks and have evolved along with TDM, ATM, SDH and
OTN.
Unlike in SDH or OTN networks, where OAM is an inherent part of every Unlike in SDH or OTN networks, where OAM is an inherent part of
frame and frames are also transmitted in idle mode, it is not per se every frame and frames are also transmitted in idle mode, it is not
possible to constantly monitor the status of individual connections per se possible to constantly monitor the status of individual
in packet networks. Packet-based OAM functions are flexible and connections in packet networks. Packet-based OAM functions are
selectively configurable according to operators' needs. flexible and selectively configurable according to operators' needs.
According to the MPLS-TP OAM requirements [1], mechanisms MUST be According to the MPLS-TP OAM requirements [1], mechanisms MUST be
available for alerting a service provider of a fault or defect available for alerting a service provider of a fault or defect
affecting the service(s) provided. In addition, to ensure that faults affecting the service(s) provided. In addition, to ensure that
or degradations can be localized, operators need a method to analyze faults or degradations can be localized, operators need a method to
or investigate the problem. From the fault localization perspective, analyze or investigate the problem. From the fault localization
end-to-end monitoring is insufficient. Using end-to-end OAM perspective, end-to-end monitoring is insufficient. Using end-to-end
monitoring, when one problem occurs in an MPLS-TP network, the OAM monitoring, when one problem occurs in an MPLS-TP network, the
operator can detect the fault, but is not able to localize it. 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[5],
the current method for segment monitoring function of a transport the current method for segment monitoring function of a transport
path has implications that hinder the usage in an operator network. path has implications that hinder the usage in an operator network.
skipping to change at page 6, line 13 skipping to change at page 6, line 17
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 [2]. The SPME is defined between the edges of the portion
of the transport path that needs to be monitored, protected, or of the transport path that needs to be monitored, protected, or
managed. This SPME is created by stacking the shim header (MPLS managed. This SPME is created by stacking the shim header (MPLS
header)[3] and is defined as the segment where the header is stacked. header)[3] and is defined as the segment where the header is stacked.
OAM messages can be initiated at the edge of the SPME and sent to the OAM messages can be initiated at the edge of the SPME and sent to
peer edge of the SPME or to a MIP along the SPME by setting the TTL the peer edge of the SPME or to a MIP along the SPME by setting the
value of the label stack entry (LSE) and interface identifier value TTL value of the label stack entry (LSE) and interface identifier
at the corresponding hierarchical LSP level in case of per-node model. value at the corresponding 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 and
MIPs need to be configured for the SPME in the old MEG 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 until service disruption, one or more SPMEs have to be set in advance
the end of life of a transport path, which is not temporal or on- until the end of life of a transport path, which is not temporal or
demand. Consuming additional bandwidth permanently for only the on-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
skipping to change at page 7, line 16 skipping to change at page 7, line 20
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[2]. However, in this case, the SPMEs have to be pre-
configured. If this solution is applied to specific segment configured. If this solution is applied to specific segment
monitoring within one operator domain, all the necessary specific monitoring within one operator domain, all the necessary specific
segments have to be pre-configured. This setting increases the segments have to be pre-configured. This setting increases the
managed objects as well as the necessary bandwidth, shown as Problem managed objects as well as the necessary bandwidth, shown as Problem
(P-1) and (P-2). Moreover, as a result of these pre-configurations, (P-1) and (P-2). Moreover, as a result of these pre-configurations,
they impose operators to pre-design the structure of sub-path they impose operators to pre-design the structure of sub-path
maintenance elements, which is not preferable in terms of operators' maintenance elements, which is not preferable in terms of operators'
increased burden. These concerns are summarized in section 3.8 of [5]. increased burden. These concerns are summarized in section 3.8 of
[5].
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, which SPMEs also causes the following problems due to label stacking,
are fatal in terms of intrinsic monitoring and service disruption. which are fatal in terms of intrinsic monitoring and service
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 SPME
is temporally configured. 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
skipping to change at page 8, line 5 skipping to change at page 8, line 12
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 the Figure 1 shows an example of SPME setting. In the figure, X means
one label expected on the tail-end node D of the original transport the one label expected on the tail-end node D of the original
path. "210" and "220" are label allocated for SPME. The label values transport path. "210" and "220" are label allocated for SPME. The
of the original path are modified as well as the values of stacked label values of the original path are modified as well as the values
label. As shown in Fig.1, SPME changes the length of all the MPLS of stacked label. As shown in Fig.1, SPME changes the length of all
frames and changes label value(s). This is no longer the monitoring the MPLS frames and changes label value(s). This is no longer the
of the original transport path but the monitoring of a different path. monitoring of the original transport path but the monitoring of a
Particularly, performance monitoring measurement (Delay measurement different path. Particularly, performance monitoring measurement
and loss measurement) are sensitive to those changes. (Delay measurement and loss measurement) are sensitive to those
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)
skipping to change at page 8, line 39 skipping to change at page 8, line 47
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 [4] seemingly supports
the hitless configuration for monitoring according to the framework the hitless configuration for monitoring according to the framework
document [2]. The reality is the hitless configuration of SPME is document [2]. The reality is the hitless configuration of SPME is
impossible without affecting the conditions of the targeted transport impossible without affecting the conditions of the targeted
path, because the make-before-break procedure is premised on the transport path, because the make-before-break procedure is premised
change of the inner label value. This means changing one of the on the change of the inner label value. This means changing one of
settings in MPLS shim header. 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 client segment is monitored could have the same impact (disruption of
traffic) as the creation of an SPME on the same LSP. client 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 to configuration etc. Therefore operators have to pay extra attention
correctly setting and checking the label values of the original LSP to correctly setting and checking the label values of the original
in the configuration. Of course, the inversion of this situation is LSP in the configuration. Of course, the inversion of this situation
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
skipping to change at page 9, line 42 skipping to change at page 9, line 51
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 required. solution avoiding those issues or minimizing their impact is
Another monitoring mechanism is therefore required that supports required. Another monitoring mechanism is therefore required that
temporal and hitless path segment monitoring. Hereafter it is called supports temporal and hitless path segment monitoring. Hereafter it
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 [5], because those segment monitoring functions are used to
locate the fault/degraded point or to diagnose the status for locate the fault/degraded point or to diagnose the status for
detailed analyses, especially when a problem occurred. In other words, detailed analyses, especially when a problem occurred. In other
the characteristic of "on-demand" is generally temporal for words, the characteristic of "on-demand" is generally temporal for
maintenance operation. Conversely, this could be a good reason that maintenance operation. Conversely, this could be a good reason that
operations should not be based on pre-configuration and pre-design. 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 because hitless and temporal segment monitoring are strongly required
these functions are supported only between end points of a transport because these functions are supported only between end points of a
path. If a fault or defect occurs, there is no way to locate the transport path. If a fault or defect occurs, there is no way to
defect or degradation point without using the segment monitoring locate the defect or degradation point without using the segment
function. If an operator cannot locate or narrow the cause of the monitoring function. If an operator cannot locate or narrow the
fault, it is quite difficult to take prompt action to solve the cause of the fault, it is quite difficult to take prompt action to
problem. Therefore, on-demand HPSM for packet loss and packet delay solve the problem. Therefore, on-demand HPSM for packet loss and
measurements are indispensable for transport network operation. packet delay measurements are indispensable for transport network
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.
skipping to change at page 10, line 46 skipping to change at page 11, line 8
Note: Note:
The solution for temporal and hitless segment monitoring should not The solution for temporal and hitless segment monitoring should not
be limited to label stacking mechanisms based on pre-configuration, be limited to label stacking mechanisms based on pre-configuration,
such as PST/TCM(label stacking), which can cause the issues (P-1) such as PST/TCM(label stacking), which can cause the issues (P-1)
and (P-2) described in Section 4. 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 [5].
6. Further consideration of requirements for enhanced segment monitoring 6. Further consideration of requirements for enhanced segment
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 multi- level segment monitoring is required, on-demand and in-service
level segment monitoring is desirable. Figure 2 shows an example of a multi-level segment monitoring is desirable. Figure 2 shows an
multi-level on-demand segment monitoring. example of 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
skipping to change at page 11, line 47 skipping to change at page 12, line 14
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 done In this environment, on-demand single-level monitoring should be
without disrupting pro-active monitoring of the targeted end-to-end done without disrupting pro-active monitoring of the targeted end-
transport path. to-end transport path.
If operators have to disable the pro-active monitoring during the on- If operators have to disable the pro-active monitoring during the
demand hitless path segment monitoring, the network operation system on-demand hitless path segment monitoring, the network operation
might miss any performance degradation of user traffic. This kind of system might miss any performance degradation of user traffic. This
inconvenience should be avoided in the network operations. kind of 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 The main objective of on-demand segment monitoring is to diagnose
fault points. One possible diagnostic procedure is to fix one end the fault points. One possible diagnostic procedure is to fix one
point of a segment at the MEP of a transport path and change end 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 box are located at customer sites and consist of cost effective small
in which a subset of OAM functions are supported. In this case, if box in which a subset of OAM functions are supported. In this case,
one end point and an originator of the diagnostic packet are limited if one end point and an originator of the diagnostic packet are
to the position of MEP, on-demand segment monitoring will be limited to the position of MEP, on-demand segment monitoring will be
ineffective because all the segments cannot be diagnosed (For example, ineffective because all the segments cannot be diagnosed (For
segment monitoring 3 in Fig.5 is not available and it is not possible example, segment monitoring 3 in Fig.5 is not available and it is
to localize the fault point). not 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 monitoring *-----* <= 1st On-demand segment
*-------* <= 2nd On-demand segment monitoring monitoring
*------------* <= 3rd On-demand segment monitoring *-------* <= 2nd On-demand segment
monitoring
*------------* <= 3rd On-demand segment
monitoring
| |
| |
*-----------------------* <= 6th On-demand segment monitoring *-----------------------* <= 6th On-demand segment
*-----------------------------*<= 7th On-demand segment monitoring monitoring
*-----------------------------*<= 7th On-demand segment
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 in Figure 5 : Example where on-demand monitoring has to be configured
arbitrary segments in 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 that Node or link failures may occur during the HPSM is activated. In
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 monitoring such a situation that a target node of the hitless segment
is changed to unintended node when failures occur on the segment. monitoring 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. 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 happens between A and E. Therefore, considering the case that a fault
between B and C, the HPSM doesn't continue in a protected path. As a happens between B and C, the HPSM doesn't continue in a protected
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 on HPSM happens on HPSM
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 this a transport path has different label assignments (sub-paths). In
case, when a fault condition is identified on working sub-path B-C-D, this case, when a fault condition is identified on working sub-path
the sub-path is switched to protection sub-path B-G-H-D. As a result, B-C-D, the sub-path is switched to protection sub-path B-G-H-D. As a
the target node of HPSM changes from E to D due to the difference of result, the target node of HPSM changes from E to D due to the
hop counts between a route of working path(ABCDE: 4 hops) and that of difference of hop counts between a route of working path(ABCDE: 4
protection path(ABGHDE: 5 hops), because the forwarding and hops) and that of protection path(ABGHDE: 5 hops), because the
processing of HPSM OAM packets depend only on TTL value of MPLS label forwarding and processing of HPSM OAM packets depend only on TTL
header. In this case, some additional mechanisms to notify the fault value of MPLS label header. In this case, some additional mechanisms
on working path to the source of HPSM may be necessary to suspend the to notify the fault on working path to the source of HPSM may be
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 happens Figure 7 : Protection scenario B having an issue when a fault
on HPSM happens 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 or terms of the architecture definition, the same identifier for MIPs
MEPs could be applied to maintenance points of the HPSM. or 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 [5].
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 objectives. i.e., P-1, P-2, P'-1( and P'-2), to meet those two network
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
in [5]. In addition, the following requirements should be considered specified in [5]. In addition, the following requirements should be
for an enhanced temporal and hitless path segment monitoring considered for an enhanced temporal and hitless path segment
function: monitoring function:
- "On-demand and in-service" single level segment should be done - "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 - 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:
skipping to change at page 16, line 23 skipping to change at page 17, line 5
There are no IANA actions required by this draft. There are no IANA actions required by this draft.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in [1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC5860, May 2010 MPLS Transport Networks", RFC5860, May 2010
[2] Bocci, M., et al., "A Framework for MPLS in Transport Networks", [2] Bocci, M., et al., "A Framework for MPLS in Transport
RFC5921, July 2010 Networks", RFC5921, July 2010
[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001 January 2001
[4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching [4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching
Transport Profile Survivability Framework", RFC6372, September Transport Profile Survivability Framework", RFC6372, September
2011 2011
[5] Busi, I., Dave, A. , "Operations, Administration and [5] Busi, I., Dave, A. , "Operations, Administration and
Maintenance Framework for MPLS-based Transport Networks ", Maintenance Framework for MPLS-based Transport Networks ",
skipping to change at page 16, line 48 skipping to change at page 17, line 30
None None
11. Acknowledgments 11. Acknowledgments
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 Allan, The authors would also like to thank Alexander Vainshtein, Dave
Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm Allan, Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers,
Betts, Nurit Sprecher and Jia He for their comments and enhancements Malcolm Betts, Nurit Sprecher and Jia He for their comments and
to the text. enhancements to the text.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Alessandro D'Alessandro Alessandro D'Alessandro
Telecom Italia Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it Email: alessandro.dalessandro@telecomitalia.it
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 Communications
Email: satoshi.ueno@ntt.com Email: satoshi.ueno@ntt.com
Kaoru Arai
NTT
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. 50 change blocks. 
157 lines changed or deleted 180 lines changed or added

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