--- 1/draft-ietf-mpls-tp-temporal-hitless-psm-12.txt 2017-03-08 01:13:34.189124551 -0800 +++ 2/draft-ietf-mpls-tp-temporal-hitless-psm-13.txt 2017-03-08 01:13:34.221125304 -0800 @@ -1,54 +1,55 @@ Network Working Group A. D'Alessandro Internet-Draft Telecom Italia Intended status: Informational L. Andersson -Expires: August 5, 2017 Huawei Technologies +Expires: September 9, 2017 Huawei Technologies S. Ueno NTT Communications K. Arai Y. Koike NTT - February 1, 2017 + March 8, 2017 - Hitless path segment monitoring - draft-ietf-mpls-tp-temporal-hitless-psm-12.txt + Requirements for hitless MPLS path segment monitoring + draft-ietf-mpls-tp-temporal-hitless-psm-13.txt Abstract One of the most important OAM capabilities for transport network operation is fault localisation. An in-service, on-demand segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between end points. However, the current segment monitoring approach defined for MPLS (including the transport profile (MPLS-TP)) in RFC - 6371 [RFC6371] has drawbacks. This document provides an analysis of - the existing MPLS-TP OAM mechanisms for the path segment monitoring - and provides requirements to guide the development of new OAM tools - to support a Hitless Path Segment Monitoring (HPSM). + 6371 "Operations, Administration, and Maintenance Framework for MPLS- + Based Transport Networks" has drawbacks. This document provides an + analysis of the existing MPLS-TP OAM mechanisms for the path segment + monitoring and provides requirements to guide the development of new + OAM tools to support a Hitless Path Segment Monitoring (HPSM). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,21 +74,21 @@ 4.5. HPSM and end-to-end proactive monitoring independence . . 9 4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12 4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], mechanisms MUST be available for alerting service providers of faults or defects that affects their services. In addition, to ensure that faults or service degradation can be localized, operators need a @@ -99,21 +100,23 @@ a transport path and that can provide a detailed analysis is indispensable to promptly and accurately localize the fault. A path segment monitoring function has been defined to perform this task for MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371 [RFC6371], the current method for segment monitoring of a transport path has implications that hinder the usage in an operator network. This document, after elaborating on the problem statement for the path segment monitoring function as it is currently defined, provides 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.1. Terminology ATM - Asynchronous Transfer Mode @@ -214,21 +217,27 @@ unexpected treatment of SPME labels can result in false detection of a fault where no problem existed originally. 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 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 stacked labels. As shown in Figure 1, SPME changes both the length of MPLS frames and the label value(s). In particular, performance 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) --- --- --- --- --- | | | | | | | | | | | | | | | | | | | | --- --- --- --- --- A--100--B--110--C--120--D--130--E <= transport path MEP MEP (After SPME settings) @@ -275,21 +284,21 @@ carrier or inter-domain segment monitoring where they are typically pre- configured or pre-instantiated. SPME instantiates a hierarchical path (introducing MPLS label stacking) through which OAM packets can be sent. The SPME monitoring function is also mainly important for protecting bundles of transport paths and carriers' carrier solutions within an administrative domain. The analogy for SPME in other transport technologies is Tandem Connection Monitoring (TCM), used in Optical Transport Networks (OTN) 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 intermediate points in the network. It is done such that their insertion and removal do not change the conditions of the path. Though as the OAM overhead is part of the frame (designated overhead bytes), it is constrained to a pre-defined number of monitoring segments. To summarize: the problem statement is that the current sub-path maintenance based on a hierarchical LSP (SPME) is problematic for pre-configuration in terms of increasing the number of managed @@ -405,22 +414,26 @@ *------------------* <= On-demand HPSM Figure 4: Independence between proactive end-to-end monitoring and on-demand HPSM 4.6. Arbitrary segment monitoring The main objective for on-demand segment monitoring is to diagnose 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 - observation and change progressively the length of the segments. - This example is shown in Figure 5. + observation and change progressively the length of the segments. It + 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 | --- --- --- --- --- MEP MEP <= ME of a transport path +-----------------------------+ <= Pro-active end-to-end mon. *-----* <= 1st on-demand HPSM *-------* <= 2nd on-demand HPSM | | @@ -577,26 +590,25 @@ interface model specified in RFC 6371 [RFC6371]. The on-demand segment monitoring without traffic disruption solution needs to support on-demand Packet Loss Measurement and Packet Delay Measurement functions and optionally other performance monitoring and fault management functions (e.g. Throughput measurement, Packet Delay variation measurement, Diagnostic test, etc.). 6. Security Considerations - The security considerations defined for MPLS Transport Profile - Framework in RFC 5921 [RFC5921] apply to this document as well. The - document provides the requirements for a new construct for - performance monitoring that would make use of existing OAM tools that - follow the security considerations provided in OAM Requirements for - MPLS-TP in RFC5860 [RFC5860]. + Security is a significant requirement of MPLS Transport Profile. The + document provides a problem statement and requirements to guide the + development of new OAM tools to support Hitless Path Segment + Monitoring. Such new tools must follow the security considerations + provided in OAM Requirements for MPLS-TP in RFC5860 [RFC5860]. 7. IANA Considerations There are no requests for IANA actions in this document. Note to the RFC Editor - this section can be removed before publication. 8. Contributors