idnits 2.17.00 (12 Aug 2021) /tmp/idnits34129/draft-ietf-mpls-tp-temporal-hitless-psm-14.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2017) is 1716 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. D'Alessandro 3 Internet-Draft Telecom Italia 4 Intended status: Informational L. Andersson 5 Expires: March 5, 2018 Huawei Technologies 6 S. Ueno 7 NTT Communications 8 K. Arai 9 Y. Koike 10 NTT 11 September 1, 2017 13 Requirements for hitless MPLS path segment monitoring 14 draft-ietf-mpls-tp-temporal-hitless-psm-14.txt 16 Abstract 18 One of the most important OAM capabilities for transport network 19 operation is fault localisation. An in-service, on-demand segment 20 monitoring function of a transport path is indispensable, 21 particularly when the service monitoring function is activated only 22 between end points. However, the current segment monitoring approach 23 defined for MPLS (including the transport profile (MPLS-TP)) in RFC 24 6371 "Operations, Administration, and Maintenance Framework for MPLS- 25 Based Transport Networks" has drawbacks. This document provides an 26 analysis of the existing MPLS-TP OAM mechanisms for the path segment 27 monitoring and provides requirements to guide the development of new 28 OAM tools to support a Hitless Path Segment Monitoring (HPSM). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 5, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Requirements for Hitless Path Segment Monitoring . . . . . . 7 69 4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7 70 4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8 71 4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8 72 4.4. Single and multiple level monitoring . . . . . . . . . . 8 73 4.5. HPSM and end-to-end proactive monitoring independence . . 9 74 4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 75 4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11 76 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12 77 4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13 78 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 10.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], 91 mechanisms MUST be available for alerting service providers of faults 92 or defects that affects their services. In addition, to ensure that 93 faults or service degradation can be localized, operators need a 94 function to diagnose the detected problem. Using end-to-end 95 monitoring for this purpose is insufficient in that an operator will 96 not be able to localize a fault or service degradation accurately. 98 A segment monitoring function that can focus on a specific segment of 99 a transport path and that can provide a detailed analysis is 100 indispensable to promptly and accurately localize the fault. A path 101 segment monitoring function has been defined to perform this task for 102 MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371 103 [RFC6371], the current method for segment monitoring of a transport 104 path has implications that hinder the usage in an operator network. 106 This document, after elaborating on the problem statement for the 107 path segment monitoring function as it is currently defined, provides 108 requirements for an on-demand segment monitoring function without 109 traffic distruption. Further works are required to evaluate how 110 proposed requirements match with current MPLS architecture and to 111 identify possibile solutions. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2.1. Terminology 121 HPSM - Hitless Path Segment Monitoring 123 LSP - Label Switched Path 125 LSR - Label Switching Router 127 ME - Maintenance Entity 129 MEG - Maintenance Entity Group 131 MEP - Maintenance Entity Group End Point 133 MIP - Maintenance Entity Group Intermediate Point 135 OTN - Optical Transport Network 137 TCM - Tandem connection monitoring 139 SPME - Sub-path Maintenance Element 141 3. Problem Statement 143 To monitor (and to protect and/or manage) MPLS-TP network segments a 144 Sub-Path Maintenance Element (SPME) function has been defined in RFC 145 5921 [RFC5921]. The SPME is defined between the edges of the segment 146 of a transport path that needs to be monitored, protected, or 147 managed. SPME is created by stacking the shim header (MPLS header) 148 according to RFC 3031 [RFC3031] and it is defined as the segment 149 where the header is stacked. OAM messages can be initiated at the 150 edge of the SPME and sent to the peer edge of the SPME or to a MIP 151 along the SPME by setting the TTL value of the label stack entry 152 (LSE) and interface identifier value at the corresponding 153 hierarchical LSP level in case of a per-node model. 155 MPLS-TP segment monitoring should satisfy two network objectives 156 according to section 3.8 of RFC 6371 [RFC6371]: 158 (N1) The monitoring and maintenance of current transport paths has 159 to be conducted in-service without traffic disruption. 161 (N2) Segment monitoring must not modify the forwarding of the 162 segment portion of the transport path. 164 The SPME function that has been defined in RFC 5921 [RFC5921] has 165 the following drawbacks: 167 (P1) It increases network management complexity, because a new 168 sublayer and new MEPs and MIPs have to be configured for the SPME. 170 (P2) Original conditions of the path change. 172 (P3) The client traffic over a transport path is disrupted if the 173 SPME is configured on-demand. 175 Problem (P1) is related to the management of each additional sub- 176 layer required for segment monitoring in a MPLS-TP network. When an 177 SPME is applied to administer on-demand OAM functions in MPLS-TP 178 networks, a rule for operationally differentiating those SPME will be 179 required at least within an administrative domain. This forces 180 operators to implement at least an additional layer into the 181 management systems that will only be used for on-demand path segment 182 monitoring. From the perspective of operation, increasing the number 183 of managed layers and managed addresses/identifiers is not desirable 184 in view of keeping the management systems as simple as possible. 185 Moreover, using the currently defined methods, on-demand setting of 186 SPMEs causes problems (P2) and (P3) due to additional label stacking. 188 Problem (P2) arises from the fact that MPLS exposed label value and 189 MPLS frames length changes. The monitoring function should monitor 190 the status without changing any condition of the target, to be 191 monitored, segment or transport path. Changing the settings of the 192 original shim header should not be allowed because this change 193 corresponds to creating a new segment of the original transport path 194 that differs from the original one. When the conditions of the path 195 change, the measured values or observed data will also change and 196 this may make the monitoring meaningless because the result of the 197 measurement would no longer reflect the performance of the connection 198 where the original fault or degradation occurred. As an example, 199 setting up an on-demand SPME will result in the LSRs within the 200 monitoring segment only looking at the added (stacked) labels and not 201 at the labels of the original LSP. This means that problems stemming 202 from incorrect (or unexpected) treatment of labels of the original 203 LSP by the nodes within the monitored segment cannot be identified 204 when setting up SPME. This might include hardware problems during 205 label look-up, mis-configuration, etc. Therefore operators have to 206 pay extra attention to correctly setting and checking the label 207 values of the original LSP in the configuration. Of course, the 208 reverse of this situation is also possible, e.g., an incorrect or 209 unexpected treatment of SPME labels can result in false detection of 210 a fault where no problem existed originally. 212 Figure 1 shows an example of SPME settings. In the figure, "X" is 213 the label value of the original path expected at the tail-end of node 214 D. "210" and "220" are label values allocated for SPME. The label 215 values of the original path are modified as well as the values of the 216 stacked labels. As shown in Figure 1, SPME changes both the length 217 of MPLS frames and the label value(s). In particular, performance 218 monitoring measurements (e.g. Delay Measurement and Packet Loss 219 Measurement) are sensitive to these changes. As an example, 220 increasing the packet lenght may impact on packet loss due to MTU 221 settings, modifying the label stack may introduce packet loss or it 222 may fix packet loss depending on the configuration status so 223 modifying network conditions. Such changes influence packets delay 224 too even if, from a practical point of view, it is likely that only a 225 few services will experience a practical impact. 227 (Before SPME settings) 228 --- --- --- --- --- 229 | | | | | | | | | | 230 | | | | | | | | | | 231 --- --- --- --- --- 232 A--100--B--110--C--120--D--130--E <= transport path 233 MEP MEP 235 (After SPME settings) 236 --- --- --- --- --- 237 | | | | | | | | | | 238 | | | | | | | | | | 239 --- --- --- --- --- 240 A--100--B-----------X---D--130--E <= transport path 241 MEP MEP 242 210--C--220 <= SPME 243 MEP' MEP' 245 Figure 1: SPME settings example 247 Problem (P3) can be avoided if the operator sets SPMEs in advance and 248 maintains them until the end of life of a transport path. But this 249 does not support on-demand. Furthermore SMPEs cannot be set 250 arbitrarily because overlapping of path segments is limited to 251 nesting relationships. As a result, possible SPME configurations of 252 segments of an original transport path are limited due to the 253 characteristic of the SPME shown in Figure 1, even if SPMEs are pre- 254 configured. 256 Although the make-before-break procedure in the survivability 257 document RFC 6372 [RFC6372] supports configuration for monitoring 258 according to the framework document RFC 5921 [RFC5921], without 259 traffic distruption, the configuration of an SPME is not possible 260 without violating network objective (N2). These concerns are 261 described in section 3.8 of RFC 6371 [RFC6371]. 263 Additionally, the make-before-break approach typically relies on a 264 control plane and requires additional functionalities for a 265 management system to properly support SPME creation and traffic 266 switching from the original transport path to the SPME. 268 As an example, the old and new transport resources (e.g. LSP 269 tunnels) might compete with each other for resources which they have 270 in common. Depending on availability of resources, this competition 271 can cause admission control to prevent the new LSP tunnel from being 272 established as this bandwidth accounting deviates from traditional 273 (non control plane) management system operation. While SPMEs can be 274 applied in any network context (single domain, multi domain, single 275 carrier, multi carrier, etc.), the main applications are in inter- 276 carrier or inter-domain segment monitoring where they are typically 277 pre- configured or pre-instantiated. SPME instantiates a 278 hierarchical path (introducing MPLS label stacking) through which OAM 279 packets can be sent. The SPME monitoring function is also mainly 280 important for protecting bundles of transport paths and carriers' 281 carrier solutions within an administrative domain. 283 The analogy for SPME in other transport technologies is Tandem 284 Connection Monitoring (TCM), used in Optical Transport Networks (OTN) 285 and Ethernet transport networks, which supports on-demand but does 286 not affect the path. For example in OTN, TCM allows the insertion 287 and removal of performance monitoring overhead within the frame at 288 intermediate points in the network. It is done such that their 289 insertion and removal do not change the conditions of the path. 290 Though as the OAM overhead is part of the frame (designated overhead 291 bytes), it is constrained to a pre-defined number of monitoring 292 segments. 294 To summarize: the problem statement is that the current sub-path 295 maintenance based on a hierarchical LSP (SPME) is problematic for 296 pre-configuration in terms of increasing the number of managed 297 objects by layer stacking and identifiers/addresses. An on-demand 298 configuration of SPME is one of the possible approaches for 299 minimizing the impact of these issues. However, the current 300 procedure is unfavourable because the on-demand configuration for 301 monitoring changes the condition of the original monitored path. To 302 avoid or minimize the impact of the drawbacks discussed above, a more 303 efficient approach is required for the operation of an MPLS-TP 304 transport network. A monitoring mechanism, named Hitless Path 305 Segment Monitoring (HPSM), supporting on-demand path segment 306 monitoring without traffic disruption is needed. 308 4. Requirements for Hitless Path Segment Monitoring 310 In the following sections, mandatory (M) and optional (O) 311 requirements for the Hitless Path Segment Monitoring function are 312 listed. 314 4.1. Backward compatibility 316 HPSM would be an additional OAM tool that would not replace SPME. As 317 such: 319 (M1) HPSM MUST be compatible with the usage of SPME 321 (O1) HPSM SHOULD be applicable at the SPME layer too 322 (M2) HPSM MUST support both the per-node and per-interface model 323 as specified in RFC 6371 [RFC6371]. 325 4.2. Non-intrusive segment monitoring 327 One of the major problems of legacy SPME highlighted in section 3 is 328 that it may not monitor the original path and it could disrupt 329 service traffic when set-up on demand. 331 (M3) HPSM MUST NOT change the original conditions of transport 332 path (e.g. must not change the length of MPLS frames, the exposed 333 label values, etc.) 335 (M4) HPSM MUST support on-demand provisioning without traffic 336 disruption. 338 4.3. Multiple segments monitoring 340 Along a transport path there may be the need to support 341 simultaneously monitoring multiple segments 343 (M5) HPSM MUST support configuration of multiple monitoring 344 segments along a transport path. 346 --- --- --- --- --- 347 | | | | | | | | | | 348 | A | | B | | C | | D | | E | 349 --- --- --- --- --- 350 MEP MEP <= ME of a transport path 351 *------* *----* *--------------* <=three HPSM monit. instances 353 Figure 2: Multiple HPSM instances example 355 4.4. Single and multiple level monitoring 357 HPSM would apply mainly for on-demand diagnostic purposes. With the 358 currently defined approach, the most serious problem is that there is 359 no way to locate the degraded segment of a path without changing the 360 conditions of the original path. Therefore, as a first step, a 361 single level, single segment monitoring, not affecting the monitored 362 path, is required for HPSM. A combination of multi-level and 363 simultaneous segments monitoring is the most powerful tool for 364 accurately diagnosing the performance of a transport path. However, 365 in the field, a single level, multiple segments approach would be 366 less complex for management and operations. 368 (M6) HPSM MUST support single-level segment monitoring 370 (O2) HPSM MAY support multi-level segment monitoring. 372 Figure 3 shows an example of multi-level HPSM. 374 --- --- --- --- --- 375 | | | | | | | | | | 376 | A | | B | | C | | D | | E | 377 --- --- --- --- --- 378 MEP MEP <= ME of a transport path 379 *-----------------* <=On-demand HPSM level 1 380 *-------------* <=On-demand HPSM level 2 381 *-* <=On-demand HPSM level 3 383 Figure 3: Multi-level HPSM example 385 4.5. HPSM and end-to-end proactive monitoring independence 387 There is a need for simultaneously using existing end-to-end 388 proactive monitoring and on-demand path segment monitoring. 389 Normally, the on-demand path segment monitoring is configured on a 390 segment of a maintenance entity of a transport path. In such an 391 environment, on-demand single-level monitoring should be performed 392 without disrupting the pro-active monitoring of the targeted end-to- 393 end transport path to avoid affecting user traffic performance 394 monitoring. 396 (M7) HPSM MUST support the capability of being operated 397 concurrently to, and independently of OAM function operated on the 398 end-to-end path 400 --- --- --- --- --- 401 | | | | | | | | | | 402 | A | | B | | C | | D | | E | 403 --- --- --- --- --- 404 MEP MEP <= ME of a transport path 405 +-----------------------------+ <= Pro-active end-to-end mon. 406 *------------------* <= On-demand HPSM 408 Figure 4: Independence between proactive end-to-end monitoring and 409 on-demand HPSM 411 4.6. Arbitrary segment monitoring 413 The main objective for on-demand segment monitoring is to diagnose 414 the fault locations. A possible realistic diagnostic procedure is to 415 fix one end point of a segment at the MEP of the transport path under 416 observation and change progressively the length of the segments. It 417 is therefore possible to monitoring step by step all the path with a 418 granularity that depends on equipment implementations. For example, 419 Figure 5 shows the case where the granularity is at interface level 420 (i.e. monitoring is at each input interface and output interface of 421 each piece of equipment). 423 --- --- --- --- --- 424 | | | | | | | | | | 425 | A | | B | | C | | D | | E | 426 --- --- --- --- --- 427 MEP MEP <= ME of a transport path 428 +-----------------------------+ <= Pro-active end-to-end mon. 429 *-----* <= 1st on-demand HPSM 430 *-------* <= 2nd on-demand HPSM 431 | | 432 | | 433 *-----------------------* <= 4th on-demand HPSM 434 *-----------------------------* <= 5th on-demand HPSM 436 Figure 5: Localization of a defect by consecutive on-demand segment 437 monitoring procedure 439 Another possible scenario is depicted in Figure 6. In this case, the 440 operator wants to diagnose a transport path starting at a transit 441 node, because the end nodes (A and E) are located at customer sites 442 and consist of small boxes supporting only a subset of OAM functions. 443 In this case, where the source entities of the diagnostic packets are 444 limited to the position of MEPs, on-demand segment monitoring will be 445 ineffective because not all the segments can be diagnosed (e.g. 446 segment monitoring HPSM 3 in Figure 6 is not available and it is not 447 possible to determine the fault location exactly). 449 (M8) It SHALL be possible to provision HPSM on an arbitrary 450 segment of a transport path. 452 --- --- --- 453 --- | | | | | | --- 454 | A | | B | | C | | D | | E | 455 --- --- --- --- --- 456 MEP MEP <= ME of a transport path 457 +-----------------------------+ <= Pro-active end-to-end mon. 458 *-----* <= On-demand HPSM 1 459 *-----------------------* <= On-demand HPSM 2 460 *---------* <= On-demand HPSM 3 462 Figure 6: HPSM configuration at arbitrary segments 464 4.7. Fault while HPSM is operational 466 Node or link failures may occur while HPSM is active. In this case, 467 if no resiliency mechanism is set-up on the subtended transport path, 468 there is no particular requirement for HPSM. If the transport path 469 is protected, the HPSM function may bring to monitoring unintended 470 segments. The following examples are provided for clarification. 472 Protection scenario A is shown in figure 7. In this scenario a 473 working LSP and a protection LSP are set-up. HPSM is activated 474 between nodes A and E. When a fault occurs between nodes B and C, 475 the operation of HPSM is not affected by the protection switch and 476 continues on the active LSP path. 478 A - B - C - D - E - F 479 \ / 480 G - H - I - L 482 Where: 483 - end-to-end LSP: A-B-C-D-E-F 484 - working LSP: A-B-C-D-E-F 485 - protection LSP: A-G-H-I-L-F 486 - HPSM: A-E 488 Figure 7: Protection scenario A 490 Protection scenario B is shown in figure 8. The difference with 491 scenario A is that only a portion of the transport path is protected. 492 In this case, when a fault occurs between nodes B and C on the 493 working sub-path B-C-D, traffic will be switched to protection sub- 494 path B-G-H-D. Assuming that OAM packet termination depends only on 495 the TTL value of the MPLS label header, the target node of the HPSM 496 changes from E to D due to the difference of hop counts between the 497 working path route (A-B-C-D-E: 4 hops) and protection path route 498 (A-B-G-H-D-E: 5 hops). In this case the operation of HPSM is 499 affected. 501 A - B - C - D - E - F 502 \ / 503 G - H 505 - end-to-end LSP: A-B-C-D-E-F 506 - working sub-path: B-C-D 507 - protection sub-path: B-G-H-D 508 - HPSM: A-E 510 Figure 8: Protection scenario B 512 (M9) The HPSM SHOULD avoid monitoring an unintended segment when 513 one or more failures occur 515 There are potentially different solutions to satisfy such a 516 requirement. A possible solution may be to suspend HPSM monitoring 517 until network restoration takes place. Another possible approach may 518 be to compare the node/interface ID in the OAM packet with that at 519 the node reached at TTL termination and if this does not match 520 through some means trigger a suspension of HPSM monitoring. The 521 above approaches are valid in any circumstance, both for protected 522 and unprotected networks LSPs. These examples should not be taken to 523 limit the design of a solution. 525 4.8. HPSM Manageability 527 From managing perspective, increasing the number of managed layers 528 and managed addresses/identifiers is not desirable in view of keeping 529 the management systems as simple as possible. 531 (M10)HPSM SHOULD NOT be based on additional transport layers (e.g. 532 hierarchical LSPs) 534 (M11) The same identifiers used for MIPs and/or MEPs SHOULD be 535 applied to maintenance points for the HPSM when they are 536 instantiated in the same place along a transport path. 538 Anyway maintenance points for the HPSM may be different from MIPs 539 and MEPs functional components as defined in the OAM framework 540 document RFC 6371 [RFC6371]. Investigating potential solutions 541 for satisfying proposed HPSM requirements might lead to propose 542 new functional components that have to be backward compatible with 543 MPLS architecture. Solutions are outside the scope of this 544 document. 546 4.9. Supported OAM functions 548 A maintenance point supporting the HPSM function has to be able to 549 generate and inject OAM packets. OAM functions that may be 550 applicable for on-demand HPSM are basically the on-demand performance 551 monitoring functions which are defined in the OAM framework document 552 RFC 6371 [RFC6371]. The "on-demand" attribute is typically temporary 553 for maintenance operation. 555 (M12) HPSM MUST support Packet Loss and Packet Delay measurement. 557 That because these functions are normally only supported at the end 558 points of a transport path. If a defect occurs, it might be quite 559 hard to locate the defect or degradation point without using the 560 segment monitoring function. If an operator cannot locate or narrow 561 down the cause of the fault, it is quite difficult to take prompt 562 actions to solve the problem. 564 Other on-demand monitoring functions (e.g. Delay Variation 565 measurement) are desirable but not as necessary as the functions 566 mentioned above. 568 (O3) HPSM MAY support Packet Delay variation, Throughput 569 measurement and other performance monitoring and fault management 570 functions. 572 Support of out-of-service on-demand performance management functions 573 (e.g. Throughput measurement) is not required for HPSM. 575 5. Summary 577 A new hitless path segment monitoring (HPSM) mechanism is required to 578 provide on-demand segment monitoring without traffic disruption. It 579 shall meet the two network objectives described in section 3.8 of RFC 580 6371 [RFC6371] and summarized in Section 3 of this document. 582 The mechanism should minimize the problems described in Section 3, 583 i.e. (P1), (P2) and (P3). 585 The solution for the on-demand segment monitoring without traffic 586 disruption needs to cover both the per-node model and the per- 587 interface model specified in RFC 6371 [RFC6371]. 589 The on-demand segment monitoring without traffic disruption solution 590 needs to support on-demand Packet Loss Measurement and Packet Delay 591 Measurement functions and optionally other performance monitoring and 592 fault management functions (e.g. Throughput measurement, Packet 593 Delay variation measurement, Diagnostic test, etc.). 595 6. Security Considerations 597 Security is a significant requirement of MPLS Transport Profile. The 598 document provides a problem statement and requirements to guide the 599 development of new OAM tools to support Hitless Path Segment 600 Monitoring. Such new tools must follow the security considerations 601 provided in OAM Requirements for MPLS-TP in RFC5860 [RFC5860]. 603 7. IANA Considerations 605 There are no requests for IANA actions in this document. 607 Note to the RFC Editor - this section can be removed before 608 publication. 610 8. Contributors 612 Manuel Paul 614 Deutsche Telekom AG 616 Email: manuel.paul@telekom.de 618 9. Acknowledgements 620 The authors would also like to thank Alexander Vainshtein, Dave 621 Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, 622 Maarten Vissers, Jia He and Nurit Sprecher for their comments and 623 enhancements to the text. 625 10. References 627 10.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, . 634 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 635 Label Switching Architecture", RFC 3031, 636 DOI 10.17487/RFC3031, January 2001, . 639 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 640 "Requirements for Operations, Administration, and 641 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 642 DOI 10.17487/RFC5860, May 2010, . 645 10.2. Informative References 647 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 648 L., and L. Berger, "A Framework for MPLS in Transport 649 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 650 . 652 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 653 Administration, and Maintenance Framework for MPLS-Based 654 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 655 September 2011, . 657 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 658 Profile (MPLS-TP) Survivability Framework", RFC 6372, 659 DOI 10.17487/RFC6372, September 2011, . 662 Authors' Addresses 664 Alessandro D'Alessandro 665 Telecom Italia 666 Via Reiss Romoli, 274 667 Torino 10148 668 Italy 670 Email: alessandro.dalessandro@telecomitalia.it 672 Loa Andersson 673 Huawei Technologies 675 Email: loa@mail01.huawei.com 677 Satoshi Ueno 678 NTT Communications 680 Email: satoshi.ueno@ntt.com 681 Kaoru Arai 682 NTT 684 Email: arai.kaoru@lab.ntt.co.jp 686 Yoshinori Koike 687 NTT 689 Email: y.koike@vcd.nttbiz.com