MPLS Working Group A. D'Alessandro Internet Draft Telecom Italia M.Paul Deutsche Telekom Intended status: Informational S. Ueno NTT Communications Y.Koike NTT Expires: January 13, 2012 July 11, 2011 Temporal and hitless path segment monitoring draft-koike-mpls-tp-temporal-hitless-psm-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 13, 2011. Copyright Notice Copyright (c) 2011 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 Koike Expires January 13, 2012 [Page 1] Internet-Draft Temporal and hitless PSM July 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. One of the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which are common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the path segment monitoring function. Moreover, this document requests to add network objectives to solve or improve the issues and proposes to consider a new improved method of segment monitoring. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. Table of Contents 1. Introduction ................................................ 4 2. Conventions used in this document............................ 4 2.1. Terminology ............................................... 5 2.2. Definitions ............................................... 5 3. Network objectives for monitoring............................ 5 4. Problem statement ........................................... 5 5. OAM functions for segment monitoring .........................8 Koike Expires January 13, 2012 [Page 2] Internet-Draft Temporal and hitless PSM July 2011 6. Further consideration of requirements for enhanced segment monitoring .................................................... 10 6.1. Necessity of on-demand single-layer monitoring ............10 6.2. Necessity of on-demand monitoring independent from proactive monitoring .................................................... 11 6.3. On-demand diagnostic procedures........................... 11 7. Conclusion ................................................. 12 8. Security Considerations..................................... 13 9. IANA Considerations ........................................ 13 10. References ................................................ 13 10.1. Normative References..................................... 13 10.2. Informative References................................... 14 11. Acknowledgments ........................................... 14 Koike Expires January 13, 2012 [Page 3] Internet-Draft Temporal and hitless PSM July 2011 1. Introduction A packet transport network will enable carriers or service providers to use network resources efficiently, reduce operational complexity and provide carrier-grade network operation. Appropriate maintenance functions, supporting fault location, survivability, performance monitoring and preliminary or in-service measurements, are essential to ensure quality and reliability of a network. They are essential in transport networks and have evolved along with TDM, ATM, SDH and OTN. Unlike in SDH or OTN networks, where OAM is an inherent part of every frame and frames are also transmitted in idle mode, it is not per se possible to constantly monitor the status of individual connections in packet networks. Packet-based OAM functions are flexible and selectively configurable according to operators' needs. According to the MPLS-TP OAM requirements [1], mechanisms MUST be available for alerting a service provider of a fault or defect affecting the service(s) provides. In addition, to ensure that faults or degradations can be localized, operators need a method to analyze or investigate the problem. From the fault localization perspective, end-to-end monitoring is insufficient. Using end-to-end OAM monitoring, when one problem occurs in an MPLS-TP network, the operator can detect the fault, but is not able to localize it. Thus, a specific segment monitoring function for detailed analysis, by focusing on and selecting a specific portion of a transport path, is indispensable to promptly and accurately localize the fault point. For MPLS-TP, a path segment monitoring function has been defined to perform this task. However, as noted in the MPLS-TP OAM Framework[5], the current method for segment monitoring function of a transport path has implications that hinder the usage in an operator network. This document elaborates on the problem statement for the path segment monitoring function. Moreover, this document requests to add network objectives to solve or improve the issues and proposes to reconsider the new improved method of the segment monitoring. 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 [1]. Koike Expires January 13, 2012 [Page 4] Internet-Draft Temporal and hitless PSM July 2011 2.1. Terminology LSP Label Switched Path OTN Optical Transport Network PST Path Segment Tunnel TCM Tandem connection monitoring SDH Synchronous Digital Hierarchy SPME Sub-path Maintenance Element 2.2. Definitions None 3. Network objectives for monitoring There are two indispensable network objectives in the current on- going MPLS-TP standard as described in section 3.8 of [5]. (1) The monitoring and maintenance of current transport paths has to be conducted in service without traffic disruption. (2) Segment monitoring must not modify the forwarding of the segment portion of the transport path. It was agreed in ITU-T SG15 that Network objective (1) is mandatory and that regarding Network objective (2) the monitoring shall be hitless and not change the forwarding behavior. 4. Problem statement To monitor, protect, or manage a portion of a transport path, such as LSP in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is defined in [2]. The SPME is defined between the edges of the portion of the LSP that needs to be monitored, protected, or managed. This SPME is created by stacking the shim header (MPLS header)[3] and is defined as the segment 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 along the SPME by setting the TTL value of the label stack entry (LSE) and interface identifier value at the corresponding hierarchical LSP level in a per-node model. Koike Expires January 13, 2012 [Page 5] Internet-Draft Temporal and hitless PSM July 2011 This method has the following general issues, which are fatal in terms of cost and operation. (P-1) Increasing the overhead by the stacking of shim header(s) (P-2) Increasing the address management complexity, as new MEPs and MIPs need to be configured for the SPME in the old MEG Problem (P-1) leads to decreased efficiency as bandwidth is wasted. As the size of monitored segments increases, the size of the label stack grows. Moreover, if operator wants to monitor the portion of a transport path without 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-demand. Consuming additional bandwidth permanently for the monitoring purpose should be avoided to maximize the available bandwidth. Problem (P-2) is related to an identifier issue, of which the discussion is still continuing and not so critical at the moment, but can be quite inefficient if the policy of allocating the identifier is different in each layer. Moreover, from the perspective of operation, increasing the managed addresses and the managed layer is not desirable in terms of simplified operation featured by current transport networks. Reducing the managed identifier and managed layer should be the fundamental direction in designing the architecture. The most familiar example for SPME in transport networks is tandem connection monitoring (TCM), which can for example be used for a carrier's carrier solution, as shown in Fig. 17 of the framework document[2]. However, in this case, the SPMEs have to be pre- configured. If this solution is applied to specific segment monitoring within one operator domain, all the necessary specific segments have to be pre-configured. This setting increases the managed objects as well as the necessary bandwidth, shown as Problem (P-1) and (P-2). To avoid these issues, the temporal setting of the SPME(s) only when necessary seems reasonable and efficient for monitoring in MPLS-TP transport network operation. Unfortunately, the temporal settings of SPMEs also cause the following problems due to label stacking, which are fatal in terms of intrinsic monitoring and service disruption. (P'-1) Changing the condition of the original transport path by changing the length of the MPLS frame (delay measurement and loss measurement can be sensitive) Koike Expires January 13, 2012 [Page 6] Internet-Draft Temporal and hitless PSM July 2011 (P'-2) Disrupting client traffic over a transport path, if the SPME is temporally configured. Problem (P'-1) is a fatal problem in terms of intrinsic monitoring. The monitoring function checks the status without changing any conditions of the targeted monitored segment or the transport path. If the conditions of the transport path change, the measured value or observed data will also change. This can make the monitoring meaningless because the result of the monitoring would no longer reflect the reality of the connection where the original fault or degradation occurred. In addition, changing the settings of the original shim header should not be allowed because those changes correspond to creating a new portion of the original transport path, which is completely different from the original circumstances. Figure 1 shows an example of SPME setting. In the figure, X means the one label expected on the tail end node D of the original transport path. "210" and "220" are label allocated for SPME. The label values of the original path are modified as well as the values of stacked label. This is not the monitoring of the original transport path but the monitoring of a different path. (Before SPME settings) --- --- --- --- --- | | | | | | | | | | | | | | | | | | | | --- --- --- --- --- A--100--B--110--C--120--D -- - - -130 -- - - -E <= transport path MEP MEP (After SPME settings) --- --- --- --- --- | | | | | | | | | | | | | | | | | | | | --- --- --- --- --- A---100--B-------X-------D--130--E MEP \ / MEP <= transport path --210--C--220-- <= SPME MEP' MEP' Figure 1 : An Example of a SPME setting Problem (P'-2) was not fully discussed, although the make-before- break procedure in the survivability document [4] seemingly supports the hitless configuration for monitoring according to the framework Koike Expires January 13, 2012 [Page 7] Internet-Draft Temporal and hitless PSM July 2011 document [2]. The reality is the hitless configuration of SPME is impossible without affecting the circumstances of the targeted transport path, because the make-before-break procedure is premised on the change of the label value. This means changing one of the settings in MPLS shim header and should not be allowed as explained in (P'-1) above. Moreover, this might not be effective under the static model without a control plane because the make-before-break is a restoration application based on the control plane. The removal of SPME whose segment is monitored could have the same impact (disruption of client traffics) as creation of an SPME on the same LSP. The other potential risks are also envisaged. Setting up a temporal SPME will result in the LSRs within the monitoring segment only looking at the added (stacked) labels and not at the labels of the original LSP. This means that problems stemming from incorrect (or unexpected) treatment of labels of the original LSP by the nodes within the monitored segment may disappear when setting up SPME. This might include hardware problems during label look-up, mis- configuration etc. Therefore operators have to pay extra attention to correctly setting and checking the label values of the original LSP in the configuration. Of course, the inversion of this situation is also possible, .e.g., incorrect or unexpected treatment of SPME labels can result in false detection of a fault where none of the problem originally existed. The way MPLS works requires use of SPMEs to be designed in advance, hence the utility of SPMEs is basically limited. To summarize, the problem statement is that the current sub-path maintenance based on a hierarchical LSP (SPME) is problematic in terms of increasing bandwidth by label stacking and managing objects by layer stacking and address management. A temporal configuration of SPME is one of the possible approaches for minimizing the impact of these issues. However, the current method is unfavorable because the temporal configuration for monitoring can change the condition of the original monitored transport path and disrupt the in-service customer traffic. From the perspective of monitoring in transport network operation, a solution avoiding those issues or minimizing their impact is required. 5. OAM functions using segment monitoring OAM functions in which segment monitoring is required are basically limited to on-demand monitoring which are defined in OAM framework document [5], because those segment monitoring functions are used to Koike Expires January 13, 2012 [Page 8] Internet-Draft Temporal and hitless PSM July 2011 locate the fault/degraded point or to diagnose the status for detailed analyses, especially when a problem occurred. Packet loss and packet delay measurements are OAM functions in which hitless and temporal segment monitoring are strongly required because these functions are supported only between end points of a transport path. If a fault or defect occurs, there is no way to locate the defect or degradation point without using the segment monitoring function. If an operator cannot locate or narrow the cause of the fault, it is quite difficult to take prompt action to solve the problem. Therefore, temporal and hitless monitoring for packet loss and packet delay measurements are indispensable for transport network operation. Regarding other on-demand monitoring functions, segment monitoring is desirable, but not as urgent as for packet loss and packet delay measurements. Regarding out-of-service on-demand monitoring functions, such as diagnostic tests, there seems no need for hitless settings. However, specific segment monitoring should be applied to the OAM function of diagnostic test. See section 6.3. Note: The reason only on-demand OAM functions are discussed at this point is because the characteristic of "on-demand" is generally temporal for maintenance operation. Thus, operations should not be based on pre-configuration. Pre-design and pre-configuration of PST/TCM (label stacking) for all the possible patterns for the on-demand (temporal) usage are not reasonable, because these tasks will increase the operator's burden, although pre-configuration of PST for pro-active usage may be accepted considering the agreement thus far. Therefore, the solution for temporal and hitless segment monitoring does not need to be limited to label stacking mechanisms, such as PST/TCM(label stacking), which can cause the issues (P-1) and (P-2) described in Section 4. The solution for temporal and hitless segment monitoring has to cover both per-node model and per-interface model which are specified in [5]. Koike Expires January 13, 2012 [Page 9] Internet-Draft Temporal and hitless PSM July 2011 6. Further consideration of requirements for enhanced segment monitoring An existing segment monitoring function relates to SPME that instantiates a hierarchical transport path (introducing MPLS label stacking) through which OAM packets can be sent. SPME construct monitoring function is particularly important mainly for protecting bundles of transport paths and carriers' carrier solutions. From this perspective, monitoring function related to can be considered ''proactive multi-layer monitoring,'' which has already been determined by consensus to be mandatory in MPLS-TP. 6.1. Necessity of on-demand single-layer monitoring In contrast to the ''proactive multi-layer monitoring'' so called ''SPME'', the new segment monitoring function is supposed to be applied mainly for diagnostic purpose on-demand. We can differentiate this monitoring from the proactive segment monitoring as on-demand (multi- layer) monitoring. The most serious problem at the moment is that there is no way to localize the degradation point on a path without changing the conditions of the original path. Therefore, as a first step, single layer segment monitoring not affecting the monitored path is required for a new on-demand and hitless segment monitoring function. A combination of multi-layer and simultaneous monitoring is the most powerful tool for accurately diagnosing the performance of a transport path. However, considering the balance of estimated implementation difficulties and the substantial benefits to operators, a strict monitoring function such as in a test environment in a laboratory does not seem to be necessary in the field. To summarize, on-demand and in-service (hitless) single-layer segment monitoring is required, but the need for on-demand and in-service multi-layer segment monitoring is not as urgent at the moment. Figure 2 shows an example of a multi-layer on-demand segment monitoring. --- --- --- --- --- | | | | | | | | | | | A | | B | | C | | D | | E | --- --- --- --- --- MEP MEP <= ME of a transport path +-----------------------------+ <= End-to-end monitoring *------------------* <= segment monitoring layer1 *-------------* <= segment monitoring layer2 *-* <= segment monitoring layer3 Figure 2 : An Example of a multi-layer on-demand segment monitoring Koike Expires January 13, 2012 [Page 10] Internet-Draft Temporal and hitless PSM July 2011 6.2. Necessity of on-demand monitoring independent from proactive monitoring As multi-layer simultaneous monitoring only in layers for on-demand monitoring was already discussed in section6.1, we consider the necessity of simultaneous proactive and on-demand monitoring. Normally, on-demand segment monitoring is configured in a segment of a maintenance entity of a transport path. In this environment, on- demand single-layer monitoring should be done irrespective of the status of pro-active monitoring of the targeted end-to-end transport path. If operators have to disable the pro-active monitoring during ''on- demand and in-service'' segment monitoring, the network operation system might miss any performance degradation of user traffic. This kind of inconvenience should be avoided in the network operations. From this perspective, the ability for on-demand single layer segment monitoring is required without changing or interfering the proactive monitoring of the original end-to-end transport path. --- --- --- --- --- | | | | | | | | | | | A | | B | | C | | D | | E | --- --- --- --- --- MEP MEP <= ME of a transport path +-----------------------------+ <= Proactive E2E monitoring *------------------* <= On-demand segment monitoring Figure 3 : Relation between proactive end-to-end monitoring and on- demand segment monitoring 6.3. On-demand diagnostic procedures The main objective of on-demand segment monitoring is to diagnose the fault points. One possible diagnostic procedure is to fix one end point of a segment at the MEP of a transport path and change progressively the length of the segment in order. This example is shown in Fig. 4. This approach is considered as a common and realistic diagnostic procedure. In this case, one end point of a segment can be anchored at MEP at any time. Other scenarios are also considered, one shown in Fig. 5. In this case, the operators want to diagnose a transport path from a transit node that is located at the middle, because the end nodes(A and E) are located at customer sites and consist of cost effective small box in which a subset of OAM functions are supported. In this case, if Koike Expires January 13, 2012 [Page 11] Internet-Draft Temporal and hitless PSM July 2011 one end point and an originator of the diagnostic packet are limited to the position of MEP, on-demand segment monitoring will be ineffective because all the segments cannot be diagnosed (For example, segment monitoring 3 in Fig.5 is not available and it is not possible to localize the fault point). --- --- --- --- --- | | | | | | | | | | | A | | B | | C | | D | | E | --- --- --- --- --- MEP MEP <= ME of a transport path +-----------------------------+ <= Proactive E2E monitoring *-----* <= 1st On-demand segment monitoring *-------* <= 2nd On-demand segment monitoring *------------* <= 3rd On-demand segment monitoring | | *-----------------------* <= 6th On-demand segment monitoring *-----------------------------*<= 7th On-demand segment monitoring Figure 4 : One possible procedure to localize a fault point by sequential on-demand segment monitoring Accordingly, on-demand monitoring of arbitrary segments is mandatory in the case in Fig. 5. As a result, on-demand and in-service segment monitoring should be set in an arbitrary segment of a transport path and diagnostic packets should be inserted from at least any of intermediate maintenance points of the original ME. --- --- --- --- | | | | | | --- | A | | B | | C | | D | | E | --- --- --- --- --- MEP MEP <= ME of a transport path +-----------------------------+ <= Proactive E2E monitoring *-----* <= On-demand segment monitoring 1 *-----------------------*<= On-demand segment monitoring 2 *---------* <= On-demand segment monitoring 3 Figure 5 : Example where on-demand monitoring has to be configured in arbitrary segments 7. Conclusion It is requested that the two network objectives mentioned in Section 3 are met by MPLS-TP OAM solutions which has been already described in section 3.8 of [5]. The enhancements should minimize the issues Koike Expires January 13, 2012 [Page 12] Internet-Draft Temporal and hitless PSM July 2011 described in Section 4,, i.e., P-1, P-2, P'-1 and P'-2, to meet those two network objectives. In addition, the following requirements should be considered for an enhanced temporal and hitless path segment monitoring function. - An on-demand and in-service ''single-layer'' segment monitoring is proposed. Multi-layer segment monitoring is optional. - ''On-demand and in-service'' single layer segment should be done without changing or interfering any condition of pro-active monitoring of an original ME of a transport path. - On-demand and in-service segment monitoring should be able to be set in an arbitrary segment of a transport path. 8. Security Considerations This document does not by itself raise any particular security considerations. 9. IANA Considerations There are no IANA actions required by this draft. 10. References 10.1. Normative References [1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", RFC5860, May 2010 [2] Bocci, M., et al., "A Framework for MPLS in Transport Networks", RFC5921, July 2010 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 [4] Sprecher, N., Farrel, A. , ''Multiprotocol Label Switching Transport Profile Survivability Framework'', draft-ietf-mpls-tp- survive-fwk-06.txt(work in progress), June 2010 [5] Busi, I., Dave, A. , "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", draft-ietf-mpls-tp-oam-framework-11.txt(work in progress), February 2011 Koike Expires January 13, 2012 [Page 13] Internet-Draft Temporal and hitless PSM July 2011 10.2. Informative References None 11. Acknowledgments The author would like to thank all members (including MPLS-TP steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. The authors would also like to thank Alexander Vainshtein, Dave Allan, Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm Betts and Nurit Sprecher for their comments and enhancements to the text. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Alessandro D'Alessandro Telecom Italia Email: alessandro.dalessandro@telecomitalia.it Manuel Paul Deutsche Telekom Email: Manuel.Paul@telekom.de Satoshi Ueno NTT Communications Email: satoshi.ueno@ntt.com Yoshinori Koike NTT Email: koike.yoshinori@lab.ntt.co.jp Koike Expires January 13, 2012 [Page 14]