draft-ietf-mpls-tp-temporal-hitless-psm-13.txt   draft-ietf-mpls-tp-temporal-hitless-psm-14.txt 
Network Working Group A. D'Alessandro Network Working Group A. D'Alessandro
Internet-Draft Telecom Italia Internet-Draft Telecom Italia
Intended status: Informational L. Andersson Intended status: Informational L. Andersson
Expires: September 9, 2017 Huawei Technologies Expires: March 5, 2018 Huawei Technologies
S. Ueno S. Ueno
NTT Communications NTT Communications
K. Arai K. Arai
Y. Koike Y. Koike
NTT NTT
March 8, 2017 September 1, 2017
Requirements for hitless MPLS path segment monitoring Requirements for hitless MPLS path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-13.txt draft-ietf-mpls-tp-temporal-hitless-psm-14.txt
Abstract Abstract
One of the most important OAM capabilities for transport network One of the most important OAM capabilities for transport network
operation is fault localisation. An in-service, on-demand segment operation is fault localisation. An in-service, on-demand segment
monitoring function of a transport path is indispensable, monitoring function of a transport path is indispensable,
particularly when the service monitoring function is activated only particularly when the service monitoring function is activated only
between end points. However, the current segment monitoring approach between end points. However, the current segment monitoring approach
defined for MPLS (including the transport profile (MPLS-TP)) in RFC defined for MPLS (including the transport profile (MPLS-TP)) in RFC
6371 "Operations, Administration, and Maintenance Framework for MPLS- 6371 "Operations, Administration, and Maintenance Framework for MPLS-
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2017. This Internet-Draft will expire on March 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements for Hitless Path Segment Monitoring . . . . . . 7 4. Requirements for Hitless Path Segment Monitoring . . . . . . 7
4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7 4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7
4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8 4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8
4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8 4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8
4.4. Single and multiple level monitoring . . . . . . . . . . 8 4.4. Single and multiple level monitoring . . . . . . . . . . 8
4.5. HPSM and end-to-end proactive monitoring independence . . 9 4.5. HPSM and end-to-end proactive monitoring independence . . 9
4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10
4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11 4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11
4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12
4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13 4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], According to the MPLS-TP OAM requirements RFC 5860 [RFC5860],
mechanisms MUST be available for alerting service providers of faults mechanisms MUST be available for alerting service providers of faults
or defects that affects their services. In addition, to ensure that or defects that affects their services. In addition, to ensure that
faults or service degradation can be localized, operators need a faults or service degradation can be localized, operators need a
function to diagnose the detected problem. Using end-to-end function to diagnose the detected problem. Using end-to-end
skipping to change at page 3, line 31 skipping to change at page 3, line 30
identify possibile solutions. identify possibile solutions.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.1. Terminology 2.1. Terminology
ATM - Asynchronous Transfer Mode
HPSM - Hitless Path Segment Monitoring HPSM - Hitless Path Segment Monitoring
LSP - Label Switched Path LSP - Label Switched Path
LSR - Label Switching Router LSR - Label Switching Router
ME - Maintenance Entity ME - Maintenance Entity
MEG - Maintenance Entity Group MEG - Maintenance Entity Group
MEP - Maintenance Entity Group End Point MEP - Maintenance Entity Group End Point
MIP - Maintenance Entity Group Intermediate Point MIP - Maintenance Entity Group Intermediate Point
OTN - Optical Transport Network OTN - Optical Transport Network
TCM - Tandem connection monitoring TCM - Tandem connection monitoring
SPME - Sub-path Maintenance Element SPME - Sub-path Maintenance Element
2.2. Definitions
None.
3. Problem Statement 3. Problem Statement
To monitor (and to protect and/or manage) MPLS-TP network segments a To monitor (and to protect and/or manage) MPLS-TP network segments a
Sub-Path Maintenance Element (SPME) function has been defined in RFC Sub-Path Maintenance Element (SPME) function has been defined in RFC
5921 [RFC5921]. The SPME is defined between the edges of the segment 5921 [RFC5921]. The SPME is defined between the edges of the segment
of a transport path that needs to be monitored, protected, or of a transport path that needs to be monitored, protected, or
managed. SPME is created by stacking the shim header (MPLS header) managed. SPME is created by stacking the shim header (MPLS header)
according to RFC 3031 [RFC3031] and it is defined as the segment according to RFC 3031 [RFC3031] and it is defined as the segment
where the header is stacked. OAM messages can be initiated at the where the header is stacked. OAM messages can be initiated at the
edge of the SPME and sent to the peer edge of the SPME or to a MIP edge of the SPME and sent to the peer edge of the SPME or to a MIP
skipping to change at page 5, line 4 skipping to change at page 4, line 49
Problem (P1) is related to the management of each additional sub- Problem (P1) is related to the management of each additional sub-
layer required for segment monitoring in a MPLS-TP network. When an layer required for segment monitoring in a MPLS-TP network. When an
SPME is applied to administer on-demand OAM functions in MPLS-TP SPME is applied to administer on-demand OAM functions in MPLS-TP
networks, a rule for operationally differentiating those SPME will be networks, a rule for operationally differentiating those SPME will be
required at least within an administrative domain. This forces required at least within an administrative domain. This forces
operators to implement at least an additional layer into the operators to implement at least an additional layer into the
management systems that will only be used for on-demand path segment management systems that will only be used for on-demand path segment
monitoring. From the perspective of operation, increasing the number monitoring. From the perspective of operation, increasing the number
of managed layers and managed addresses/identifiers is not desirable of managed layers and managed addresses/identifiers is not desirable
in view of keeping the management systems as simple as possible. in view of keeping the management systems as simple as possible.
Moreover, using the currently defined methods, on-demand setting of Moreover, using the currently defined methods, on-demand setting of
SPMEs causes problems (P2) and (P3) due to additional label stacking. SPMEs causes problems (P2) and (P3) due to additional label stacking.
Problem (P2) arises from the fact that MPLS exposed label value and Problem (P2) arises from the fact that MPLS exposed label value and
MPLS frames length changes. The monitoring function should monitor MPLS frames length changes. The monitoring function should monitor
the status without changing any conditions of the targeted, to be the status without changing any condition of the target, to be
monitored, segment or transport path. Changing the settings of the monitored, segment or transport path. Changing the settings of the
original shim header should not be allowed because this change original shim header should not be allowed because this change
corresponds to creating a new segment of the original transport path corresponds to creating a new segment of the original transport path
that differs from the original one. When the conditions of the path that differs from the original one. When the conditions of the path
change, the measured values or observed data will also change and change, the measured values or observed data will also change and
this may make the monitoring meaningless because the result of the this may make the monitoring meaningless because the result of the
measurement would no longer reflect the performance of the connection measurement would no longer reflect the performance of the connection
where the original fault or degradation occurred. As an example, where the original fault or degradation occurred. As an example,
setting up an on-demand SPME will result in the LSRs within the setting up an on-demand SPME will result in the LSRs within the
monitoring segment only looking at the added (stacked) labels and not monitoring segment only looking at the added (stacked) labels and not
skipping to change at page 9, line 34 skipping to change at page 9, line 34
There is a need for simultaneously using existing end-to-end There is a need for simultaneously using existing end-to-end
proactive monitoring and on-demand path segment monitoring. proactive monitoring and on-demand path segment monitoring.
Normally, the on-demand path segment monitoring is configured on a Normally, the on-demand path segment monitoring is configured on a
segment of a maintenance entity of a transport path. In such an segment of a maintenance entity of a transport path. In such an
environment, on-demand single-level monitoring should be performed environment, on-demand single-level monitoring should be performed
without disrupting the pro-active monitoring of the targeted end-to- without disrupting the pro-active monitoring of the targeted end-to-
end transport path to avoid affecting user traffic performance end transport path to avoid affecting user traffic performance
monitoring. monitoring.
(M7) HPSM MUST support the capability of being operated (M7) HPSM MUST support the capability of being operated
concurrently to, and independently of operated of the OAM function concurrently to, and independently of OAM function operated on the
operated on the end-to-end path end-to-end 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
+-----------------------------+ <= Pro-active end-to-end mon. +-----------------------------+ <= Pro-active end-to-end mon.
*------------------* <= On-demand HPSM *------------------* <= On-demand HPSM
Figure 4: Independence between proactive end-to-end monitoring and Figure 4: Independence between proactive end-to-end monitoring and
skipping to change at page 11, line 22 skipping to change at page 11, line 22
*-----------------------* <= On-demand HPSM 2 *-----------------------* <= On-demand HPSM 2
*---------* <= On-demand HPSM 3 *---------* <= On-demand HPSM 3
Figure 6: HPSM configuration at arbitrary segments Figure 6: HPSM configuration at arbitrary segments
4.7. Fault while HPSM is operational 4.7. Fault while HPSM is operational
Node or link failures may occur while HPSM is active. In this case, Node or link failures may occur while HPSM is active. In this case,
if no resiliency mechanism is set-up on the subtended transport path, if no resiliency mechanism is set-up on the subtended transport path,
there is no particular requirement for HPSM. If the transport path there is no particular requirement for HPSM. If the transport path
is protected, the HPSM function should be terminated to avoid is protected, the HPSM function may bring to monitoring unintended
monitoring a new segment when a protection or restoration path is segments. The following examples are provided for clarification.
active.
(M9) The HPSM SHOULD avoid monitoring an unintended segment when
one or more failures occur
The following examples are provided for clarification only and they
are not intended to restrict any solution for meeting the
requirements of HPSM.
Protection scenario A is shown in figure 7. In this scenario a Protection scenario A is shown in figure 7. In this scenario a
working LSP and a protection LSP are set-up. HPSM is activated working LSP and a protection LSP are set-up. HPSM is activated
between nodes A and E. When a fault occurs between nodes B and C, between nodes A and E. When a fault occurs between nodes B and C,
the operation of HPSM is not affected by the protection switch and the operation of HPSM is not affected by the protection switch and
continues on the active LSP path. As a result requirement (M9) is continues on the active LSP path.
satisfied.
A - B - C - D - E - F A - B - C - D - E - F
\ / \ /
G - H - I - L G - H - I - L
Where: Where:
- end-to-end LSP: A-B-C-D-E-F - end-to-end LSP: A-B-C-D-E-F
- working LSP: A-B-C-D-E-F - working LSP: A-B-C-D-E-F
- protection LSP: A-G-H-I-L-F - protection LSP: A-G-H-I-L-F
- HPSM: A-E - HPSM: A-E
skipping to change at page 12, line 25 skipping to change at page 12, line 5
Figure 7: Protection scenario A Figure 7: Protection scenario A
Protection scenario B is shown in figure 8. The difference with Protection scenario B is shown in figure 8. The difference with
scenario A is that only a portion of the transport path is protected. scenario A is that only a portion of the transport path is protected.
In this case, when a fault occurs between nodes B and C on the In this case, when a fault occurs between nodes B and C on the
working sub-path B-C-D, traffic will be switched to protection sub- working sub-path B-C-D, traffic will be switched to protection sub-
path B-G-H-D. Assuming that OAM packet termination depends only on path B-G-H-D. Assuming that OAM packet termination depends only on
the TTL value of the MPLS label header, the target node of the HPSM the TTL value of the MPLS label header, the target node of the HPSM
changes from E to D due to the difference of hop counts between the changes from E to D due to the difference of hop counts between the
working path route (A-B-C-D-E: 4 hops) and protection path route working path route (A-B-C-D-E: 4 hops) and protection path route
(A-B-G-H-D-E: 5 hops). As a result requirement (M9) is not (A-B-G-H-D-E: 5 hops). In this case the operation of HPSM is
satisfied. affected.
A - B - C - D - E - F A - B - C - D - E - F
\ / \ /
G - H G - H
- end-to-end LSP: A-B-C-D-E-F - end-to-end LSP: A-B-C-D-E-F
- working sub-path: B-C-D - working sub-path: B-C-D
- protection sub-path: B-G-H-D - protection sub-path: B-G-H-D
- HPSM: A-E - HPSM: A-E
Figure 8: Protection scenario B Figure 8: Protection scenario B
(M9) The HPSM SHOULD avoid monitoring an unintended segment when
one or more failures occur
There are potentially different solutions to satisfy such a
requirement. A possible solution may be to suspend HPSM monitoring
until network restoration takes place. Another possible approach may
be to compare the node/interface ID in the OAM packet with that at
the node reached at TTL termination and if this does not match
through some means trigger a suspension of HPSM monitoring. The
above approaches are valid in any circumstance, both for protected
and unprotected networks LSPs. These examples should not be taken to
limit the design of a solution.
4.8. HPSM Manageability 4.8. HPSM Manageability
From managing perspective, increasing the number of managed layers From managing perspective, increasing the number of managed layers
and managed addresses/identifiers is not desirable in view of keeping and managed addresses/identifiers is not desirable in view of keeping
the management systems as simple as possible. the management systems as simple as possible.
(M10)HPSM SHOULD NOT be based on additional transport layers (e.g. (M10)HPSM SHOULD NOT be based on additional transport layers (e.g.
hierarchical LSPs) hierarchical LSPs)
(M11) The same identifiers used for MIPs and/or MEPs SHOULD be (M11) The same identifiers used for MIPs and/or MEPs SHOULD be
applied to maintenance points for the HPSM when they are applied to maintenance points for the HPSM when they are
instantiated in the same place along a transport path. instantiated in the same place along a transport path.
Anyway maintenance points for the HPSM may be different from MIPs Anyway maintenance points for the HPSM may be different from MIPs
and MEPs functional components as defined in the OAM framework and MEPs functional components as defined in the OAM framework
document RFC 6371 [RFC6371]. Investigating potential solutions document RFC 6371 [RFC6371]. Investigating potential solutions
for satisfying proposed HPSM requirements might lead to propose for satisfying proposed HPSM requirements might lead to propose
new functional components that have to be backward compatible with new functional components that have to be backward compatible with
MPLS architecture. Solutions are outside the scope of this MPLS architecture. Solutions are outside the scope of this
skipping to change at page 15, line 4 skipping to change at page 14, line 39
Email: manuel.paul@telekom.de Email: manuel.paul@telekom.de
9. Acknowledgements 9. Acknowledgements
The authors would also like to thank Alexander Vainshtein, Dave The authors would also like to thank Alexander Vainshtein, Dave
Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi,
Maarten Vissers, Jia He and Nurit Sprecher for their comments and Maarten Vissers, Jia He and Nurit Sprecher for their comments and
enhancements to the text. enhancements to the text.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3031>. editor.org/info/rfc3031>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and "Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860, Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010, DOI 10.17487/RFC5860, May 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5860>. editor.org/info/rfc5860>.
10.2. Informative References 10.2. Informative References
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>. <https://www.rfc-editor.org/info/rfc5921>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371, Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>. September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372, Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011, DOI 10.17487/RFC6372, September 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6372>. editor.org/info/rfc6372>.
Authors' Addresses Authors' Addresses
Alessandro D'Alessandro Alessandro D'Alessandro
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: alessandro.dalessandro@telecomitalia.it Email: alessandro.dalessandro@telecomitalia.it
 End of changes. 23 change blocks. 
40 lines changed or deleted 38 lines changed or added

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