draft-ietf-mpls-tp-temporal-hitless-psm-00.txt   draft-ietf-mpls-tp-temporal-hitless-psm-01.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: September 25, 2012 March 26, 2012 Expires: January 15, 2013 July 16, 2012
Temporal and hitless path segment monitoring Temporal and hitless path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-00.txt draft-ietf-mpls-tp-temporal-hitless-psm-01.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 September 25, 2012. This Internet-Draft will expire on January 15, 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 27 skipping to change at page 2, line 27
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 of
a transport path is effective in terms of extension of the a transport path is effective in terms of extension of the
maintenance work and indispensable particularly when the OAM function maintenance work and indispensable particularly when the OAM function
is effective only between end points. However, the current approach is effective only between end points. However, the current approach
defined for MPLS-TP for the segment monitoring (SPME) has some fatal defined for MPLS-TP for the segment monitoring (SPME) has some fatal
drawbacks. drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provides monitoring of a
This document elaborates on the problem statement for the Sub-path portion of a set of transport paths (LSPs or MS-PWs). Based on the
Maintenance Elements (SPMEs) which provides monitoring of a portion problems, this document specifies new requirements to consider a new
of a set of transport paths (LSPs or MS-PWs). Based on the problems, improved mechanism of hitless transport path segment monitoring.
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 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 ........................................... 5 4. Problem statement ........................................... 6
5. OAM functions using segment monitoring ....................... 9 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.......... 10 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
7. Conclusion ................................................. 13 6.4. Fault during HPSM in case of protection ................ 13
8. Security Considerations..................................... 14 7. Summary .................................................... 15
9. IANA Considerations ........................................ 14 8. Security Considerations ..................................... 15
10. References ................................................ 14 9. IANA Considerations ........................................ 15
10.1. Normative References.................................. 14 10. References ................................................ 15
10.2. Informative References................................ 15 10.1. Normative References .................................. 15
11. Acknowledgments ........................................... 15 10.2. Informative References ................................ 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
transport networks and have evolved along with TDM, ATM, SDH and OTN. transport networks and have evolved along with TDM, ATM, SDH and OTN.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
covered in [5]. covered in [5].
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 [1].
2.1. Terminology 2.1. Terminology
HSPM Hitless Path Segment Monitoring HPSM Hitless Path Segment Monitoring
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance Entity Group End 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
skipping to change at page 8, line 41 skipping to change at page 8, line 51
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 C-plane environment) is specified in other (in both with and without Control Plane environment) is specified in
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 MBB, in other words, taking an following issue. Non-disruptive make-before-break, in other words,
action similar to switching just for monitoring is not an ideal taking an action similar to switching just for monitoring is not an
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 to
correctly setting and checking the label values of the original LSP correctly setting and checking the label values of the original LSP
in the configuration. Of course, the inversion of this situation is in the configuration. Of course, the inversion of this situation is
also possible, .e.g., incorrect or unexpected treatment of SPME 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 The utility of SPMEs is basically limited to inter-carrier or inter-
or inter-domain segment monitoring where they are typically pre- domain segment monitoring where they are typically pre-configured or
configured or pre-instantiated. SPME instantiates a hierarchical pre-instantiated. SPME instantiates a hierarchical transport path
transport path (introducing MPLS label stacking) through which OAM (introducing MPLS label stacking) through which OAM packets can be
packets can be sent. SPME construct monitoring function is sent. SPME construct monitoring function is particularly important
particularly important mainly for protecting bundles of transport mainly for protecting bundles of transport paths and carriers'
paths and carriers' carrier solutions. SPME is expected to be mainly carrier solutions. SPME is expected to be mainly used for protection
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
skipping to change at page 11, line 12 skipping to change at page 11, line 23
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 multi-
level segment monitoring isdesirable. Figure 2 shows an example of a level segment monitoring is desirable. Figure 2 shows an example of a
multi-level on-demand segment monitoring. 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
skipping to change at page 13, line 41 skipping to change at page 13, line 41
--- --- --- --- --- --- --- --- --- ---
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 in
arbitrary segments arbitrary segments
7. Conclusion 6.4. Fault during HPSM in case of protection
It is requested that another monitoring mechanism is required to Node or link failures may occur during the HPSM is activated. In that
support temporal and hitless segment monitoring which meets the two case, the hitless path segment monitoring function should be
network objectives mentioned in Section 3 of this draftthat are suspended immediately and must not continue the monitoring on a new
described also in section 3.8 of [5]. protected or restored path when a protection or restoration for the
fault path is available. The reason is that target node of the
hitless segment monitoring can be changed to unintended node due to
the different hop counts from source node of segment monitoring to
target node between working path and protection path.
The enhancements should minimize the issues described in Section 4,, Protection scenario A is shown in figure 6. In this scenario, a
i.e., P-1, P-2, P'-1( and P'-2,) to meet those two network objectives. 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
\ /
G - H
Where:
- working LSP: A-B-C-D-E-F
- protection LSP: A-B-G-H-D-E-F
- HPSM: A-E
---------------
Figure 6 : Protection scenario A having no issue when a fault
happens on HPSM
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
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 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 hops) and that of
protection path(ABGHDE: 5 hops), because the forwarding and
processing of HPSM OAM packets depend only on TTL 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 necessary to suspend the
monitoring.
A - B -- C -- D - E - F
\ /
G - H
- e2e LSP: A-B...D-E-F
- working sub-path: B-C-D
- protection sub-path: B-G-H-D
- HPSM: A-E
---------------
Figure 7 : Protection scenario B having an issue when a fault happens
on HPSM
7. Summary
An enhanced monitoring mechanism is required to support temporal and
hitless segment monitoring which meets the two network objectives
mentioned in Section 3 of this document that are described also in
section 3.8 of [5].
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.
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 function. for an enhanced temporal and hitless path segment monitoring
function:
Note: (P'-2) needs to be reconsidered.- An on-demand and in-service
"single-level" segment monitoring ismandatory. Multi-level segment
monitoring is optional.
- "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 followings are specific requirements on each on-demand OAM The temporal and hitless segment monitoring solutions is applicable
function.Mandatory: Packet Loss Measurement and Packet Delay to and needs to support several on-demand OAM functions, as follows:
Measurement Mandatory: Packet Loss Measurement and Packet Delay Measurement
Optional: Connectivity Verification, Diagnostic Tests (Throughput
Option: Connectivity verification, Diagnostic Tests (Throughput test), test), and Route Tracing.
Route tracing
8. Security Considerations 8. Security Considerations
This document does not by itself raise any particular security This document does not by itself raise any particular security
considerations. considerations.
9. IANA Considerations 9. IANA Considerations
There are no IANA actions required by this draft. There are no IANA actions required by this draft.
skipping to change at page 15, line 6 skipping to change at page 16, line 9
[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 Networks",
RFC5921, July 2010 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", draft-ietf-mpls-tp- Transport Profile Survivability Framework", RFC6372, September
survive-fwk-06.txt(work in progress), June 2010 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 ",
draft-ietf-mpls-tp-oam-framework-11.txt(work in progress), RFC6371, February 2011
February 2011
10.2. Informative References 10.2. Informative References
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
 End of changes. 20 change blocks. 
59 lines changed or deleted 118 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/