draft-ietf-mpls-tp-temporal-hitless-psm-02.txt   draft-ietf-mpls-tp-temporal-hitless-psm-03.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
Y.Koike Y.Koike
NTT NTT
Expires: May8, 2013 November 9, 2012 Expires: Nov7, 2013 May 8, 2013
Temporal and hitless path segment monitoring Temporal and hitless path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-02.txt draft-ietf-mpls-tp-temporal-hitless-psm-03.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 the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), 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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 May 8, 2013. This Internet-Draft will expire on November 7, 2013.
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 carefully,
skipping to change at page 2, line 42 skipping to change at page 2, line 42
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network. 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 .................................................... 10
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-end
proactive monitoring........................................ 11 proactive monitoring........................................ 11
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 ................ 13
7. Summary .................................................... 15 7. Summary .................................................... 15
8. Security Considerations..................................... 15 8. Security Considerations ..................................... 16
9. IANA Considerations ........................................ 15 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 ................................ 16
11. Acknowledgments ........................................... 16 11. Acknowledgments ........................................... 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 in to ensure quality and reliability of a network. They are essential in
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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 until
the end of life of a transport path, which is not temporal or on- the end of life of a transport path, which is not temporal or 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. There is no standardized way to monitoring in a MPLS-TP network. When SPME/TCM is applied for on-
identify a layer, however a possible rule of differentiating layers demand OAM functions in MPLS-TP networks in a similar manner to OTN
will be necessary at least within an administrative domain, if SPME or Ethernet transport networks, a possible rule of differentiating
is applied for on-demand OAM functions. This enforces operators to those SPME/TCMs operationally will be necessary at least within an
create an additional permanent layer identification policy only for administrative domain. This enforces operators to create an
temporal path segment monitoring. Moreover, from the perspective of additional permanent layer identification policy only for temporal
operation, increasing the managed addresses and the managed layer is path segment monitoring. Moreover, from the perspective of operation,
not desirable in terms of simplified operation featured by current increasing the managed addresses and the managed layer is not
desirable in terms of simplified operation featured by current
transport networks. Reducing the managed identifiers and managed 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[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 temporal fix issues in an on-demand manner. To avoid these issues, the
and on-demand setting of the SPME(s) is needed and more efficient for temporal and on-demand setting of the SPME(s) is needed and more
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, which
are fatal in terms of intrinsic monitoring and service disruption. are fatal in terms of intrinsic monitoring and service disruption.
(P-1) C-hanging 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
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
skipping to change at page 8, line 35 skipping to change at page 8, line 35
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
--- --- --- --- --- --- --- --- --- ---
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 [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 transport
path, because the make-before-break procedure is premised on the path, because the make-before-break procedure is premised on the
change of the inner label value. This means changing one of the change of the inner label value. This means changing one of the
settings in MPLS shim header. 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 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.
skipping to change at page 9, line 49 skipping to change at page 9, line 49
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 required.
Another monitoring mechanism is therefore required that supports Another monitoring mechanism is therefore required that supports
temporal and hitless path segment monitoring. Hereafter it is called temporal and hitless path segment monitoring. Hereafter it is called
on-demand hitless path segment monitoring (HPSM). 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 words,
the characteristic of "on-demand" is generally temporal for 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
skipping to change at page 13, line 47 skipping to change at page 13, line 47
Figure 5 : Example where on-demand monitoring has to be configured in Figure 5 : Example where on-demand monitoring has to be configured 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 that Node or link failures may occur during the HPSM is activated. In that
case, the hitless path segment monitoring function should be 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. The reason is that target node of the fault path is available. Therefore a solution of HPSM should avoid
hitless segment monitoring can be changed to unintended node due to such a situation that a target node of the hitless segment monitoring
the different hop counts from source node of segment monitoring to is changed to unintended node when failures occur on the segment.
target node between working path and protection path.
Protection scenario A is shown in figure 6. In this scenario, a Fig.6 and Fig.7 exemplify one of the examples that should be avoided.
working LSP and a protection LSP are separately set, in other words However, this example is just for clarification of the problem that
as independent LSPs. HPSM is set between A and E. Therefore, should be avoided. It does not intend to restrict any solution for
considering the case that a fault happens between B and C, the HPSM meeting the requirements of HPSM. Protection scenario A is shown in
doesn't continue in a protected path. As a result, there is no issue. figure 6. In this scenario, a working LSP and a protection LSP are
separately set, in other words as independent LSPs. HPSM is set
between A and E. Therefore, considering the case that a fault happens
between B and C, the HPSM doesn't continue in a protected path. As a
result, there is no issue.
A - B -- C -- D - E - F 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
skipping to change at page 15, line 20 skipping to change at page 15, line 33
terms of the architecture definition, the same identifier for MIPs or terms of the architecture definition, the same identifier for MIPs 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 [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 specified
in [5]. In addition, the following requirements should be considered in [5]. In addition, the following requirements should be considered
for an enhanced temporal and hitless path segment monitoring for an enhanced temporal and hitless path segment monitoring
function: 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:
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
skipping to change at page 16, line 39 skipping to change at page 17, line 4
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 Allan,
Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm
Betts and Nurit Sprecher for their comments and enhancements to the Betts, Nurit Sprecher and Jia He for their comments and enhancements
text. 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
 End of changes. 23 change blocks. 
42 lines changed or deleted 46 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/