idnits 2.17.1 draft-ietf-mpls-tp-temporal-hitless-psm-13.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 (March 8, 2017) is 2605 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: September 9, 2017 Huawei Technologies 6 S. Ueno 7 NTT Communications 8 K. Arai 9 Y. Koike 10 NTT 11 March 8, 2017 13 Requirements for hitless MPLS path segment monitoring 14 draft-ietf-mpls-tp-temporal-hitless-psm-13.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 September 9, 2017. 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 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Requirements for Hitless Path Segment Monitoring . . . . . . 7 70 4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7 71 4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8 72 4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8 73 4.4. Single and multiple level monitoring . . . . . . . . . . 8 74 4.5. HPSM and end-to-end proactive monitoring independence . . 9 75 4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 76 4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11 77 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12 78 4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13 79 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 10.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], 92 mechanisms MUST be available for alerting service providers of faults 93 or defects that affects their services. In addition, to ensure that 94 faults or service degradation can be localized, operators need a 95 function to diagnose the detected problem. Using end-to-end 96 monitoring for this purpose is insufficient in that an operator will 97 not be able to localize a fault or service degradation accurately. 99 A segment monitoring function that can focus on a specific segment of 100 a transport path and that can provide a detailed analysis is 101 indispensable to promptly and accurately localize the fault. A path 102 segment monitoring function has been defined to perform this task for 103 MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371 104 [RFC6371], the current method for segment monitoring of a transport 105 path has implications that hinder the usage in an operator network. 107 This document, after elaborating on the problem statement for the 108 path segment monitoring function as it is currently defined, provides 109 requirements for an on-demand segment monitoring function without 110 traffic distruption. Further works are required to evaluate how 111 proposed requirements match with current MPLS architecture and to 112 identify possibile solutions. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2.1. Terminology 122 ATM - Asynchronous Transfer Mode 124 HPSM - Hitless Path Segment Monitoring 126 LSP - Label Switched Path 128 LSR - Label Switching Router 130 ME - Maintenance Entity 132 MEG - Maintenance Entity Group 134 MEP - Maintenance Entity Group End Point 136 MIP - Maintenance Entity Group Intermediate Point 138 OTN - Optical Transport Network 140 TCM - Tandem connection monitoring 142 SPME - Sub-path Maintenance Element 144 2.2. Definitions 146 None. 148 3. Problem Statement 150 To monitor (and to protect and/or manage) MPLS-TP network segments a 151 Sub-Path Maintenance Element (SPME) function has been defined in RFC 152 5921 [RFC5921]. The SPME is defined between the edges of the segment 153 of a transport path that needs to be monitored, protected, or 154 managed. SPME is created by stacking the shim header (MPLS header) 155 according to RFC 3031 [RFC3031] and it is defined as the segment 156 where the header is stacked. OAM messages can be initiated at the 157 edge of the SPME and sent to the peer edge of the SPME or to a MIP 158 along the SPME by setting the TTL value of the label stack entry 159 (LSE) and interface identifier value at the corresponding 160 hierarchical LSP level in case of a per-node model. 162 MPLS-TP segment monitoring should satisfy two network objectives 163 according to section 3.8 of RFC 6371 [RFC6371]: 165 (N1) The monitoring and maintenance of current transport paths has 166 to be conducted in-service without traffic disruption. 168 (N2) Segment monitoring must not modify the forwarding of the 169 segment portion of the transport path. 171 The SPME function that has been defined in RFC 5921 [RFC5921] has 172 the following drawbacks: 174 (P1) It increases network management complexity, because a new 175 sublayer and new MEPs and MIPs have to be configured for the SPME. 177 (P2) Original conditions of the path change. 179 (P3) The client traffic over a transport path is disrupted if the 180 SPME is configured on-demand. 182 Problem (P1) is related to the management of each additional sub- 183 layer required for segment monitoring in a MPLS-TP network. When an 184 SPME is applied to administer on-demand OAM functions in MPLS-TP 185 networks, a rule for operationally differentiating those SPME will be 186 required at least within an administrative domain. This forces 187 operators to implement at least an additional layer into the 188 management systems that will only be used for on-demand path segment 189 monitoring. From the perspective of operation, increasing the number 190 of managed layers and managed addresses/identifiers is not desirable 191 in view of keeping the management systems as simple as possible. 193 Moreover, using the currently defined methods, on-demand setting of 194 SPMEs causes problems (P2) and (P3) due to additional label stacking. 196 Problem (P2) arises from the fact that MPLS exposed label value and 197 MPLS frames length changes. The monitoring function should monitor 198 the status without changing any conditions of the targeted, to be 199 monitored, segment or transport path. Changing the settings of the 200 original shim header should not be allowed because this change 201 corresponds to creating a new segment of the original transport path 202 that differs from the original one. When the conditions of the path 203 change, the measured values or observed data will also change and 204 this may make the monitoring meaningless because the result of the 205 measurement would no longer reflect the performance of the connection 206 where the original fault or degradation occurred. As an example, 207 setting up an on-demand SPME will result in the LSRs within the 208 monitoring segment only looking at the added (stacked) labels and not 209 at the labels of the original LSP. This means that problems stemming 210 from incorrect (or unexpected) treatment of labels of the original 211 LSP by the nodes within the monitored segment cannot be identified 212 when setting up SPME. This might include hardware problems during 213 label look-up, mis-configuration, etc. Therefore operators have to 214 pay extra attention to correctly setting and checking the label 215 values of the original LSP in the configuration. Of course, the 216 reverse of this situation is also possible, e.g., an incorrect or 217 unexpected treatment of SPME labels can result in false detection of 218 a fault where no problem existed originally. 220 Figure 1 shows an example of SPME settings. In the figure, "X" is 221 the label value of the original path expected at the tail-end of node 222 D. "210" and "220" are label values allocated for SPME. The label 223 values of the original path are modified as well as the values of the 224 stacked labels. As shown in Figure 1, SPME changes both the length 225 of MPLS frames and the label value(s). In particular, performance 226 monitoring measurements (e.g. Delay Measurement and Packet Loss 227 Measurement) are sensitive to these changes. As an example, 228 increasing the packet lenght may impact on packet loss due to MTU 229 settings, modifying the label stack may introduce packet loss or it 230 may fix packet loss depending on the configuration status so 231 modifying network conditions. Such changes influence packets delay 232 too even if, from a practical point of view, it is likely that only a 233 few services will experience a practical impact. 235 (Before SPME settings) 236 --- --- --- --- --- 237 | | | | | | | | | | 238 | | | | | | | | | | 239 --- --- --- --- --- 240 A--100--B--110--C--120--D--130--E <= transport path 241 MEP MEP 243 (After SPME settings) 244 --- --- --- --- --- 245 | | | | | | | | | | 246 | | | | | | | | | | 247 --- --- --- --- --- 248 A--100--B-----------X---D--130--E <= transport path 249 MEP MEP 250 210--C--220 <= SPME 251 MEP' MEP' 253 Figure 1: SPME settings example 255 Problem (P3) can be avoided if the operator sets SPMEs in advance and 256 maintains them until the end of life of a transport path. But this 257 does not support on-demand. Furthermore SMPEs cannot be set 258 arbitrarily because overlapping of path segments is limited to 259 nesting relationships. As a result, possible SPME configurations of 260 segments of an original transport path are limited due to the 261 characteristic of the SPME shown in Figure 1, even if SPMEs are pre- 262 configured. 264 Although the make-before-break procedure in the survivability 265 document RFC 6372 [RFC6372] supports configuration for monitoring 266 according to the framework document RFC 5921 [RFC5921], without 267 traffic distruption, the configuration of an SPME is not possible 268 without violating network objective (N2). These concerns are 269 described in section 3.8 of RFC 6371 [RFC6371]. 271 Additionally, the make-before-break approach typically relies on a 272 control plane and requires additional functionalities for a 273 management system to properly support SPME creation and traffic 274 switching from the original transport path to the SPME. 276 As an example, the old and new transport resources (e.g. LSP 277 tunnels) might compete with each other for resources which they have 278 in common. Depending on availability of resources, this competition 279 can cause admission control to prevent the new LSP tunnel from being 280 established as this bandwidth accounting deviates from traditional 281 (non control plane) management system operation. While SPMEs can be 282 applied in any network context (single domain, multi domain, single 283 carrier, multi carrier, etc.), the main applications are in inter- 284 carrier or inter-domain segment monitoring where they are typically 285 pre- configured or pre-instantiated. SPME instantiates a 286 hierarchical path (introducing MPLS label stacking) through which OAM 287 packets can be sent. The SPME monitoring function is also mainly 288 important for protecting bundles of transport paths and carriers' 289 carrier solutions within an administrative domain. 291 The analogy for SPME in other transport technologies is Tandem 292 Connection Monitoring (TCM), used in Optical Transport Networks (OTN) 293 and Ethernet transport networks, which supports on-demand but does 294 not affect the path. For example in OTN, TCM allows the insertion 295 and removal of performance monitoring overhead within the frame at 296 intermediate points in the network. It is done such that their 297 insertion and removal do not change the conditions of the path. 298 Though as the OAM overhead is part of the frame (designated overhead 299 bytes), it is constrained to a pre-defined number of monitoring 300 segments. 302 To summarize: the problem statement is that the current sub-path 303 maintenance based on a hierarchical LSP (SPME) is problematic for 304 pre-configuration in terms of increasing the number of managed 305 objects by layer stacking and identifiers/addresses. An on-demand 306 configuration of SPME is one of the possible approaches for 307 minimizing the impact of these issues. However, the current 308 procedure is unfavourable because the on-demand configuration for 309 monitoring changes the condition of the original monitored path. To 310 avoid or minimize the impact of the drawbacks discussed above, a more 311 efficient approach is required for the operation of an MPLS-TP 312 transport network. A monitoring mechanism, named Hitless Path 313 Segment Monitoring (HPSM), supporting on-demand path segment 314 monitoring without traffic disruption is needed. 316 4. Requirements for Hitless Path Segment Monitoring 318 In the following sections, mandatory (M) and optional (O) 319 requirements for the Hitless Path Segment Monitoring function are 320 listed. 322 4.1. Backward compatibility 324 HPSM would be an additional OAM tool that would not replace SPME. As 325 such: 327 (M1) HPSM MUST be compatible with the usage of SPME 329 (O1) HPSM SHOULD be applicable at the SPME layer too 330 (M2) HPSM MUST support both the per-node and per-interface model 331 as specified in RFC 6371 [RFC6371]. 333 4.2. Non-intrusive segment monitoring 335 One of the major problems of legacy SPME highlighted in section 3 is 336 that it may not monitor the original path and it could disrupt 337 service traffic when set-up on demand. 339 (M3) HPSM MUST NOT change the original conditions of transport 340 path (e.g. must not change the length of MPLS frames, the exposed 341 label values, etc.) 343 (M4) HPSM MUST support on-demand provisioning without traffic 344 disruption. 346 4.3. Multiple segments monitoring 348 Along a transport path there may be the need to support 349 simultaneously monitoring multiple segments 351 (M5) HPSM MUST support configuration of multiple monitoring 352 segments along a transport path. 354 --- --- --- --- --- 355 | | | | | | | | | | 356 | A | | B | | C | | D | | E | 357 --- --- --- --- --- 358 MEP MEP <= ME of a transport path 359 *------* *----* *--------------* <=three HPSM monit. instances 361 Figure 2: Multiple HPSM instances example 363 4.4. Single and multiple level monitoring 365 HPSM would apply mainly for on-demand diagnostic purposes. With the 366 currently defined approach, the most serious problem is that there is 367 no way to locate the degraded segment of a path without changing the 368 conditions of the original path. Therefore, as a first step, a 369 single level, single segment monitoring, not affecting the monitored 370 path, is required for HPSM. A combination of multi-level and 371 simultaneous segments monitoring is the most powerful tool for 372 accurately diagnosing the performance of a transport path. However, 373 in the field, a single level, multiple segments approach would be 374 less complex for management and operations. 376 (M6) HPSM MUST support single-level segment monitoring 378 (O2) HPSM MAY support multi-level segment monitoring. 380 Figure 3 shows an example of multi-level HPSM. 382 --- --- --- --- --- 383 | | | | | | | | | | 384 | A | | B | | C | | D | | E | 385 --- --- --- --- --- 386 MEP MEP <= ME of a transport path 387 *-----------------* <=On-demand HPSM level 1 388 *-------------* <=On-demand HPSM level 2 389 *-* <=On-demand HPSM level 3 391 Figure 3: Multi-level HPSM example 393 4.5. HPSM and end-to-end proactive monitoring independence 395 There is a need for simultaneously using existing end-to-end 396 proactive monitoring and on-demand path segment monitoring. 397 Normally, the on-demand path segment monitoring is configured on a 398 segment of a maintenance entity of a transport path. In such an 399 environment, on-demand single-level monitoring should be performed 400 without disrupting the pro-active monitoring of the targeted end-to- 401 end transport path to avoid affecting user traffic performance 402 monitoring. 404 (M7) HPSM MUST support the capability of being operated 405 concurrently to, and independently of operated of the OAM function 406 operated on the end-to-end path 408 --- --- --- --- --- 409 | | | | | | | | | | 410 | A | | B | | C | | D | | E | 411 --- --- --- --- --- 412 MEP MEP <= ME of a transport path 413 +-----------------------------+ <= Pro-active end-to-end mon. 414 *------------------* <= On-demand HPSM 416 Figure 4: Independence between proactive end-to-end monitoring and 417 on-demand HPSM 419 4.6. Arbitrary segment monitoring 421 The main objective for on-demand segment monitoring is to diagnose 422 the fault locations. A possible realistic diagnostic procedure is to 423 fix one end point of a segment at the MEP of the transport path under 424 observation and change progressively the length of the segments. It 425 is therefore possible to monitoring step by step all the path with a 426 granularity that depends on equipment implementations. For example, 427 Figure 5 shows the case where the granularity is at interface level 428 (i.e. monitoring is at each input interface and output interface of 429 each piece of equipment). 431 --- --- --- --- --- 432 | | | | | | | | | | 433 | A | | B | | C | | D | | E | 434 --- --- --- --- --- 435 MEP MEP <= ME of a transport path 436 +-----------------------------+ <= Pro-active end-to-end mon. 437 *-----* <= 1st on-demand HPSM 438 *-------* <= 2nd on-demand HPSM 439 | | 440 | | 441 *-----------------------* <= 4th on-demand HPSM 442 *-----------------------------* <= 5th on-demand HPSM 444 Figure 5: Localization of a defect by consecutive on-demand segment 445 monitoring procedure 447 Another possible scenario is depicted in Figure 6. In this case, the 448 operator wants to diagnose a transport path starting at a transit 449 node, because the end nodes (A and E) are located at customer sites 450 and consist of small boxes supporting only a subset of OAM functions. 451 In this case, where the source entities of the diagnostic packets are 452 limited to the position of MEPs, on-demand segment monitoring will be 453 ineffective because not all the segments can be diagnosed (e.g. 454 segment monitoring HPSM 3 in Figure 6 is not available and it is not 455 possible to determine the fault location exactly). 457 (M8) It SHALL be possible to provision HPSM on an arbitrary 458 segment of a transport path. 460 --- --- --- 461 --- | | | | | | --- 462 | A | | B | | C | | D | | E | 463 --- --- --- --- --- 464 MEP MEP <= ME of a transport path 465 +-----------------------------+ <= Pro-active end-to-end mon. 466 *-----* <= On-demand HPSM 1 467 *-----------------------* <= On-demand HPSM 2 468 *---------* <= On-demand HPSM 3 470 Figure 6: HPSM configuration at arbitrary segments 472 4.7. Fault while HPSM is operational 474 Node or link failures may occur while HPSM is active. In this case, 475 if no resiliency mechanism is set-up on the subtended transport path, 476 there is no particular requirement for HPSM. If the transport path 477 is protected, the HPSM function should be terminated to avoid 478 monitoring a new segment when a protection or restoration path is 479 active. 481 (M9) The HPSM SHOULD avoid monitoring an unintended segment when 482 one or more failures occur 484 The following examples are provided for clarification only and they 485 are not intended to restrict any solution for meeting the 486 requirements of HPSM. 488 Protection scenario A is shown in figure 7. In this scenario a 489 working LSP and a protection LSP are set-up. HPSM is activated 490 between nodes A and E. When a fault occurs between nodes B and C, 491 the operation of HPSM is not affected by the protection switch and 492 continues on the active LSP path. As a result requirement (M9) is 493 satisfied. 495 A - B - C - D - E - F 496 \ / 497 G - H - I - L 499 Where: 500 - end-to-end LSP: A-B-C-D-E-F 501 - working LSP: A-B-C-D-E-F 502 - protection LSP: A-G-H-I-L-F 503 - HPSM: A-E 505 Figure 7: Protection scenario A 507 Protection scenario B is shown in figure 8. The difference with 508 scenario A is that only a portion of the transport path is protected. 509 In this case, when a fault occurs between nodes B and C on the 510 working sub-path B-C-D, traffic will be switched to protection sub- 511 path B-G-H-D. Assuming that OAM packet termination depends only on 512 the TTL value of the MPLS label header, the target node of the HPSM 513 changes from E to D due to the difference of hop counts between the 514 working path route (A-B-C-D-E: 4 hops) and protection path route 515 (A-B-G-H-D-E: 5 hops). As a result requirement (M9) is not 516 satisfied. 518 A - B - C - D - E - F 519 \ / 520 G - H 522 - end-to-end LSP: A-B-C-D-E-F 523 - working sub-path: B-C-D 524 - protection sub-path: B-G-H-D 525 - HPSM: A-E 527 Figure 8: Protection scenario B 529 4.8. HPSM Manageability 531 From managing perspective, increasing the number of managed layers 532 and managed addresses/identifiers is not desirable in view of keeping 533 the management systems as simple as possible. 535 (M10)HPSM SHOULD NOT be based on additional transport layers (e.g. 536 hierarchical LSPs) 537 (M11) The same identifiers used for MIPs and/or MEPs SHOULD be 538 applied to maintenance points for the HPSM when they are 539 instantiated in the same place along a transport path. 541 Anyway maintenance points for the HPSM may be different from MIPs 542 and MEPs functional components as defined in the OAM framework 543 document RFC 6371 [RFC6371]. Investigating potential solutions 544 for satisfying proposed HPSM requirements might lead to propose 545 new functional components that have to be backward compatible with 546 MPLS architecture. Solutions are outside the scope of this 547 document. 549 4.9. Supported OAM functions 551 A maintenance point supporting the HPSM function has to be able to 552 generate and inject OAM packets. OAM functions that may be 553 applicable for on-demand HPSM are basically the on-demand performance 554 monitoring functions which are defined in the OAM framework document 555 RFC 6371 [RFC6371]. The "on-demand" attribute is typically temporary 556 for maintenance operation. 558 (M12) HPSM MUST support Packet Loss and Packet Delay measurement. 560 That because these functions are normally only supported at the end 561 points of a transport path. If a defect occurs, it might be quite 562 hard to locate the defect or degradation point without using the 563 segment monitoring function. If an operator cannot locate or narrow 564 down the cause of the fault, it is quite difficult to take prompt 565 actions to solve the problem. 567 Other on-demand monitoring functions (e.g. Delay Variation 568 measurement) are desirable but not as necessary as the functions 569 mentioned above. 571 (O3) HPSM MAY support Packet Delay variation, Throughput 572 measurement and other performance monitoring and fault management 573 functions. 575 Support of out-of-service on-demand performance management functions 576 (e.g. Throughput measurement) is not required for HPSM. 578 5. Summary 580 A new hitless path segment monitoring (HPSM) mechanism is required to 581 provide on-demand segment monitoring without traffic disruption. It 582 shall meet the two network objectives described in section 3.8 of RFC 583 6371 [RFC6371] and summarized in Section 3 of this document. 585 The mechanism should minimize the problems described in Section 3, 586 i.e. (P1), (P2) and (P3). 588 The solution for the on-demand segment monitoring without traffic 589 disruption needs to cover both the per-node model and the per- 590 interface model specified in RFC 6371 [RFC6371]. 592 The on-demand segment monitoring without traffic disruption solution 593 needs to support on-demand Packet Loss Measurement and Packet Delay 594 Measurement functions and optionally other performance monitoring and 595 fault management functions (e.g. Throughput measurement, Packet 596 Delay variation measurement, Diagnostic test, etc.). 598 6. Security Considerations 600 Security is a significant requirement of MPLS Transport Profile. The 601 document provides a problem statement and requirements to guide the 602 development of new OAM tools to support Hitless Path Segment 603 Monitoring. Such new tools must follow the security considerations 604 provided in OAM Requirements for MPLS-TP in RFC5860 [RFC5860]. 606 7. IANA Considerations 608 There are no requests for IANA actions in this document. 610 Note to the RFC Editor - this section can be removed before 611 publication. 613 8. Contributors 615 Manuel Paul 617 Deutsche Telekom AG 619 Email: manuel.paul@telekom.de 621 9. Acknowledgements 623 The authors would also like to thank Alexander Vainshtein, Dave 624 Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, 625 Maarten Vissers, Jia He and Nurit Sprecher for their comments and 626 enhancements to the text. 628 10. References 629 10.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, 634 . 636 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 637 Label Switching Architecture", RFC 3031, 638 DOI 10.17487/RFC3031, January 2001, 639 . 641 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 642 "Requirements for Operations, Administration, and 643 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 644 DOI 10.17487/RFC5860, May 2010, 645 . 647 10.2. Informative References 649 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 650 L., and L. Berger, "A Framework for MPLS in Transport 651 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 652 . 654 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 655 Administration, and Maintenance Framework for MPLS-Based 656 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 657 September 2011, . 659 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 660 Profile (MPLS-TP) Survivability Framework", RFC 6372, 661 DOI 10.17487/RFC6372, September 2011, 662 . 664 Authors' Addresses 666 Alessandro D'Alessandro 667 Telecom Italia 668 Via Reiss Romoli, 274 669 Torino 10148 670 Italy 672 Email: alessandro.dalessandro@telecomitalia.it 673 Loa Andersson 674 Huawei Technologies 676 Email: loa@mail01.huawei.com 678 Satoshi Ueno 679 NTT Communications 681 Email: satoshi.ueno@ntt.com 683 Kaoru Arai 684 NTT 686 Email: arai.kaoru@lab.ntt.co.jp 688 Yoshinori Koike 689 NTT 691 Email: y.koike@vcd.nttbiz.com