--- 1/draft-ietf-mpls-tp-temporal-hitless-psm-06.txt 2015-07-22 07:16:34.667734934 -0700 +++ 2/draft-ietf-mpls-tp-temporal-hitless-psm-07.txt 2015-07-22 07:16:34.787737828 -0700 @@ -1,157 +1,153 @@ Network Working Group A. D'Alessandro Internet-Draft Telecom Italia Intended status: Standards Track L. Andersson -Expires: August 30, 2015 Huawei Technologies +Expires: January 21, 2016 Huawei Technologies M. Paul Deutsche Telekom S. Ueno + NTT Communications K. Arai Y. Koike NTT - February 26, 2015 + July 20, 2015 - Temporal and hitless path segment monitoring - draft-ietf-mpls-tp-temporal-hitless-psm-06.txt + Enhanced path segment monitoring + draft-ietf-mpls-tp-temporal-hitless-psm-07.txt Abstract - The MPLS transport profile (MPLS-TP) is being standardized to enable + The MPLS transport profile (MPLS-TP) has been standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP - are OAM functions, which enable network operators or service + there 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. + fault location, survivability, performance monitoring and in-service/ + out of service measurements. One of the most important mechanisms which is 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 + defined for MPLS-TP for the segment monitoring (SPME) has some drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new - improved mechanism of hitless transport path segment monitoring. + improved mechanism of hitless transport path segment monitoring named + Enhanced Path Segment Monitoring (EPSM). 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 30, 2015. + This Internet-Draft will expire on January 21, 2016. Copyright Notice Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions used in this document . . . . . . . . . . . . . . 4 + 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Network objectives for monitoring . . . . . . . . . . . . . . 4 - 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 - 5. OAM functions using segment monitoring . . . . . . . . . . . 9 - 6. Further consideration of requirements for enhanced - segmentmonitoring . . . . . . . . . . . . . . . . . . . . . . 10 - 6.1. Necessity of on-demand single-level monitoring . . . . . 10 - 6.2. Necessity of on-demand monitoring independent from end- - to-end proactive monitoring . . . . . . . . . . . . . . . 10 - 6.3. Necessity of arbitrary segment monitoring . . . . . . . 11 - 6.4. Fault during HPSM in case of protection . . . . . . . . . 13 - 6.5. Consideration of maintenance point for HPSM . . . . . . . 14 - 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + 3. Network objectives for segment monitoring . . . . . . . . . . 4 + 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 + 5. OAM functions supported in segment monitoring . . . . . . . . 8 + 6. Requirements for enhanced segment monitoring . . . . . . . . 8 + 6.1. Non intrusive segment monitoring . . . . . . . . . . . . 9 + 6.2. Single and multiple levels monitoring . . . . . . . . . . 9 + 6.3. EPSM and end-to-end proactive monitoring independence . . 10 + 6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 + 6.5. Fault while EPSM is in place . . . . . . . . . . . . . . 12 + 6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13 + 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 + A packet transport network enables carriers or service providers to + use network resources efficiently, reduces operational complexity and + provides 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. + As legacy technologies, also MPLS-TP does not scale when an arbitrary + number of OAM functions are enabled. According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], mechanisms MUST be available for alerting a service provider of a - fault or defect affecting the service(s) provided. 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. + fault or defect affecting services. In addition, to ensure that + faults or degradations can be localized, operators need a method to + analyze or investigate the problem being end-to-end monitoring + insufficient. In fact using end-to-end OAM monitoring, an operator + is not able to localize a fault or degrade. Thus, a specific segment monitoring function for detailed analysis, - by focusing on and selecting a specific portion of a transport path, + by selecting and focusing on a specific portion of a transport path, is indispensable to promptly and accurately localize the fault. For MPLS-TP, a path segment monitoring function has been defined to perform this task. However, as noted in the MPLS-TP OAM Framework RFC 6371 [RFC6371], 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 and proposes to consider a new improved - method of the segment monitoring, following up the work done in RFC - 6371 [RFC6371]. Moreover, this document explains detailed - requirements on the new temporal and hitless segment monitoring - function which are not covered in RFC 6371 [RFC6371]. + method for segment monitoring, following up the work done in RFC 6371 + [RFC6371]. Moreover, this document explains detailed requirements on + the new temporal and hitless segment monitoring function which are + not covered in RFC 6371 [RFC6371]. 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 - HPSM - Hitless Path Segment Monitoring + EPSM - Enhanced Path Segment Monitoring LSP - Label Switched Path LSR - Label Switching Router ME - Maintenance Entity MEG - Maintenance Entity Group MEP - Maintenance Entity Group End Point @@ -165,496 +161,433 @@ TCM - Tandem connection monitoring SDH - Synchronous Digital Hierarchy SPME - Sub-path Maintenance Element 2.2. Definitions None. -3. Network objectives for monitoring +3. Network objectives for segment monitoring - There are two indispensable network objectives for MPLS-TP networks - as described in section 3.8 of RFC 6371 [RFC6371]. + There are two required network objectives for MPLS-TP segment + monitoring as described in section 3.8 of RFC 6371 [RFC6371]. 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 is common in transport networks that network objective (1) is - mandatory and that regarding network objective (2) the monitoring - shall not change the forwarding behavior. - 4. Problem Statement - To monitor, protect, or manage portions of transport paths, such as - LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is - defined in RFC 5921 [RFC5921]. The SPME is defined between the edges - of the portion of the transport path that needs to be monitored, + Sub-Path Maintenance Element (SPME) is defined in RFC 5921 [RFC5921] + to monitor, protect, or manage portions of transport paths, such as + LSPs in MPLS-TP networks. The SPME is defined between the edges of + the portion of the transport path that needs to be monitored, protected, or managed. This SPME is created by stacking the shim - header (MPLS header) RFC 3031 [RFC3031] 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 + header (MPLS header) according to RFC 3031 [RFC3031] 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 case of per-node model. - 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 + This method has the following drawbacks, which impact on operation + costs: - Problem (P-1) leads to decreased efficiency as bandwidth is wasted - only for maintenance purposes. As the size of monitored segments - increases, the size of the label stack grows. Moreover, if the - 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 only the - monitoring purpose should be avoided to maximize the available - bandwidth. + (P-1) Lowering the bandwidth efficiency by increasing the overhead + by shim headers stacking - Problem (P-2) is related to an identifier-management issue. The - identification of each layer in case of LSP label stacking is - required in terms of strict sub-layer management for the segment - monitoring in a MPLS-TP network. When SPME/TCM is applied for on- - demand OAM functions in MPLS-TP networks in a similar manner to OTN - or Ethernet transport networks, a possible rule of differentiating - those SPME/TCMs operationally will be necessary at least within an - administrative domain. This enforces operators to create an - additional permanent layer identification policy only for temporal - path segment monitoring. 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 identifiers and managed - layers should be the fundamental direction in designing the - architecture. + (P-2) Increasing network management complexity, as a new sublayer + and new MEPs and MIPs need to be configured for the SPME - 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 RFC 5921 [RFC5921]. 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). Moreover, as a result of these pre- - configurations, they impose operators to pre-design the structure of - sub-path maintenance elements, which is not preferable in terms of - operators' increased burden. These concerns are summarized in - section 3.8 of RFC 6371 [RFC6371]. + Problem (P-1) comes from shim headers stacking that increase the + overhead. - Furthermore, in reality, all the possible patterns of path segment - cannot be set in SPME, because overlapping of path segments is - limited to nesting relationship. As a result, possible SPME patterns - of portions of an original transport path are limited due to the - characteristic of SPME shown in Figure.1, even if SPMEs are pre- - configured. This restriction is inconvenient when operators have to - fix issues in an on-demand manner. To avoid these issues, the - temporal and on-demand setting of the SPME(s) is needed and more - efficient for monitoring in MPLS-TP transport network operation. + Problem (P-2) is related to identifiers management issue. The + identification of each sub-layer in case of label stacking is + required for the segment monitoring in a MPLS-TP network. When SPME + is applied for on-demand OAM functions in MPLS-TP networks in a + similar manner to TCM for OTN or Ethernet transport networks, a + possible rule of differentiating those SPME/TCMs operationally will + be necessary at least within an administrative domain. This enforces + operators to create an additional permanent layer identification + policy only for temporal path segment monitoring. Moreover, from the + perspective of operation, increasing the managed addresses and the + managed layers is not desirable to keep transport networks as simple + as possible. Reducing the managed identifiers and managed sub-layers + should be the fundamental direction in designing the architecture. - However, using currently defined methods, the temporal setting of - SPMEs also causes the following problems due to label stacking, which - are fatal in terms of intrinsic monitoring and service disruption. + The analogy for SPME in legacy transport networks is Tandem + Connection Monitoring (TCM), which is on-demand and does not change + the transport path. - (P'-1) Changing the condition of the original transport path by - changing the length of all the MPLS frames and changing label - value(s) + Moreover, using currently defined methods, the temporal setting of + SPMEs also causes the following problems due to label stacking: - (P'-2) Disrupting client traffic over a transport path, if the - SPME is temporally configured. + (P-3) Changing the original condition of transport path by + changing the length of MPLS frames and changing the value of + exposed label - Problem (P'-1) is a fatal problem in terms of intrinsic monitoring. - As shown in network objective (2), the monitoring function needs to - monitor 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. + (P-4) Disrupting client traffic over a transport path, if the SPME + is configured on demand. - Another aspect is that 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 differs - from the original data plane conditions. + Problem (P-3) has impacts on network objective (2). The monitoring + function should monitor the status without changing any conditions of + the targeted monitored segment or transport path. 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 differs from the original data plane + conditions. If the conditions of the transport path change, the + measured value or observed data will also change. This may 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. 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 + the label value 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. As shown in Fig.1, SPME changes the length of all - the MPLS frames and changes label value(s). This is no longer the - monitoring of the original transport path but the monitoring of a - different path. Particularly, performance monitoring measurement - (Delay measurement and loss measurement) are sensitive to those + of stacked label. As shown in Figure 1, SPME changes both the length + of MPLS frames and label value(s). This is no longer the monitoring + of the original transport path but the monitoring of a different + path. Particularly, performance monitoring measurement (e.g. Delay + measurement and packet loss measurement) are sensitive to those changes. (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 + A---100--B-----------X---D--130--E <= transport path + MEP \ / MEP --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 RFC 6371 [RFC6372] - seemingly supports the hitless configuration for monitoring according - to the framework document RFS 5921 [RFC5921]. The reality is the - hitless configuration of SPME is impossible without affecting the - conditions of the targeted transport path, because the make-before- - break procedure is premised on the change of the inner label value. - This means changing one of the settings in MPLS shim header. + Problem (P-4) can be avoided if the operator sets SPMEs in advance + until the end of life of a transport path, which is neither temporal + nor on demand. Furthermore SMPEs cannot be set arbitrarly because + overlapping of path segments is limited to nesting relationship. As + a result, possible SPME patterns of portions of an original transport + path are limited due to the characteristic of SPME shown in Figure 1, + even if SPMEs are pre- configured. - 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 - traffic) as the creation of an SPME on the same LSP. + Although the make-before-break procedure in the survivability + document RFC 6372 [RFC6372] seemingly supports the hitless + configuration for monitoring according to the framework document RFC + 5921 [RFC5921], the reality is that configurating an SPME is + impossible without violating network objective (2). These concerns + are reported in section 3.8 of RFC 6371 [RFC6371]. - Note: (P'-2) will be removed when non-disruptive make-before-break - (in both with and without Control Plane environment) is specified in - other MPLS-TP documents. However, (P'-2) could be replaced with the - following issue. Non-disruptive make-before-break, in other words, - taking an action similar to switching just for monitoring is not an - ideal operation in transport networks. + Moreover, make-before-break approach 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. So management + systems should provide support for SPME creation and for coordinated + traffic switching from original transport path to the SPME. - 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 could not be found when setting up SPME. - This might include hardware problems during label look-up, mis- + 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 could not be found 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 + 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 utility of SPMEs is basically limited to inter-carrier or inter- domain segment monitoring where they are typically pre-configured or pre-instantiated. SPME 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. SPME is expected to be mainly used for protection purpose within one administrative domain. 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 bandwidth by label stacking and managing objects by layer stacking and address management. A on- demand/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. Another monitoring mechanism is therefore required that - supports temporal and hitless path segment monitoring. Hereafter it - is called on-demand hitless path segment monitoring (HPSM). + transport path. To avoid the drawbacks discussed above, a more + efficient approach is required for MPLS-TP transport network + operation to overcome or minimize the impact of the above described + drawbacks. A monitoring mechanism, named on-demand Enhanced Path + Segment Monitoring (EPSM), supporting temporal and hitless path + segment monitoring is proposed. - Note: The above sentence "and disrupt the in-service customer - traffic" might need to be modified depending on the result of future - discussion about (P'-2). +5. OAM functions supported in segment monitoring -5. OAM functions using segment monitoring + OAM functions that may useful exploited across on-demand EPSM are + basically limited to on-demand performance monitoring functions which + are defined in OAM framework document RFC 6371 [RFC6371]. Segment + performance monitoring is used to evaluate the performance and hence + the status of transport path segments. The "on-demand" attribute is + generally temporal for maintenance operation. - OAM functions in which on-demand HPSM is required are basically - limited to on-demand monitoring which are defined in OAM framework - document RFC 6371 [RFC6371], because those segment monitoring - functions are used to locate the fault/degraded point or to diagnose - the status for detailed analyses, especially when a problem occurred. - In other words, the characteristic of "on-demand" is generally - temporal for maintenance operation. Conversely, this could be a good - reason that operations should not be based on pre-configuration and - pre-design. + Packet loss and packet delay are OAM functions strongly required in + hitless and temporal segment monitoring because these functions are + supported only between end points of a transport path. If a defect + occurs, it might be quite hard 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 actions to solve the problem. - 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, on-demand HPSM for packet loss and packet delay - measurements are indispensable for transport network operation. + Other on-demand monitoring functions, (e.g. and Delay variation + measurement) are desirable but not as necessary as the previous + mentioned functions. - Regarding other on-demand monitoring functions path segment - monitoring is desirable, but not as urgent as for packet loss and - packet delay measurements. + Regarding out-of-service on-demand performance management functions + (e.g. Throughput measurement), there seems no need for EPSM. + However, OAM functions specifically designed for segment monitoring + should be developed to satisfy network objective (2) described in + section 3. - Regarding out-of-service on-demand monitoring functions, such as - diagnostic tests, there seems no need for HPSM. However, specific - segment monitoring should be applied to the OAM function of - diagnostic test, because SPME doesn't meet network objective (2) in - section 3. See section 6.3. + Finally, the solution for EPSM has to cover both per-node model and + per- interface model which are specified in RFC 6371 [RFC6371]. - Note: +6. Requirements for enhanced segment monitoring - The solution for temporal and hitless segment monitoring should - not be limited to label stacking mechanisms based on pre- - configuration, such as PST/TCM(label stacking), which can cause - the issues (P-1) and (P-2) described in Section 4. + In the following clauses, mandatory (M) and optional (O) requirements + are for the new segment monitoring function are listed. - The solution for HPSM has to cover both per-node model and per- - interface model which are specified in RFC 6371 [RFC6371]. +6.1. Non intrusive segment monitoring -6. Further consideration of requirements for enhanced segmentmonitoring + One of the major problem of legacy SPME that has been highlighted in + Sec. 4 is that it does not monitor the original transport path and it + could distrupt service traffic when set-up on demand. -6.1. Necessity of on-demand single-level monitoring + (M1) EPSM must not change the original condition of transport path + (e.g. must not change the lenght of MPLS frames, the exposed label + values, etc.) + + (M2) EPSM must be set on demand without traffic dispruption + +6.2. Single and multiple levels monitoring The new segment monitoring function is supposed to be applied mainly - for diagnostic purpose on-demand. We can differentiate this + for on-demand diagnostic purpose. We can differentiate this monitoring from the proactive segment monitoring as on-demand multi- level monitoring. The most serious problem at the moment is that - there is no way to localize the degradation point on a path without + there is no way to localize the degraded portion of 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. + function. A combination of multi-level and simultaneous segment + monitoring is the most powerful tool for accurately diagnosing the + performance of a transport path. However, on field, a single level + approach may be enough. - A combination of multi-level and simultaneous monitoring is the most - powerful tool for accurately diagnosing the performance of a - transport path. However, considering the substantial benefits to - operators, a strict monitoring function which is required in such as - a test environment of a laboratory does not seem to be necessary in - 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 desirable. Figure 2 shows an example of - a multi-level on-demand segment monitoring. + (M3) Single-level segment monitoring is required + + (O1) Multi-level segment monitoring is desirable + + Figure 2 shows an example of a multi-level on-demand segment + monitoring. --- --- --- --- --- | | | | | | | | | | | A | | B | | C | | D | | E | --- --- --- --- --- MEP MEP <= ME of a transport path - +-----------------------------+ <= End-to-end monitoring - *------------------* <= segment monitoring level1 - *-------------* <= segment monitoring level2 - *-* <= segment monitoring level3 + *------------------* <=On-demand segm. monit. level 1 + *-------------* <=On-demand segm. monit. level 2 + *-* <=On-demand segm. monit. level 3 - Figure 2: An Example of a multi-level on-demand segment monitoring + Figure 2: Example of multi-level on-demand segment monitoring -6.2. Necessity of on-demand monitoring independent from end-to-end - proactive monitoring +6.3. EPSM and end-to-end proactive monitoring independence - As multi-level simultaneous monitoring only for on-demand new path - segment monitoring was already discussed in section6.1, next we - consider the necessity of simultaneous monitoring of end-to-end - current proactive monitoring and new on-demand path segment - monitoring. Normally, the on-demand path segment monitoring is - configured in a segment of a maintenance entity of a transport path. - In this environment, on-demand single-level monitoring should be done - without disrupting pro-active monitoring of the targeted end- to-end - transport path. + The necessity of simultaneous monitoring of current end-to-end + proactive monitoring and new on-demand path segment monitoring is + here below considered. Normally, the on-demand path segment + monitoring is configured in a segment of a maintenance entity of a + transport path. In such an environment, on-demand single-level + monitoring should be done without disrupting pro-active monitoring of + the targeted end- to-end transport path to avoid missing user traffic + performance monitoring. - If operators have to disable the pro-active monitoring during the on- - demand hitless path 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. + Accordingly, - Accordingly, the on-demand single lavel path segment monitoring is - required without changing or interfering the proactive monitoring of - the original end-to-end transport path. + (M4) EPSM shall be established without changing or interfering + with the already in place end-to-end pro-active monitoring of + transport path --- --- --- --- --- | | | | | | | | | | | A | | B | | C | | D | | E | --- --- --- --- --- MEP MEP <= ME of a transport path +-----------------------------+ <= Proactive E2E monitoring *------------------* <= On-demand segment monitoring Figure 3: Independency between proactive end-to-end monitoring and on-demand segment monitoring -6.3. Necessity of arbitrary segment monitoring +6.4. Arbitrary segment monitoring 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 - 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). + fault points. One 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 4. --- --- --- --- --- | | | | | | | | | | | 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 + *-----* <= 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 + Figure 4: A procedure to localize a defect by consecutive on-demand + segments monitoring - Accordingly, on-demand monitoring of arbitrary segments is mandatory - in the case in Fig. 5. As a result, on-demand HSPM 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. + Another possible scenario is depicted in Figure 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 supporting + only a subset of OAM functions. In that case, if the source entities + of the diagnostic packets are limited to the position of MEPs, on- + demand segment monitoring will be ineffective because not all the + segments can be diagnosed (e.g. segment monitoring 3 in Figure 5 is + not available and it is not possible to precisely localize the fault + point). + + Accordingly, + + (M5) EPSM shall be set in an arbitrary segment of a transport path + and diagnostic packets should be inserted/terminated at 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 + Figure 5: HSPM is configured at arbitrary segments -6.4. Fault during HPSM in case of protection +6.5. Fault while EPSM is in place - Node or link failures may occur during the HPSM is activated. In - that case, the hitless path segment monitoring function should be - suspended immediately and must not continue the monitoring on a new - protected or restored path when a protection or restoration for the - fault path is available. Therefore a solution of HPSM should avoid - such a situation that a target node of the hitless segment monitoring - is changed to unintended node when failures occur on the segment. + Node or link failures may occur while EPSM is active. In that case, + if no resiliency mechanism is set-up on the subtended transport path, + there is no particular requirement for EPSM while if the trasport + path is protected, EPSM function should be terminated to avoid + monitoring a new segment when a protection or restoration path is in + place. Therefore - Fig.6 and Fig.7 exemplify one of the examples that should be avoided. - However, this example is just for clarification of the problem that - should be avoided. It does not intend to restrict any solution for - meeting the requirements of HPSM. Protection scenario A is shown in - figure 6. In this scenario, a 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. + (M5) EPSM function should avoid monitoring an unintended segment + when failures occur - A - B -- C -- D - E - F + The folowing examples are reported for clarification only and shall + not be intended to restrict any solution for meeting the requirements + of EPSM. A Protection scenario A is shown in figure 6. In this + scenario, a working LSP and a protection LSP are set. EPSM is set + between A and E. Considering a fault happens between nodes B and C, + the EPSM is not affected by protection and continues in the working + LSP path. As a result, requirement (M5) is satisfied. + + A - B - C - D - E - F \ / - G - H + G - H - I - L Where: - + - e2e LSP: A-B-C-D-E-F - working LSP: A-B-C-D-E-F - - protection LSP: A-B-G-H-D-E-F - - HPSM: A-E + - protection LSP: A-B-G-H-I-L-F + - EPSM: A-E --------------- - Figure 6: Protection scenario A having no issue when a fault happens - on HPSMs + Figure 6: Protection scenario A - 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. + Differently, figure 7 shows a scenario where only a portion of a + transport path is protected. In this case, when a fault happen + between node B and C along the working sub-path, traffic is switched + to protection sub-path B-G-H-D. In the hypotesis that OAM packets + termination depend only on TTL value of MPLS label header, the target + node of EPSM changes from E to D due to the difference of hop counts + between the working path route (ABCDE: 4 hops) and protection path + route (ABGHDE: 5 hops). As a result, requirement (M5) is not + satisfied. - A - B -- C -- D - E - F + A - B - C - D - E - F \ / G - H - - e2e LSP: A-B...D-E-F + - e2e LSP: A-B-C-D-E-F - working sub-path: B-C-D - protection sub-path: B-G-H-D - - HPSM: A-E + - EPSM: A-E --------------- - Figure 7: Protection scenario B having an issue when a fault happens - on HPSM + Figure 7: Protection scenario B -6.5. Consideration of maintenance point for HPSM +6.6. EPSM maintenance points - An intermediate maintenance point supporting the HPSM has to be able + An intermediate maintenance point supporting the EPSM has to be able to generate and inject OAM packets. Although maintenance points for - the HPSM do not necessarily have to coincide with MIPs or MEPs in - terms of the architecture definition, the same identifier for MIPs or - MEPs could be applied to maintenance points of the HPSM. + the EPSM do not necessarily have to coincide with MIPs or MEPs in + terms of the architecture definition, + + (M7) The same identifiers for MIPs and/or MEPs should be applied + to EPSM maintenance points 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 RFC 6371 [RFC6371]. + described in section 3.8 of RFC 6371 [RFC6371] and reported in + Section 3 of this document. 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. + i.e., P-1, P-2, P-3 and P-4. The solution for the temporal and hitless segment monitoring has to cover both per-node model and per-interface model which are specified - in RFC 6371 [RFC6371]. In addition, the following requirements - should be considered for an enhanced temporal and hitless path - segment monitoring function: - - o "On-demand and in-service" single level segment should be done - without changing or interfering any condition of pro-active - monitoring of an original ME of a transport path. - - o On-demand and in-service segment monitoring should be able to be - set in an arbitrary segment of a transport path. + in RFC 6371 [RFC6371]. - The temporal and hitless segment monitoring solutions is applicable - to and needs to support several on-demand OAM functions, as follows: - Mandatory: Packet Loss Measurement and Packet Delay Measurement - Optional: Connectivity Verification, Diagnostic Tests (Throughput - test), and Route Tracing. + The temporal and hitless segment monitoring solutions shall support + on-demand Packet Loss Measurement and Packet Delay Measurement + functions and optionally other performance monitoring /fault + management functions (e.g. Throughput measurement, Delay variation + measurement, Diagnostic test measurement, etc.). 8. Security Considerations The security considerations defined for RFC 6378 apply to this document as well. As this is simply a re-use of RFC 6378, there are no new security considerations. 9. IANA Considerations There are no requests for IANA actions in this document. @@ -670,61 +603,70 @@ Transport Profile. The authors would also like to thank Alexander Vainshtein, Dave Allan, Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm Betts, Nurit Sprecher and Jia He for their comments and enhancements to the text. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol - Label Switching Architecture", RFC 3031, January 2001. + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + . - [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for - Operations, Administration, and Maintenance (OAM) in MPLS - Transport Networks", RFC 5860, May 2010. + [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., + "Requirements for Operations, Administration, and + Maintenance (OAM) in MPLS Transport Networks", RFC 5860, + DOI 10.17487/RFC5860, May 2010, + . - [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. - Berger, "A Framework for MPLS in Transport Networks", RFC - 5921, July 2010. + [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, + L., and L. Berger, "A Framework for MPLS in Transport + Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, + . - [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and - Maintenance Framework for MPLS-Based Transport Networks", - RFC 6371, September 2011. + [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, + Administration, and Maintenance Framework for MPLS-Based + Transport Networks", RFC 6371, DOI 10.17487/RFC6371, + September 2011, . - [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- - TP) Survivability Framework", RFC 6372, September 2011. + [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport + Profile (MPLS-TP) Survivability Framework", RFC 6372, + DOI 10.17487/RFC6372, September 2011, + . Authors' Addresses Alessandro D'Alessandro Telecom Italia Email: alessandro.dalessandro@telecomitalia.it Loa Andersson Huawei Technologies Email: loa@mail01.huawei.com Manuel Paul Deutsche Telekom Email: Manuel.Paul@telekom.de Satoshi Ueno - NTT + NTT Communications Email: satoshi.ueno@ntt.com Kaoru Arai NTT Email: arai.kaoru@lab.ntt.co.jp - Yoshinori Koike NTT Email: koike.yoshinori@lab.ntt.co.jp