draft-ietf-mpls-tp-temporal-hitless-psm-12.txt   draft-ietf-mpls-tp-temporal-hitless-psm-13.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: August 5, 2017 Huawei Technologies Expires: September 9, 2017 Huawei Technologies
S. Ueno S. Ueno
NTT Communications NTT Communications
K. Arai K. Arai
Y. Koike Y. Koike
NTT NTT
February 1, 2017 March 8, 2017
Hitless path segment monitoring Requirements for hitless MPLS path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-12.txt draft-ietf-mpls-tp-temporal-hitless-psm-13.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 [RFC6371] has drawbacks. This document provides an analysis of 6371 "Operations, Administration, and Maintenance Framework for MPLS-
the existing MPLS-TP OAM mechanisms for the path segment monitoring Based Transport Networks" has drawbacks. This document provides an
and provides requirements to guide the development of new OAM tools analysis of the existing MPLS-TP OAM mechanisms for the path segment
to support a Hitless Path Segment Monitoring (HPSM). monitoring and provides requirements to guide the development of new
OAM tools to support a Hitless Path Segment Monitoring (HPSM).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 August 5, 2017. This Internet-Draft will expire on September 9, 2017.
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 42 skipping to change at page 2, line 42
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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
a transport path and that can provide a detailed analysis is a transport path and that can provide a detailed analysis is
indispensable to promptly and accurately localize the fault. A path indispensable to promptly and accurately localize the fault. A path
segment monitoring function has been defined to perform this task for segment monitoring function has been defined to perform this task for
MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371 MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371
[RFC6371], the current method for segment monitoring of a transport [RFC6371], the current method for segment monitoring 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.
This document, after elaborating on the problem statement for the This document, after elaborating on the problem statement for the
path segment monitoring function as it is currently defined, provides path segment monitoring function as it is currently defined, provides
requirements for an on-demand segment monitoring function without requirements for an on-demand segment monitoring function without
traffic distruption. traffic distruption. Further works are required to evaluate how
proposed requirements match with current MPLS architecture and to
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 ATM - Asynchronous Transfer Mode
skipping to change at page 5, line 39 skipping to change at page 5, line 39
unexpected treatment of SPME labels can result in false detection of unexpected treatment of SPME labels can result in false detection of
a fault where no problem existed originally. a fault where no problem existed originally.
Figure 1 shows an example of SPME settings. In the figure, "X" is Figure 1 shows an example of SPME settings. In the figure, "X" is
the label value of the original path expected at the tail-end of node the label value of the original path expected at the tail-end of node
D. "210" and "220" are label values allocated for SPME. The label D. "210" and "220" are label values allocated for SPME. The label
values of the original path are modified as well as the values of the values of the original path are modified as well as the values of the
stacked labels. As shown in Figure 1, SPME changes both the length stacked labels. As shown in Figure 1, SPME changes both the length
of MPLS frames and the label value(s). In particular, performance of MPLS frames and the label value(s). In particular, performance
monitoring measurements (e.g. Delay Measurement and Packet Loss monitoring measurements (e.g. Delay Measurement and Packet Loss
Measurement) are sensitive to these changes. Measurement) are sensitive to these changes. As an example,
increasing the packet lenght may impact on packet loss due to MTU
settings, modifying the label stack may introduce packet loss or it
may fix packet loss depending on the configuration status so
modifying network conditions. Such changes influence packets delay
too even if, from a practical point of view, it is likely that only a
few services will experience a practical impact.
(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 7, line 16 skipping to change at page 7, line 16
carrier or inter-domain segment monitoring where they are typically carrier or inter-domain segment monitoring where they are typically
pre- configured or pre-instantiated. SPME instantiates a pre- configured or pre-instantiated. SPME instantiates a
hierarchical path (introducing MPLS label stacking) through which OAM hierarchical path (introducing MPLS label stacking) through which OAM
packets can be sent. The SPME monitoring function is also mainly packets can be sent. The SPME monitoring function is also mainly
important for protecting bundles of transport paths and carriers' important for protecting bundles of transport paths and carriers'
carrier solutions within an administrative domain. carrier solutions within an administrative domain.
The analogy for SPME in other transport technologies is Tandem The analogy for SPME in other transport technologies is Tandem
Connection Monitoring (TCM), used in Optical Transport Networks (OTN) Connection Monitoring (TCM), used in Optical Transport Networks (OTN)
and Ethernet transport networks, which supports on-demand but does and Ethernet transport networks, which supports on-demand but does
not affect the path. For exampla in OTN, TCM allows the insertion not affect the path. For example in OTN, TCM allows the insertion
and removal of performance monitoring overhead within the frame at and removal of performance monitoring overhead within the frame at
intermediate points in the network. It is done such that their intermediate points in the network. It is done such that their
insertion and removal do not change the conditions of the path. insertion and removal do not change the conditions of the path.
Though as the OAM overhead is part of the frame (designated overhead Though as the OAM overhead is part of the frame (designated overhead
bytes), it is constrained to a pre-defined number of monitoring bytes), it is constrained to a pre-defined number of monitoring
segments. segments.
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 the number of managed pre-configuration in terms of increasing the number of managed
skipping to change at page 10, line 10 skipping to change at page 10, line 10
*------------------* <= 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
on-demand HPSM on-demand HPSM
4.6. Arbitrary segment monitoring 4.6. Arbitrary segment monitoring
The main objective for on-demand segment monitoring is to diagnose The main objective for on-demand segment monitoring is to diagnose
the fault locations. A possible realistic diagnostic procedure is to the fault locations. A possible realistic diagnostic procedure is to
fix one end point of a segment at the MEP of the transport path under fix one end point of a segment at the MEP of the transport path under
observation and change progressively the length of the segments. observation and change progressively the length of the segments. It
This example is shown in Figure 5. is therefore possible to monitoring step by step all the path with a
granularity that depends on equipment implementations. For example,
Figure 5 shows the case where the granularity is at interface level
(i.e. monitoring is at each input interface and output interface of
each piece of equipment).
--- --- --- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | | | | | |
| 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.
*-----* <= 1st on-demand HPSM *-----* <= 1st on-demand HPSM
*-------* <= 2nd on-demand HPSM *-------* <= 2nd on-demand HPSM
| | | |
skipping to change at page 14, line 20 skipping to change at page 14, line 20
interface model specified in RFC 6371 [RFC6371]. interface model specified in RFC 6371 [RFC6371].
The on-demand segment monitoring without traffic disruption solution The on-demand segment monitoring without traffic disruption solution
needs to support on-demand Packet Loss Measurement and Packet Delay needs to support on-demand Packet Loss Measurement and Packet Delay
Measurement functions and optionally other performance monitoring and Measurement functions and optionally other performance monitoring and
fault management functions (e.g. Throughput measurement, Packet fault management functions (e.g. Throughput measurement, Packet
Delay variation measurement, Diagnostic test, etc.). Delay variation measurement, Diagnostic test, etc.).
6. Security Considerations 6. Security Considerations
The security considerations defined for MPLS Transport Profile Security is a significant requirement of MPLS Transport Profile. The
Framework in RFC 5921 [RFC5921] apply to this document as well. The document provides a problem statement and requirements to guide the
document provides the requirements for a new construct for development of new OAM tools to support Hitless Path Segment
performance monitoring that would make use of existing OAM tools that Monitoring. Such new tools must follow the security considerations
follow the security considerations provided in OAM Requirements for provided in OAM Requirements for MPLS-TP in RFC5860 [RFC5860].
MPLS-TP in RFC5860 [RFC5860].
7. IANA Considerations 7. IANA Considerations
There are no requests for IANA actions in this document. There are no requests for IANA actions in this document.
Note to the RFC Editor - this section can be removed before Note to the RFC Editor - this section can be removed before
publication. publication.
8. Contributors 8. Contributors
 End of changes. 11 change blocks. 
21 lines changed or deleted 33 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/