idnits 2.17.1 draft-ietf-mpls-tp-temporal-hitless-psm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 474 has weird spacing: '... demand hitle...' -- The document date (July 16, 2012) is 4273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group A. D'Alessandro 2 Internet Draft Telecom Italia 3 M.Paul 4 Deutsche Telekom 5 Intended status: Informational S. Ueno 6 NTT Communications 7 Y.Koike 8 NTT 10 Expires: January 15, 2013 July 16, 2012 12 Temporal and hitless path segment monitoring 13 draft-ietf-mpls-tp-temporal-hitless-psm-01.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 15, 2013. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents carefully, 46 as they describe your rights and restrictions with respect to this 47 document. Code Components extracted from this document must include 48 Simplified BSD License text as described in Section 4.e of the Trust 49 Legal Provisions and are provided without warranty as described in 50 the Simplified BSD License. 52 Abstract 54 The MPLS transport profile (MPLS-TP) is being standardized to enable 55 carrier-grade packet transport and complement converged packet 56 network deployments. Among the most attractive features of MPLS-TP 57 are OAM functions, which enable network operators or service 58 providers to provide various maintenance characteristics, such as 59 fault location, survivability, performance monitoring, and 60 preliminary or in-service measurements. 62 One of the most important mechanisms which is common for transport 63 network operation is fault location. A segment monitoring function of 64 a transport path is effective in terms of extension of the 65 maintenance work and indispensable particularly when the OAM function 66 is effective only between end points. However, the current approach 67 defined for MPLS-TP for the segment monitoring (SPME) has some fatal 68 drawbacks. This document elaborates on the problem statement for the 69 Sub-path Maintenance Elements (SPMEs) which provides monitoring of a 70 portion of a set of transport paths (LSPs or MS-PWs). Based on the 71 problems, this document specifies new requirements to consider a new 72 improved mechanism of hitless transport path segment monitoring. 74 This document is a product of a joint Internet Engineering Task Force 75 (IETF) / International Telecommunications Union Telecommunications 76 Standardization Sector (ITU-T) effort to include an MPLS Transport 77 Profile within the IETF MPLS and PWE3 architectures to support the 78 capabilities and functionalities of a packet transport network. 80 Table of Contents 82 1. Introduction ................................................ 4 83 2. Conventions used in this document ............................ 4 84 2.1. Terminology ............................................ 5 85 2.2. Definitions ............................................ 5 86 3. Network objectives for monitoring ............................ 5 87 4. Problem statement ........................................... 6 88 5. OAM functions using segment monitoring ...................... 10 89 6. Further consideration of requirements for enhanced segment 90 monitoring .................................................... 10 91 6.1. Necessity of on-demand single-level monitoring.......... 11 92 6.2. Necessity of on-demand monitoring independent from end-to-end 93 proactive monitoring........................................ 11 94 6.3. Necessity of arbitrary segment monitoring .............. 12 95 6.4. Fault during HPSM in case of protection ................ 13 96 7. Summary .................................................... 15 97 8. Security Considerations ..................................... 15 98 9. IANA Considerations ........................................ 15 99 10. References ................................................ 15 100 10.1. Normative References .................................. 15 101 10.2. Informative References ................................ 16 102 11. Acknowledgments ........................................... 16 104 1. Introduction 106 A packet transport network will enable carriers or service providers 107 to use network resources efficiently, reduce operational complexity 108 and provide carrier-grade network operation. Appropriate maintenance 109 functions, supporting fault location, survivability, performance 110 monitoring and preliminary or in-service measurements, are essential 111 to ensure quality and reliability of a network. They are essential in 112 transport networks and have evolved along with TDM, ATM, SDH and OTN. 114 Unlike in SDH or OTN networks, where OAM is an inherent part of every 115 frame and frames are also transmitted in idle mode, it is not per se 116 possible to constantly monitor the status of individual connections 117 in packet networks. Packet-based OAM functions are flexible and 118 selectively configurable according to operators' needs. 120 According to the MPLS-TP OAM requirements [1], mechanisms MUST be 121 available for alerting a service provider of a fault or defect 122 affecting the service(s) provided. In addition, to ensure that faults 123 or degradations can be localized, operators need a method to analyze 124 or investigate the problem. From the fault localization perspective, 125 end-to-end monitoring is insufficient. Using end-to-end OAM 126 monitoring, when one problem occurs in an MPLS-TP network, the 127 operator can detect the fault, but is not able to localize it. 129 Thus, a specific segment monitoring function for detailed analysis, 130 by focusing on and selecting a specific portion of a transport path, 131 is indispensable to promptly and accurately localize the fault. 133 For MPLS-TP, a path segment monitoring function has been defined to 134 perform this task. However, as noted in the MPLS-TP OAM Framework[5], 135 the current method for segment monitoring function of a transport 136 path has implications that hinder the usage in an operator network. 138 This document elaborates on the problem statement for the path 139 segment monitoring function and proposes to consider a new improved 140 method of the segment monitoring, following up the work done in [5]. 141 Moreover, this document explains detailed requirements on the new 142 temporal and hitless segment monitoring function which are not 143 covered in [5]. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC-2119 [1]. 151 2.1. Terminology 153 HPSM Hitless Path Segment Monitoring 155 LSP Label Switched Path 157 LSR Label Switching Router 159 ME Maintenance Entity 161 MEG Maintenance Entity Group 163 MEP Maintenance Entity Group End Point 165 MIP Maintenance Entity Group Intermediate Point 167 OTN Optical Transport Network 169 PST Path Segment Tunnel 171 TCM Tandem connection monitoring 173 SDH Synchronous Digital Hierarchy 175 SPME Sub-path Maintenance Element 177 2.2. Definitions 179 None 181 3. Network objectives for monitoring 183 There are two indispensable network objectives for MPLS-TP networks 184 as described in section 3.8 of [5]. 186 (1) The monitoring and maintenance of current transport paths has to 187 be conducted in-service without traffic disruption. 189 (2) Segment monitoring must not modify the forwarding of the segment 190 portion of the transport path. 192 It is common in transport networks that network objective (1) is 193 mandatory and that regarding network objective (2) the monitoring 194 shall not change the forwarding behavior. 196 4. Problem statement 198 To monitor, protect, or manage portions of transport paths, such as 199 LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is 200 defined in [2]. The SPME is defined between the edges of the portion 201 of the transport path that needs to be monitored, protected, or 202 managed. This SPME is created by stacking the shim header (MPLS 203 header)[3] and is defined as the segment where the header is stacked. 204 OAM messages can be initiated at the edge of the SPME and sent to the 205 peer edge of the SPME or to a MIP along the SPME by setting the TTL 206 value of the label stack entry (LSE) and interface identifier value 207 at the corresponding hierarchical LSP level in case of per-node model. 209 This method has the following general issues, which are fatal in 210 terms of cost and operation. 212 (P-1) Increasing the overhead by the stacking of shim header(s) 214 (P-2) Increasing the address management complexity, as new MEPs and 215 MIPs need to be configured for the SPME in the old MEG 217 Problem (P-1) leads to decreased efficiency as bandwidth is wasted 218 only for maintenance purposes. As the size of monitored segments 219 increases, the size of the label stack grows. Moreover, if the 220 operator wants to monitor the portion of a transport path without 221 service disruption, one or more SPMEs have to be set in advance until 222 the end of life of a transport path, which is not temporal or on- 223 demand. Consuming additional bandwidth permanently for only the 224 monitoring purpose should be avoided to maximize the available 225 bandwidth. 227 Problem (P-2) is related to an identifier-management issue. The 228 identification of each layer in case of LSP label stacking is 229 required in terms of strict sub-layer management for the segment 230 monitoring in a MPLS-TP network. There is no standardized way to 231 identify a layer, however a possible rule of differentiating layers 232 will be necessary at least within an administrative domain, if SPME 233 is applied for on-demand OAM functions. This enforces operators to 234 create an additional permanent layer identification policy only for 235 temporal path segment monitoring. Moreover, from the perspective of 236 operation, increasing the managed addresses and the managed layer is 237 not desirable in terms of simplified operation featured by current 238 transport networks. Reducing the managed identifiers and managed 239 layers should be the fundamental direction in designing the 240 architecture. 242 The most familiar example for SPME in transport networks is Tandem 243 Connection Monitoring (TCM), which can for example be used for a 244 carrier's carrier solution, as shown in Fig. 17 of the framework 245 document[2]. However, in this case, the SPMEs have to be pre- 246 configured. If this solution is applied to specific segment 247 monitoring within one operator domain, all the necessary specific 248 segments have to be pre-configured. This setting increases the 249 managed objects as well as the necessary bandwidth, shown as Problem 250 (P-1) and (P-2). Moreover, as a result of these pre-configurations, 251 they impose operators to pre-design the structure of sub-path 252 maintenance elements, which is not preferable in terms of operators' 253 increased burden. These concerns are summarized in section 3.8 of [5]. 255 Furthermore, in reality, all the possible patterns of path segment 256 cannot be set in SPME, because overlapping of path segments is 257 limited to nesting relationship. As a result, possible SPME patterns 258 of portions of an original transport path are limited due to the 259 characteristic of SPME shown in Figure.1, even if SPMEs are pre- 260 configured. This restriction is inconvenient when operators have to 261 fix issues in an on-demand manner.To avoid these issues, the temporal 262 and on-demand setting of the SPME(s) is needed and more efficient for 263 monitoring in MPLS-TP transport network operation. 265 However, using currently defined methods, the temporal setting of 266 SPMEs also causes the following problems due to label stacking, which 267 are fatal in terms of intrinsic monitoring and service disruption. 269 (P'-1) Changing the condition of the original transport path by 270 changing the length of all the MPLS frames and changing label 271 value(s) 273 (P'-2) Disrupting client traffic over a transport path, if the SPME 274 is temporally configured. 276 Problem (P'-1) is a fatal problem in terms of intrinsic monitoring. 277 As shown in network objective (2), the monitoring function needs to 278 monitor the status without changing any conditions of the targeted 279 monitored segment or the transport path. If the conditions of the 280 transport path change, the measured value or observed data will also 281 change. This can make the monitoring meaningless because the result 282 of the monitoring would no longer reflect the reality of the 283 connection where the original fault or degradation occurred. 285 Another aspect is that changing the settings of the original shim 286 header should not be allowed because those changes correspond to 287 creating a new portion of the original transport path, which differs 288 from the original data plane conditions. 290 Figure 1 shows an example of SPME setting. In the figure, X means the 291 one label expected on the tail-end node D of the original transport 292 path. "210" and "220" are label allocated for SPME. The label values 293 of the original path are modified as well as the values of stacked 294 label. As shown in Fig.1, SPME changes the length of all the MPLS 295 frames and changes label value(s). This is no longer the monitoring 296 of the original transport path but the monitoring of a different path. 297 Particularly, performance monitoring measurement (Delay measurement 298 and loss measurement) are sensitive to those changes. 300 (Before SPME settings) 301 --- --- --- --- --- 302 | | | | | | | | | | 303 | | | | | | | | | | 304 --- --- --- --- --- 305 A---100--B--110--C--120--D--130--E <= transport path 306 MEP MEP 308 (After SPME settings) 309 --- --- --- --- --- 310 | | | | | | | | | | 311 | | | | | | | | | | 312 --- --- --- --- --- 313 A---100--B-------X-------D--130--E 314 MEP \ / MEP <= transport path 315 --210--C--220-- <= SPME 316 MEP' MEP' 318 Figure 1 : An Example of a SPME setting 320 Problem (P'-2) was not fully discussed, although the make-before- 321 break procedure in the survivability document [4] seemingly supports 322 the hitless configuration for monitoring according to the framework 323 document [2]. The reality is the hitless configuration of SPME is 324 impossible without affecting the conditions of the targeted transport 325 path, because the make-before-break procedure is premised on the 326 change of the inner label value. This means changing one of the 327 settings in MPLS shim header. 329 Moreover, this might not be effective under the static model without 330 a control plane because the make-before-break is a restoration 331 application based on the control plane. The removal of SPME whose 332 segment is monitored could have the same impact (disruption of client 333 traffic) as the creation of an SPME on the same LSP. 335 Note: (P'-2) will be removed when non-disruptive make-before-break 336 (in both with and without Control Plane environment) is specified in 337 other MPLS-TP documents. However, (P'-2) could be replaced with the 338 following issue. Non-disruptive make-before-break, in other words, 339 taking an action similar to switching just for monitoring is not an 340 ideal operation in transport networks. 342 The other potential risks are also envisaged. Setting up a temporal 343 SPME will result in the LSRs within the monitoring segment only 344 looking at the added (stacked) labels and not at the labels of the 345 original LSP. This means that problems stemming from incorrect (or 346 unexpected) treatment of labels of the original LSP by the nodes 347 within the monitored segment could not be found when setting up SPME. 348 This might include hardware problems during label look-up, mis- 349 configuration etc. Therefore operators have to pay extra attention to 350 correctly setting and checking the label values of the original LSP 351 in the configuration. Of course, the inversion of this situation is 352 also possible, .e.g., incorrect or unexpected treatment of SPME 353 labels can result in false detection of a fault where none of the 354 problem originally existed. 356 The utility of SPMEs is basically limited to inter-carrier or inter- 357 domain segment monitoring where they are typically pre-configured or 358 pre-instantiated. SPME instantiates a hierarchical transport path 359 (introducing MPLS label stacking) through which OAM packets can be 360 sent. SPME construct monitoring function is particularly important 361 mainly for protecting bundles of transport paths and carriers' 362 carrier solutions. SPME is expected to be mainly used for protection 363 purpose within one administrative domain. 365 To summarize, the problem statement is that the current sub-path 366 maintenance based on a hierarchical LSP (SPME) is problematic for 367 pre-configuration in terms of increasing bandwidth by label stacking 368 and managing objects by layer stacking and address management. A on- 369 demand/temporal configuration of SPME is one of the possible 370 approaches for minimizing the impact of these issues. However, the 371 current method is unfavorable because the temporal configuration for 372 monitoring can change the condition of the original monitored 373 transport path( and disrupt the in-service customer traffic). From 374 the perspective of monitoring in transport network operation, a 375 solution avoiding those issues or minimizing their impact is required. 376 Another monitoring mechanism is therefore required that supports 377 temporal and hitless path segment monitoring. Hereafter it is called 378 on-demand hitless path segment monitoring (HPSM). 380 Note: The above sentence "and disrupt the in-service customer 381 traffic" might need to be modified depending on the result of future 382 discussion about (P'-2). 384 5. OAM functions using segment monitoring 386 OAM functions in which on-demand HPSM is required are basically 387 limited to on-demand monitoring which are defined in OAM framework 388 document [5], because those segment monitoring functions are used to 389 locate the fault/degraded point or to diagnose the status for 390 detailed analyses, especially when a problem occurred. In other words, 391 the characteristic of "on-demand" is generally temporal for 392 maintenance operation. Conversely, this could be a good reason that 393 operations should not be based on pre-configuration and pre-design. 395 Packet loss and packet delay measurements are OAM functions in which 396 hitless and temporal segment monitoring are strongly required because 397 these functions are supported only between end points of a transport 398 path. If a fault or defect occurs, there is no way to locate the 399 defect or degradation point without using the segment monitoring 400 function. If an operator cannot locate or narrow the cause of the 401 fault, it is quite difficult to take prompt action to solve the 402 problem. Therefore, on-demand HPSM for packet loss and packet delay 403 measurements are indispensable for transport network operation. 405 Regarding other on-demand monitoring functions path segment 406 monitoring is desirable, but not as urgent as for packet loss and 407 packet delay measurements. 409 Regarding out-of-service on-demand monitoring functions, such as 410 diagnostic tests, there seems no need for HPSM. However, specific 411 segment monitoring should be applied to the OAM function of 412 diagnostic test, because SPME doesn't meet network objective (2) in 413 section 3. See section 6.3. 415 Note: 417 The solution for temporal and hitless segment monitoring should not 418 be limited to label stacking mechanisms based on pre-configuration, 419 such as PST/TCM(label stacking), which can cause the issues (P-1) 420 and (P-2) described in Section 4. 422 The solution for HPSM has to cover both per-node model and per- 423 interface model which are specified in [5]. 425 6. Further consideration of requirements for enhanced segment monitoring 426 6.1. Necessity of on-demand single-level monitoring 428 The new segment monitoring function is supposed to be applied mainly 429 for diagnostic purpose on-demand. We can differentiate this 430 monitoring from the proactive segment monitoring as on-demand multi- 431 level monitoring. The most serious problem at the moment is that 432 there is no way to localize the degradation point on a path without 433 changing the conditions of the original path. Therefore, as a first 434 step, single layer segment monitoring not affecting the monitored 435 path is required for a new on-demand and hitless segment monitoring 436 function. 438 A combination of multi-level and simultaneous monitoring is the most 439 powerful tool for accurately diagnosing the performance of a 440 transport path. However, considering the substantial benefits to 441 operators, a strict monitoring function which is required in such as 442 a test environment of a laboratory does not seem to be necessary in 443 the field. To summarize, on-demand and in-service (hitless) single- 444 level segment monitoring is required, on-demand and in-service multi- 445 level segment monitoring is desirable. Figure 2 shows an example of a 446 multi-level on-demand segment monitoring. 448 --- --- --- --- --- 449 | | | | | | | | | | 450 | A | | B | | C | | D | | E | 451 --- --- --- --- --- 452 MEP MEP <= ME of a transport path 453 +-----------------------------+ <= End-to-end monitoring 454 *------------------* <= segment monitoring level1 455 *-------------* <= segment monitoring level2 456 *-* <= segment monitoring level3 458 Figure 2 : An Example of a multi-level on-demand segment monitoring 460 6.2. Necessity of on-demand monitoring independent from end-to-end 461 proactive monitoring 463 As multi-level simultaneous monitoring only for on-demand new path 464 segment monitoring was already discussed in section6.1, next we 465 consider the necessity of simultaneous monitoring of end-to-end 466 current proactive monitoring and new on-demand path segment 467 monitoring. Normally, the on-demand path segment monitoring is 468 configured in a segment of a maintenance entity of a transport path. 469 In this environment, on-demand single-level monitoring should be done 470 without disrupting pro-active monitoring of the targeted end-to-end 471 transport path. 473 If operators have to disable the pro-active monitoring during the on- 474 demand hitless path segment monitoring, the network operation system 475 might miss any performance degradation of user traffic. This kind of 476 inconvenience should be avoided in the network operations. 478 Accordingly, the on-demand single lavel path segment monitoring is 479 required without changing or interfering the proactive monitoring of 480 the original end-to-end transport path. 482 --- --- --- --- --- 483 | | | | | | | | | | 484 | A | | B | | C | | D | | E | 485 --- --- --- --- --- 486 MEP MEP <= ME of a transport path 487 +-----------------------------+ <= Proactive E2E monitoring 488 *------------------* <= On-demand segment monitoring 490 Figure 3 : Independency between proactive end-to-end monitoring and 491 on-demand segment monitoring 493 6.3. Necessity of arbitrary segment monitoring 495 The main objective of on-demand segment monitoring is to diagnose the 496 fault points. One possible diagnostic procedure is to fix one end 497 point of a segment at the MEP of a transport path and change 498 progressively the length of the segment in order. This example is 499 shown in Fig. 4. This approach is considered as a common and 500 realistic diagnostic procedure. In this case, one end point of a 501 segment can be anchored at MEP at any time. 503 Other scenarios are also considered, one shown in Fig. 5. In this 504 case, the operators want to diagnose a transport path from a transit 505 node that is located at the middle, because the end nodes(A and E) 506 are located at customer sites and consist of cost effective small box 507 in which a subset of OAM functions are supported. In this case, if 508 one end point and an originator of the diagnostic packet are limited 509 to the position of MEP, on-demand segment monitoring will be 510 ineffective because all the segments cannot be diagnosed (For example, 511 segment monitoring 3 in Fig.5 is not available and it is not possible 512 to localize the fault point). 514 --- --- --- --- --- 515 | | | | | | | | | | 516 | A | | B | | C | | D | | E | 517 --- --- --- --- --- 518 MEP MEP <= ME of a transport path 519 +-----------------------------+ <= Proactive E2E monitoring 520 *-----* <= 1st On-demand segment monitoring 521 *-------* <= 2nd On-demand segment monitoring 522 *------------* <= 3rd On-demand segment monitoring 523 | 524 | 525 *-----------------------* <= 6th On-demand segment monitoring 526 *-----------------------------*<= 7th On-demand segment monitoring 528 Figure 4 : One possible procedure to localize a fault point by 529 sequential on-demand segment monitoring 531 Accordingly, on-demand monitoring of arbitrary segments is mandatory 532 in the case in Fig. 5. As a result, on-demand HSPM should be set in 533 an arbitrary segment of a transport path and diagnostic packets 534 should be inserted from at least any of intermediate maintenance 535 points of the original ME. 537 --- --- --- 538 --- | | | | | | --- 539 | A | | B | | C | | D | | E | 540 --- --- --- --- --- 541 MEP MEP <= ME of a transport path 542 +-----------------------------+ <= Proactive E2E monitoring 543 *-----* <= On-demand segment monitoring 1 544 *-----------------------*<= On-demand segment monitoring 2 545 *---------* <= On-demand segment monitoring 3 547 Figure 5 : Example where on-demand monitoring has to be configured in 548 arbitrary segments 550 6.4. Fault during HPSM in case of protection 552 Node or link failures may occur during the HPSM is activated. In that 553 case, the hitless path segment monitoring function should be 554 suspended immediately and must not continue the monitoring on a new 555 protected or restored path when a protection or restoration for the 556 fault path is available. The reason is that target node of the 557 hitless segment monitoring can be changed to unintended node due to 558 the different hop counts from source node of segment monitoring to 559 target node between working path and protection path. 561 Protection scenario A is shown in figure 6. In this scenario, a 562 working LSP and a protection LSP are separately set, in other words 563 as independent LSPs. HPSM is set between A and E. Therefore, 564 considering the case that a fault happens between B and C, the HPSM 565 doesn't continue in a protected path. As a result, there is no issue. 567 A - B -- C -- D - E - F 568 \ / 569 G - H 571 Where: 573 - working LSP: A-B-C-D-E-F 574 - protection LSP: A-B-G-H-D-E-F 575 - HPSM: A-E 576 --------------- 578 Figure 6 : Protection scenario A having no issue when a fault 579 happens on HPSM 581 On the other hand, figure 7 shows a scenario where only a portion of 582 a transport path has different label assignments (sub-paths). In this 583 case, when a fault condition is identified on working sub-path B-C-D, 584 the sub-path is switched to protection sub-path B-G-H-D. As a result, 585 the target node of HPSM changes from E to D due to the difference of 586 hop counts between a route of working path(ABCDE: 4 hops) and that of 587 protection path(ABGHDE: 5 hops), because the forwarding and 588 processing of HPSM OAM packets depend only on TTL value of MPLS label 589 header. In this case, some additional mechanisms to notify the fault 590 on working path to the source of HPSM may be necessary to suspend the 591 monitoring. 593 A - B -- C -- D - E - F 594 \ / 595 G - H 597 - e2e LSP: A-B...D-E-F 598 - working sub-path: B-C-D 599 - protection sub-path: B-G-H-D 600 - HPSM: A-E 601 --------------- 603 Figure 7 : Protection scenario B having an issue when a fault happens 604 on HPSM 606 7. Summary 608 An enhanced monitoring mechanism is required to support temporal and 609 hitless segment monitoring which meets the two network objectives 610 mentioned in Section 3 of this document that are described also in 611 section 3.8 of [5]. 612 The enhancements should minimize the issues described in Section 4, 613 i.e., P-1, P-2, P'-1( and P'-2), to meet those two network objectives. 615 The solution for the temporal and hitless segment monitoring has to 616 cover both per-node model and per-interface model which are specified 617 in [5]. In addition, the following requirements should be considered 618 for an enhanced temporal and hitless path segment monitoring 619 function: 621 - "On-demand and in-service" single level segment should be done 622 without changing or interfering any condition of pro-active 623 monitoring of an original ME of a transport path. 625 - On-demand and in-service segment monitoring should be able to be 626 set in an arbitrary segment of a transport path. 628 The temporal and hitless segment monitoring solutions is applicable 629 to and needs to support several on-demand OAM functions, as follows: 630 Mandatory: Packet Loss Measurement and Packet Delay Measurement 631 Optional: Connectivity Verification, Diagnostic Tests (Throughput 632 test), and Route Tracing. 634 8. Security Considerations 636 This document does not by itself raise any particular security 637 considerations. 639 9. IANA Considerations 641 There are no IANA actions required by this draft. 643 10. References 645 10.1. Normative References 647 [1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 648 MPLS Transport Networks", RFC5860, May 2010 650 [2] Bocci, M., et al., "A Framework for MPLS in Transport Networks", 651 RFC5921, July 2010 653 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 654 January 2001 656 [4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching 657 Transport Profile Survivability Framework", RFC6372, September 658 2011 660 [5] Busi, I., Dave, A. , "Operations, Administration and 661 Maintenance Framework for MPLS-based Transport Networks ", 662 RFC6371, February 2011 664 10.2. Informative References 666 None 668 11. Acknowledgments 670 The author would like to thank all members (including MPLS-TP 671 steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group 672 in ITU-T) involved in the definition and specification of MPLS 673 Transport Profile. 675 The authors would also like to thank Alexander Vainshtein, Dave Allan, 676 Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm 677 Betts and Nurit Sprecher for their comments and enhancements to the 678 text. 680 This document was prepared using 2-Word-v2.0.template.dot. 682 Authors' Addresses 684 Alessandro D'Alessandro 685 Telecom Italia 686 Email: alessandro.dalessandro@telecomitalia.it 688 Manuel Paul 689 Deutsche Telekom 690 Email: Manuel.Paul@telekom.de 692 Satoshi Ueno 693 NTT Communications 694 Email: satoshi.ueno@ntt.com 696 Yoshinori Koike 697 NTT 698 Email: koike.yoshinori@lab.ntt.co.jp