idnits 2.17.1 draft-ietf-mpls-tp-temporal-hitless-psm-03.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 16 instances of too long lines in the document, the longest one being 41 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 475 has weird spacing: '... demand hitle...' -- The document date (May 8, 2013) is 4005 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: Nov7, 2013 May 8, 2013 12 Temporal and hitless path segment monitoring 13 draft-ietf-mpls-tp-temporal-hitless-psm-03.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 November 7, 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 ..................................... 16 98 9. IANA Considerations ........................................ 16 99 10. References ................................................ 16 100 10.1. Normative References .................................. 16 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. When SPME/TCM is applied for on- 231 demand OAM functions in MPLS-TP networks in a similar manner to OTN 232 or Ethernet transport networks, a possible rule of differentiating 233 those SPME/TCMs operationally will be necessary at least within an 234 administrative domain. This enforces operators to create an 235 additional permanent layer identification policy only for temporal 236 path segment monitoring. Moreover, from the perspective of operation, 237 increasing the managed addresses and the managed layer is not 238 desirable in terms of simplified operation featured by current 239 transport networks. Reducing the managed identifiers and managed 240 layers should be the fundamental direction in designing the 241 architecture. 243 The most familiar example for SPME in transport networks is Tandem 244 Connection Monitoring (TCM), which can for example be used for a 245 carrier's carrier solution, as shown in Fig. 17 of the framework 246 document[2]. However, in this case, the SPMEs have to be pre- 247 configured. If this solution is applied to specific segment 248 monitoring within one operator domain, all the necessary specific 249 segments have to be pre-configured. This setting increases the 250 managed objects as well as the necessary bandwidth, shown as Problem 251 (P-1) and (P-2). Moreover, as a result of these pre-configurations, 252 they impose operators to pre-design the structure of sub-path 253 maintenance elements, which is not preferable in terms of operators' 254 increased burden. These concerns are summarized in section 3.8 of [5]. 256 Furthermore, in reality, all the possible patterns of path segment 257 cannot be set in SPME, because overlapping of path segments is 258 limited to nesting relationship. As a result, possible SPME patterns 259 of portions of an original transport path are limited due to the 260 characteristic of SPME shown in Figure.1, even if SPMEs are pre- 261 configured. This restriction is inconvenient when operators have to 262 fix issues in an on-demand manner. To avoid these issues, the 263 temporal and on-demand setting of the SPME(s) is needed and more 264 efficient for monitoring in MPLS-TP transport network operation. 266 However, using currently defined methods, the temporal setting of 267 SPMEs also causes the following problems due to label stacking, which 268 are fatal in terms of intrinsic monitoring and service disruption. 270 (P'-1) Changing the condition of the original transport path by 271 changing the length of all the MPLS frames and changing label 272 value(s) 274 (P'-2) Disrupting client traffic over a transport path, if the SPME 275 is temporally configured. 277 Problem (P'-1) is a fatal problem in terms of intrinsic monitoring. 278 As shown in network objective (2), the monitoring function needs to 279 monitor the status without changing any conditions of the targeted 280 monitored segment or the transport path. If the conditions of the 281 transport path change, the measured value or observed data will also 282 change. This can make the monitoring meaningless because the result 283 of the monitoring would no longer reflect the reality of the 284 connection where the original fault or degradation occurred. 286 Another aspect is that changing the settings of the original shim 287 header should not be allowed because those changes correspond to 288 creating a new portion of the original transport path, which differs 289 from the original data plane conditions. 291 Figure 1 shows an example of SPME setting. In the figure, X means the 292 one label expected on the tail-end node D of the original transport 293 path. "210" and "220" are label allocated for SPME. The label values 294 of the original path are modified as well as the values of stacked 295 label. As shown in Fig.1, SPME changes the length of all the MPLS 296 frames and changes label value(s). This is no longer the monitoring 297 of the original transport path but the monitoring of a different path. 298 Particularly, performance monitoring measurement (Delay measurement 299 and loss measurement) are sensitive to those changes. 301 (Before SPME settings) 302 --- --- --- --- --- 303 | | | | | | | | | | 304 | | | | | | | | | | 305 --- --- --- --- --- 306 A---100--B--110--C--120--D--130--E <= transport path 307 MEP MEP 309 (After SPME settings) 310 --- --- --- --- --- 311 | | | | | | | | | | 312 | | | | | | | | | | 313 --- --- --- --- --- 314 A---100--B-------X-------D--130--E 315 MEP \ / MEP <= transport path 316 --210--C--220-- <= SPME 317 MEP' MEP' 319 Figure 1 : An Example of a SPME setting 321 Problem (P'-2) was not fully discussed, although the make-before- 322 break procedure in the survivability document [4] seemingly supports 323 the hitless configuration for monitoring according to the framework 324 document [2]. The reality is the hitless configuration of SPME is 325 impossible without affecting the conditions of the targeted transport 326 path, because the make-before-break procedure is premised on the 327 change of the inner label value. This means changing one of the 328 settings in MPLS shim header. 330 Moreover, this might not be effective under the static model without 331 a control plane because the make-before-break is a restoration 332 application based on the control plane. The removal of SPME whose 333 segment is monitored could have the same impact (disruption of client 334 traffic) as the creation of an SPME on the same LSP. 336 Note: (P'-2) will be removed when non-disruptive make-before-break 337 (in both with and without Control Plane environment) is specified in 338 other MPLS-TP documents. However, (P'-2) could be replaced with the 339 following issue. Non-disruptive make-before-break, in other words, 340 taking an action similar to switching just for monitoring is not an 341 ideal operation in transport networks. 343 The other potential risks are also envisaged. Setting up a temporal 344 SPME will result in the LSRs within the monitoring segment only 345 looking at the added (stacked) labels and not at the labels of the 346 original LSP. This means that problems stemming from incorrect (or 347 unexpected) treatment of labels of the original LSP by the nodes 348 within the monitored segment could not be found when setting up SPME. 349 This might include hardware problems during label look-up, mis- 350 configuration etc. Therefore operators have to pay extra attention to 351 correctly setting and checking the label values of the original LSP 352 in the configuration. Of course, the inversion of this situation is 353 also possible, .e.g., incorrect or unexpected treatment of SPME 354 labels can result in false detection of a fault where none of the 355 problem originally existed. 357 The utility of SPMEs is basically limited to inter-carrier or inter- 358 domain segment monitoring where they are typically pre-configured or 359 pre-instantiated. SPME instantiates a hierarchical transport path 360 (introducing MPLS label stacking) through which OAM packets can be 361 sent. SPME construct monitoring function is particularly important 362 mainly for protecting bundles of transport paths and carriers' 363 carrier solutions. SPME is expected to be mainly used for protection 364 purpose within one administrative domain. 366 To summarize, the problem statement is that the current sub-path 367 maintenance based on a hierarchical LSP (SPME) is problematic for 368 pre-configuration in terms of increasing bandwidth by label stacking 369 and managing objects by layer stacking and address management. A on- 370 demand/temporal configuration of SPME is one of the possible 371 approaches for minimizing the impact of these issues. However, the 372 current method is unfavorable because the temporal configuration for 373 monitoring can change the condition of the original monitored 374 transport path( and disrupt the in-service customer traffic). From 375 the perspective of monitoring in transport network operation, a 376 solution avoiding those issues or minimizing their impact is required. 377 Another monitoring mechanism is therefore required that supports 378 temporal and hitless path segment monitoring. Hereafter it is called 379 on-demand hitless path segment monitoring (HPSM). 381 Note: The above sentence "and disrupt the in-service customer 382 traffic" might need to be modified depending on the result of future 383 discussion about (P'-2). 385 5. OAM functions using segment monitoring 387 OAM functions in which on-demand HPSM is required are basically 388 limited to on-demand monitoring which are defined in OAM framework 389 document [5], because those segment monitoring functions are used to 390 locate the fault/degraded point or to diagnose the status for 391 detailed analyses, especially when a problem occurred. In other words, 392 the characteristic of "on-demand" is generally temporal for 393 maintenance operation. Conversely, this could be a good reason that 394 operations should not be based on pre-configuration and pre-design. 396 Packet loss and packet delay measurements are OAM functions in which 397 hitless and temporal segment monitoring are strongly required because 398 these functions are supported only between end points of a transport 399 path. If a fault or defect occurs, there is no way to locate the 400 defect or degradation point without using the segment monitoring 401 function. If an operator cannot locate or narrow the cause of the 402 fault, it is quite difficult to take prompt action to solve the 403 problem. Therefore, on-demand HPSM for packet loss and packet delay 404 measurements are indispensable for transport network operation. 406 Regarding other on-demand monitoring functions path segment 407 monitoring is desirable, but not as urgent as for packet loss and 408 packet delay measurements. 410 Regarding out-of-service on-demand monitoring functions, such as 411 diagnostic tests, there seems no need for HPSM. However, specific 412 segment monitoring should be applied to the OAM function of 413 diagnostic test, because SPME doesn't meet network objective (2) in 414 section 3. See section 6.3. 416 Note: 418 The solution for temporal and hitless segment monitoring should not 419 be limited to label stacking mechanisms based on pre-configuration, 420 such as PST/TCM(label stacking), which can cause the issues (P-1) 421 and (P-2) described in Section 4. 423 The solution for HPSM has to cover both per-node model and per- 424 interface model which are specified in [5]. 426 6. Further consideration of requirements for enhanced segment monitoring 427 6.1. Necessity of on-demand single-level monitoring 429 The new segment monitoring function is supposed to be applied mainly 430 for diagnostic purpose on-demand. We can differentiate this 431 monitoring from the proactive segment monitoring as on-demand multi- 432 level monitoring. The most serious problem at the moment is that 433 there is no way to localize the degradation point on a path without 434 changing the conditions of the original path. Therefore, as a first 435 step, single layer segment monitoring not affecting the monitored 436 path is required for a new on-demand and hitless segment monitoring 437 function. 439 A combination of multi-level and simultaneous monitoring is the most 440 powerful tool for accurately diagnosing the performance of a 441 transport path. However, considering the substantial benefits to 442 operators, a strict monitoring function which is required in such as 443 a test environment of a laboratory does not seem to be necessary in 444 the field. To summarize, on-demand and in-service (hitless) single- 445 level segment monitoring is required, on-demand and in-service multi- 446 level segment monitoring is desirable. Figure 2 shows an example of a 447 multi-level on-demand segment monitoring. 449 --- --- --- --- --- 450 | | | | | | | | | | 451 | A | | B | | C | | D | | E | 452 --- --- --- --- --- 453 MEP MEP <= ME of a transport path 454 +-----------------------------+ <= End-to-end monitoring 455 *------------------* <= segment monitoring level1 456 *-------------* <= segment monitoring level2 457 *-* <= segment monitoring level3 459 Figure 2 : An Example of a multi-level on-demand segment monitoring 461 6.2. Necessity of on-demand monitoring independent from end-to-end 462 proactive monitoring 464 As multi-level simultaneous monitoring only for on-demand new path 465 segment monitoring was already discussed in section6.1, next we 466 consider the necessity of simultaneous monitoring of end-to-end 467 current proactive monitoring and new on-demand path segment 468 monitoring. Normally, the on-demand path segment monitoring is 469 configured in a segment of a maintenance entity of a transport path. 470 In this environment, on-demand single-level monitoring should be done 471 without disrupting pro-active monitoring of the targeted end-to-end 472 transport path. 474 If operators have to disable the pro-active monitoring during the on- 475 demand hitless path segment monitoring, the network operation system 476 might miss any performance degradation of user traffic. This kind of 477 inconvenience should be avoided in the network operations. 479 Accordingly, the on-demand single lavel path segment monitoring is 480 required without changing or interfering the proactive monitoring of 481 the original end-to-end transport path. 483 --- --- --- --- --- 484 | | | | | | | | | | 485 | A | | B | | C | | D | | E | 486 --- --- --- --- --- 487 MEP MEP <= ME of a transport path 488 +-----------------------------+ <= Proactive E2E monitoring 489 *------------------* <= On-demand segment monitoring 491 Figure 3 : Independency between proactive end-to-end monitoring and 492 on-demand segment monitoring 494 6.3. Necessity of arbitrary segment monitoring 496 The main objective of on-demand segment monitoring is to diagnose the 497 fault points. One possible diagnostic procedure is to fix one end 498 point of a segment at the MEP of a transport path and change 499 progressively the length of the segment in order. This example is 500 shown in Fig. 4. This approach is considered as a common and 501 realistic diagnostic procedure. In this case, one end point of a 502 segment can be anchored at MEP at any time. 504 Other scenarios are also considered, one shown in Fig. 5. In this 505 case, the operators want to diagnose a transport path from a transit 506 node that is located at the middle, because the end nodes(A and E) 507 are located at customer sites and consist of cost effective small box 508 in which a subset of OAM functions are supported. In this case, if 509 one end point and an originator of the diagnostic packet are limited 510 to the position of MEP, on-demand segment monitoring will be 511 ineffective because all the segments cannot be diagnosed (For example, 512 segment monitoring 3 in Fig.5 is not available and it is not possible 513 to localize the fault point). 515 --- --- --- --- --- 516 | | | | | | | | | | 517 | A | | B | | C | | D | | E | 518 --- --- --- --- --- 519 MEP MEP <= ME of a transport path 520 +-----------------------------+ <= Proactive E2E monitoring 521 *-----* <= 1st On-demand segment monitoring 522 *-------* <= 2nd On-demand segment monitoring 523 *------------* <= 3rd On-demand segment monitoring 524 | 525 | 526 *-----------------------* <= 6th On-demand segment monitoring 527 *-----------------------------*<= 7th On-demand segment monitoring 529 Figure 4 : One possible procedure to localize a fault point by 530 sequential on-demand segment monitoring 532 Accordingly, on-demand monitoring of arbitrary segments is mandatory 533 in the case in Fig. 5. As a result, on-demand HSPM should be set in 534 an arbitrary segment of a transport path and diagnostic packets 535 should be inserted from at least any of intermediate maintenance 536 points of the original ME. 538 --- --- --- 539 --- | | | | | | --- 540 | A | | B | | C | | D | | E | 541 --- --- --- --- --- 542 MEP MEP <= ME of a transport path 543 +-----------------------------+ <= Proactive E2E monitoring 544 *-----* <= On-demand segment monitoring 1 545 *-----------------------*<= On-demand segment monitoring 2 546 *---------* <= On-demand segment monitoring 3 548 Figure 5 : Example where on-demand monitoring has to be configured in 549 arbitrary segments 551 6.4. Fault during HPSM in case of protection 553 Node or link failures may occur during the HPSM is activated. In that 554 case, the hitless path segment monitoring function should be 555 suspended immediately and must not continue the monitoring on a new 556 protected or restored path when a protection or restoration for the 557 fault path is available. Therefore a solution of HPSM should avoid 558 such a situation that a target node of the hitless segment monitoring 559 is changed to unintended node when failures occur on the segment. 561 Fig.6 and Fig.7 exemplify one of the examples that should be avoided. 562 However, this example is just for clarification of the problem that 563 should be avoided. It does not intend to restrict any solution for 564 meeting the requirements of HPSM. Protection scenario A is shown in 565 figure 6. In this scenario, a working LSP and a protection LSP are 566 separately set, in other words as independent LSPs. HPSM is set 567 between A and E. Therefore, considering the case that a fault happens 568 between B and C, the HPSM doesn't continue in a protected path. As a 569 result, there is no issue. 571 A - B -- C -- D - E - F 572 \ / 573 G - H 575 Where: 577 - working LSP: A-B-C-D-E-F 578 - protection LSP: A-B-G-H-D-E-F 579 - HPSM: A-E 580 --------------- 582 Figure 6 : Protection scenario A having no issue when a fault 583 happens on HPSM 585 On the other hand, figure 7 shows a scenario where only a portion of 586 a transport path has different label assignments (sub-paths). In this 587 case, when a fault condition is identified on working sub-path B-C-D, 588 the sub-path is switched to protection sub-path B-G-H-D. As a result, 589 the target node of HPSM changes from E to D due to the difference of 590 hop counts between a route of working path(ABCDE: 4 hops) and that of 591 protection path(ABGHDE: 5 hops), because the forwarding and 592 processing of HPSM OAM packets depend only on TTL value of MPLS label 593 header. In this case, some additional mechanisms to notify the fault 594 on working path to the source of HPSM may be necessary to suspend the 595 monitoring. 597 A - B -- C -- D - E - F 598 \ / 599 G - H 601 - e2e LSP: A-B...D-E-F 602 - working sub-path: B-C-D 603 - protection sub-path: B-G-H-D 604 - HPSM: A-E 605 --------------- 607 Figure 7 : Protection scenario B having an issue when a fault happens 608 on HPSM 610 6.5. Consideration of maintenance point for HPSM 612 An intermediate maintenance point supporting the HPSM has to be able 613 to generate and inject OAM packets. Although maintenance points for 614 the HPSM do not necessarily have to coincide with MIPs or MEPs in 615 terms of the architecture definition, the same identifier for MIPs or 616 MEPs could be applied to maintenance points of the HPSM. 618 7. Summary 620 An enhanced monitoring mechanism is required to support temporal and 621 hitless segment monitoring which meets the two network objectives 622 mentioned in Section 3 of this document that are described also in 623 section 3.8 of [5]. 624 The enhancements should minimize the issues described in Section 4, 625 i.e., P-1, P-2, P'-1( and P'-2), to meet those two network objectives. 627 The solution for the temporal and hitless segment monitoring has to 628 cover both per-node model and per-interface model which are specified 629 in [5]. In addition, the following requirements should be considered 630 for an enhanced temporal and hitless path segment monitoring 631 function: 633 - "On-demand and in-service" single level segment should be done 634 without changing or interfering any condition of pro-active 635 monitoring of an original ME of a transport path. 637 - On-demand and in-service segment monitoring should be able to be 638 set in an arbitrary segment of a transport path. 640 The temporal and hitless segment monitoring solutions is applicable 641 to and needs to support several on-demand OAM functions, as follows: 642 Mandatory: Packet Loss Measurement and Packet Delay Measurement 643 Optional: Connectivity Verification, Diagnostic Tests (Throughput 644 test), and Route Tracing. 646 8. Security Considerations 648 This document does not by itself raise any particular security 649 considerations. 651 9. IANA Considerations 653 There are no IANA actions required by this draft. 655 10. References 657 10.1. Normative References 659 [1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 660 MPLS Transport Networks", RFC5860, May 2010 662 [2] Bocci, M., et al., "A Framework for MPLS in Transport Networks", 663 RFC5921, July 2010 665 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 666 January 2001 668 [4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching 669 Transport Profile Survivability Framework", RFC6372, September 670 2011 672 [5] Busi, I., Dave, A. , "Operations, Administration and 673 Maintenance Framework for MPLS-based Transport Networks ", 674 RFC6371, February 2011 676 10.2. Informative References 678 None 680 11. Acknowledgments 682 The author would like to thank all members (including MPLS-TP 683 steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group 684 in ITU-T) involved in the definition and specification of MPLS 685 Transport Profile. 687 The authors would also like to thank Alexander Vainshtein, Dave Allan, 688 Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm 689 Betts, Nurit Sprecher and Jia He for their comments and enhancements 690 to the text. 692 This document was prepared using 2-Word-v2.0.template.dot. 694 Authors' Addresses 696 Alessandro D'Alessandro 697 Telecom Italia 698 Email: alessandro.dalessandro@telecomitalia.it 700 Manuel Paul 701 Deutsche Telekom 702 Email: Manuel.Paul@telekom.de 704 Satoshi Ueno 705 NTT Communications 706 Email: satoshi.ueno@ntt.com 708 Yoshinori Koike 709 NTT 710 Email: koike.yoshinori@lab.ntt.co.jp