idnits 2.17.1 draft-ietf-mpls-tp-temporal-hitless-psm-10.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6371]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2016) is 2880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: December 2, 2016 Huawei Technologies 6 S. Ueno 7 NTT Communications 8 K. Arai 9 Y. Koike 10 NTT 11 May 31, 2016 13 Hitless path segment monitoring 14 draft-ietf-mpls-tp-temporal-hitless-psm-10.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 RFC 6371 [RFC6371] has drawbacks. This document 24 provides an analysis of the existing MPLS-TP OAM mechanisms for the 25 path segment monitoring and provides requirements to guide the 26 development of new OAM tools to support a Hitless Path Segment 27 Monitoring (HPSM). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 2, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Requirements for hitless 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 Thus, a segment monitoring function that can focus on a specific 99 segment of a transport path and can provide a detailed analysis is 100 indispensable to promptly and accurately localize the fault. For 101 MPLS-TP, a path segment monitoring function has been defined to 102 perform this task. However, as noted in the MPLS-TP OAM Framework 103 RFC 6371 [RFC6371], the current method for segment monitoring of a 104 transport path has implications that hinder the usage in an operator 105 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. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2.1. Terminology 120 ATM - Asynchronous Transfer Mode 122 HPSM - Hitless Path Segment Monitoring 124 LSP - Label Switched Path 126 LSR - Label Switching Router 128 ME - Maintenance Entity 130 MEG - Maintenance Entity Group 132 MEP - Maintenance Entity Group End Point 134 MIP - Maintenance Entity Group Intermediate Point 136 OTN - Optical Transport Network 138 TCM - Tandem connection monitoring 140 SPME - Sub-path Maintenance Element 142 2.2. Definitions 144 None. 146 3. Problem Statement 148 To monitor (and to protect and/or manage) MPLS-TP network segments a 149 Sub-Path Maintenance Element (SPME) function has been defined in RFC 150 5921 [RFC5921]. The SPME is defined between the edges of the segment 151 of a transport path that needs to be monitored, protected, or 152 managed. SPME is created by stacking the shim header (MPLS header) 153 according to RFC 3031 [RFC3031] and it is defined as the segment 154 where the header is stacked. OAM messages can be initiated at the 155 edge of the SPME and sent to the peer edge of the SPME or to a MIP 156 along the SPME by setting the TTL value of the label stack entry 157 (LSE) and interface identifier value at the corresponding 158 hierarchical LSP level in case of a per-node model. 160 MPLS-TP segment monitoring must satisfy two network objectives 161 according to section 3.8 of RFC 6371 [RFC6371]: 163 (N1) The monitoring and maintenance of current transport paths has 164 to be conducted in-service without traffic disruption. 166 (N2) Segment monitoring must not modify the forwarding of the 167 segment portion of the transport path. 169 The SPME function that has been defined in RFC 5921 [RFC5921] has 170 the following drawbacks: 172 (P1) It increases network management complexity, because a new 173 sublayer and new MEPs and MIPs have to be configured for the SPME. 175 (P2) Original conditions of the path are changed. 177 (P3) The client traffic over a transport path is disrupted if the 178 SPME is configured on-demand. 180 Problem (P1) is related to the management of each additional sub- 181 layer required for segment monitoring in a MPLS-TP network. When an 182 SPME is applied to administer on-demand OAM functions in MPLS-TP 183 networks, a rule for operationally differentiating those SPME will be 184 required at least within an administrative domain. This forces 185 operators to implement at least an additional layer into the 186 management systems that will only be used for on-demand path segment 187 monitoring. From the perspective of operation, increasing the number 188 of managed layers and managed addresses/identifiers is not desirable 189 in view of keeping the management systems as simple as possible. 191 Moreover, using the currently defined methods, on-demand setting of 192 SPMEs causes problems (P2) and (P3) due to additional label stacking. 194 Problem (P2) arises from the fact that MPLS exposed label value and 195 MPLS frames length changes. The monitoring function should monitor 196 the status without changing any conditions of the targeted, to be 197 monitored, segment or transport path. Changing the settings of the 198 original shim header should not be allowed because this change 199 corresponds to creating a new segment of the original transport path 200 that differs from the original one. When the conditions of the path 201 change, the measured values or observed data will also change and 202 this may make the monitoring meaningless because the result of the 203 measurement would no longer reflect the performance of the connection 204 where the original fault or degradation occurred. As an example, 205 setting up an on-demand SPME will result in the LSRs within the 206 monitoring segment only looking at the added (stacked) labels and not 207 at the labels of the original LSP. This means that problems stemming 208 from incorrect (or unexpected) treatment of labels of the original 209 LSP by the nodes within the monitored segment cannot be identified 210 when setting up SPME. This might include hardware problems during 211 label look-up, mis-configuration, etc. Therefore operators have to 212 pay extra attention to correctly setting and checking the label 213 values of the original LSP in the configuration. Of course, the 214 reverse of this situation is also possible, e.g., an incorrect or 215 unexpected treatment of SPME labels can result in false detection of 216 a fault where no problem existed originally. 218 Figure 1 shows an example of SPME settings. In the figure, "X" is 219 the label value of the original path expected at the tail-end of node 220 D. "210" and "220" are label values allocated for SPME. The label 221 values of the original path are modified as well as the values of the 222 stacked labels. As shown in Figure 1, SPME changes both the length 223 of MPLS frames and the label value(s). This means that it is no 224 longer monitoring the original path but it is monitoring a different 225 path. In particular, performance monitoring measurements (e.g. 226 Delay Measurement and Packet Loss Measurement) are sensitive to these 227 changes. 229 (Before SPME settings) 230 --- --- --- --- --- 231 | | | | | | | | | | 232 | | | | | | | | | | 233 --- --- --- --- --- 234 A--100--B--110--C--120--D--130--E <= transport path 235 MEP MEP 237 (After SPME settings) 238 --- --- --- --- --- 239 | | | | | | | | | | 240 | | | | | | | | | | 241 --- --- --- --- --- 242 A--100--B-----------X---D--130--E <= transport path 243 MEP \ / MEP 244 --210--C--220-- <= SPME 245 MEP' MEP' 247 Figure 1: SPME settings example 249 Problem (P3) can be avoided if the operator sets SPMEs in advance and 250 maintains them until the end of life of a transport path. But this 251 does not support on-demand. Furthermore SMPEs cannot be set 252 arbitrarily because overlapping of path segments is limited to 253 nesting relationships. As a result, possible SPME configurations of 254 segments of an original transport path are limited due to the 255 characteristic of the SPME shown in Figure 1, even if SPMEs are pre- 256 configured. 258 Although the make-before-break procedure in the survivability 259 document RFC 6372 [RFC6372] supports configuration for monitoring 260 according to the framework document RFC 5921 [RFC5921], without 261 traffic distruption, the configuration of an SPME is not possible 262 without violating network objective (N2). These concerns are 263 described in section 3.8 of RFC 6371 [RFC6371]. 265 Additionally, the make-before-break approach tipically relies on a 266 control plane and requires additional functionalities for a 267 management system to properly support SPME creation and traffic 268 switching from the original transport path to the SPME. 270 As an example, the old and new transport resources (e.g. LSP 271 tunnels) might compete with each other for resources which they have 272 in common. Depending on availability of resources, this competition 273 can cause admission control to prevent the new LSP tunnel from being 274 established as this bandwidth accounting deviates from traditional 275 (non control plane) management system operation. While SPMEs can be 276 applied in any network context (single domain, multi domain, single 277 carrier, multi carrier, etc.), the main applications are in inter- 278 carrier or inter-domain segment monitoring where they are typically 279 pre- configured or pre-instantiated. SPME instantiates a 280 hierarchical path (introducing MPLS label stacking) through which OAM 281 packets can be sent. The SPME monitoring function is also mainly 282 important for protecting bundles of transport paths and carriers' 283 carrier solutions within an administrative domain. 285 The analogy for SPME in other transport technologies is Tandem 286 Connection Monitoring (TCM), used in Optical Transport Networks (OTN) 287 and Ethernet transport networks, which supports on-demand but does 288 not affect the path. TCM allows the insertion and removal of 289 performance monitoring overhead within the frame at intermediate 290 points in the network. It is done such that their insertion and 291 removal do not change the conditions of the path. Though as the OAM 292 overhead is part of the frame (designated overhead bytes), it is 293 constrained to a pre-defined number of monitoring segments. 295 To summarize: the problem statement is that the current sub-path 296 maintenance based on a hierarchical LSP (SPME) is problematic for 297 pre-configuration in terms of increasing the number of managed 298 objects by layer stacking and identifiers/addresses. An on-demand 299 configuration of SPME is one of the possible approaches for 300 minimizing the impact of these issues. However, the current 301 procedure is unfavourable because the on-demand configuration for 302 monitoring changes the condition of the original monitored path. To 303 avoid or minimize the impact of the drawbacks discussed above, a more 304 efficient approach is required for the operation of an MPLS-TP 305 transport network. A monitoring mechanism, named Hitless Path 306 Segment Monitoring (HPSM), supporting on-demand path segment 307 monitoring without traffic disruption is needed. 309 4. Requirements for hitless segment monitoring 311 In the following sections, mandatory (M) and optional (O) 312 requirements for the hitless segment monitoring function are listed. 314 4.1. Backward compatibility 316 HPSM is an additional OAM tool that does not replace SPME. As such: 318 (M1) HSPM MUST be compatible with the usage of SPME 320 (M2) HSPM SHOULD be applicable at the SPME layer too 322 (M3) HSPM 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 (M4) 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 (M5) HPSM MUST support on-demand provisioning and 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 (M6) 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: Multi-level on-demand segment monitoring example 355 4.4. Single and multiple level monitoring 357 The new hitless segment monitoring function will be applied mainly 358 for on-demand diagnostic purposes. With the current defined 359 approach, the most serious problem is that there is no way to locate 360 the degraded segment of a path without changing the conditions of the 361 original path. Therefore, as a first step, a single level, single 362 segment monitoring, not affecting the monitored path, is required for 363 a new on-demand segment monitoring function without traffic 364 disruption. A combination of multi-level and simultaneous segments 365 monitoring is the most powerful tool for accurately diagnosing the 366 performance of a transport path. However, in the field, a single 367 level, multiple segments approach will be less complex for management 368 and operations. 370 (M7) HPSM MUST support single-level segment monitoring 372 (O1) HPSM MAY support multi-level segment monitoring. 374 Figure 3 shows an example of multi-level on-demand segment 375 monitoring. 377 --- --- --- --- --- 378 | | | | | | | | | | 379 | A | | B | | C | | D | | E | 380 --- --- --- --- --- 381 MEP MEP <= ME of a transport path 382 *-----------------* <=On-demand HPSM level 1 383 *-------------* <=On-demand HPSM level 2 384 *-* <=On-demand HPSM level 3 386 Figure 3: Multi-level on-demand segment monitoring example 388 4.5. HPSM and end-to-end proactive monitoring independence 390 There is a need for simultaneously using existing end-to-end 391 proactive monitoring and on-demand path segment monitoring. 392 Normally, the on-demand path segment monitoring is configured on a 393 segment of a maintenance entity of a transport path. In such an 394 environment, on-demand single-level monitoring should be performed 395 without disrupting the pro-active monitoring of the targeted end-to- 396 end transport path to avoid affecting user traffic performance 397 monitoring. 399 (M8) HPSM MUST support the capability to be concurrently and 400 independently operated of the OAM function operated on the end-to- 401 end path 403 --- --- --- --- --- 404 | | | | | | | | | | 405 | A | | B | | C | | D | | E | 406 --- --- --- --- --- 407 MEP MEP <= ME of a transport path 408 +-----------------------------+ <= Pro-active end-to-end mon. 409 *------------------* <= On-demand HPSM 411 Figure 4: Independency between proactive end-to-end monitoring and 412 on-demand segment monitoring 414 4.6. Arbitrary segment monitoring 416 The main objective for on-demand segment monitoring is to diagnose 417 the fault locations. A possible realistic diagnostic procedure is to 418 fix one end point of a segment at the MEP of the transport path under 419 observation and change progressively the length of the segments. 420 This example is shown in Figure 5. 422 --- --- --- --- --- 423 | | | | | | | | | | 424 | A | | B | | C | | D | | E | 425 --- --- --- --- --- 426 MEP MEP <= ME of a transport path 427 +-----------------------------+ <= Pro-active end-to-end mon. 428 *-----* <= 1st on-demand HPSM 429 *-------* <= 2nd on-demand HPSM 430 | | 431 | | 432 *-----------------------* <= 4th on-demand HPSM 433 *-----------------------------* <= 5th on-demand HPSM 435 Figure 5: Localization of a defect by consecutive on-demand segment 436 monitoring procedure 438 Another possible scenario is depicted in Figure 6. In this case, the 439 operator wants to diagnose a transport path starting at a transit 440 node, because the end nodes (A and E) are located at customer sites 441 and consist of cost effective small boxes supporting only a subset of 442 OAM functions. In this case, where the source entities of the 443 diagnostic packets are limited to the position of MEPs, on-demand 444 segment monitoring will be ineffective because not all the segments 445 can be diagnosed (e.g. segment monitoring HPSM 3 in Figure 6 is not 446 available and it is not possible to determine the fault location 447 exactly). 449 (M9) It SHALL be possible to provision HPSM on an arbitrary 450 segment of a transport path and diagnostic packets should be 451 inserted/terminated at any of intermediate maintenance points of 452 the original ME. 454 --- --- --- 455 --- | | | | | | --- 456 | A | | B | | C | | D | | E | 457 --- --- --- --- --- 458 MEP MEP <= ME of a transport path 459 +-----------------------------+ <= Pro-active end-to-end mon. 460 *-----* <= On-demand HPSM 1 461 *-----------------------* <= On-demand HPSM 2 462 *---------* <= On-demand HPSM 3 464 Figure 6: HSPM configuration at arbitrary segments 466 4.7. Fault while HPSM is operational 468 Node or link failures may occur while HPSM is active. In this case, 469 if no resiliency mechanism is set-up on the subtended transport path, 470 there is no particular requirement for the HPSM function. If the 471 transport path is protected, the HPSM function should be terminated 472 to avoid monitoring a new segment when a protection or restoration 473 path is active. 475 (M10) The HPSM functions SHOULD avoid monitoring an unintended 476 segment when one or more failures occur 478 The following examples are provided for clarification only and they 479 are not intended to restrict any solution for meeting the 480 requirements of HPSM. 482 Protection scenario A is shown in figure 7. In this scenario a 483 working LSP and a protection LSP are set-up. HPSM is activated 484 between nodes A and E. When a fault occurs between nodes B and C, 485 the operation of HPSM is not affected by the protection switch and 486 continues on the active LSP path. As a result requirement (M10) is 487 satisfied. 489 A - B - C - D - E - F 490 \ / 491 G - H - I - L 493 Where: 494 - end-to-end LSP: A-B-C-D-E-F 495 - working LSP: A-B-C-D-E-F 496 - protection LSP: A-G-H-I-L-F 497 - EPSM: A-E 499 Figure 7: Protection scenario A 501 Protection scenario B is shown in figure 8. The difference with 502 scenario A is that only a portion of the transport path is protected. 503 In this case, when a fault occurs between nodes B and C on the 504 working sub-path B-C-D, traffic will be switched to protection sub- 505 path B-G-H-D. Assuming that OAM packet termination depends only on 506 the TTL value of the MPLS label header, the target node of the HPSM 507 changes from E to D due to the difference of hop counts between the 508 working path route (A-B-C-D-E: 4 hops) and protection path route 509 (A-B-G-H-D-E: 5 hops). As a result requirement (M10) is not 510 satisfied. 512 A - B - C - D - E - F 513 \ / 514 G - H 516 - end-to-end LSP: A-B-C-D-E-F 517 - working sub-path: B-C-D 518 - protection sub-path: B-G-H-D 519 - EPSM: A-E 521 Figure 8: Protection scenario B 523 4.8. HPSM Manageability 525 From managing perspective, increasing the number of managed layers 526 and managed addresses/identifiers is not desirable in view of keeping 527 the management systems as simple as possible. 529 (M11)HPSM SHOULD NOT be based on additional transport layers (e.g. 530 hierarchical LSPs) 532 (M12) The same identifiers used for MIPs and/or MEPs SHOULD be 533 applied to HPSM maintenance points when they coincide. Anyway 534 maintenance points for the HPSM do not necessarily have to 535 coincide with MIPs and MEPs functional components as defined in 536 the OAM framework document RFC 6371 [RFC6371]. 538 4.9. Supported OAM functions 540 An intermediate maintenance point supporting the HPSM function has to 541 be able to generate and inject OAM packets. OAM functions that may 542 be applicable for on-demand HPSM are basically the on-demand 543 performance monitoring functions which are defined in the OAM 544 framework document RFC 6371 [RFC6371]. The "on-demand" attribute is 545 typically temporary for maintenance operation. 547 (M13) HPSM MUST support Packet Loss and Packet Delay measurement. 549 That because these functions are normally only supported at the end 550 points of a transport path. If a defect occurs, it might be quite 551 hard to locate the defect or degradation point without using the 552 segment monitoring function. If an operator cannot locate or narrow 553 down the cause of the fault, it is quite difficult to take prompt 554 actions to solve the problem. 556 Other on-demand monitoring functions (e.g. Delay Variation 557 measurement) are desirable but not as necessary as the functions 558 mentioned above. 560 (O2) HPSM MAY support Packet Delay variation, Throughput 561 measurement and other performance monitoring and fault management 562 functions. 564 Support of out-of-service on-demand performance management functions 565 (e.g. Throughput measurement) is not required for HPSM. 567 5. Summary 569 A new hitless path segment monitoring (HPSM) mechanism is required to 570 provide on-demand segment monitoring without traffic disruption. It 571 shall meet the two network objectives described in section 3.8 of RFC 572 6371 [RFC6371] and summarized in Section 3 of this document. 574 The mechanism should minimize the problems described in Section 3, 575 i.e. (P1), (P2) and (P3). 577 The solution for the on-demand segment monitoring without traffic 578 disruption needs to cover both the per-node model and the per- 579 interface model specified in RFC 6371 [RFC6371]. 581 The on-demand segment monitoring without traffic disruption solution 582 needs to support on-demand Packet Loss Measurement and Packet Delay 583 Measurement functions and optionally other performance monitoring and 584 fault management functions (e.g. Throughput measurement, Packet 585 Delay variation measurement, Diagnostic test, etc.). 587 6. Security Considerations 589 The security considerations defined for MPLS Transport Profile 590 Framework in RFC 5921 [RFC5921] apply to this document as well. The 591 document provides the requirements for a new construct for 592 performance monitoring that will make use of existing OAM tools that 593 follow the security considerations provided in OAM Requirements for 594 MPLS-TP in RFC5860 [RFC5860]. 596 7. IANA Considerations 598 There are no requests for IANA actions in this document. 600 Note to the RFC Editor - this section can be removed before 601 publication. 603 8. Contributors 605 Manuel Paul 607 Deutsche Telekom AG 609 Email: manuel.paul@telekom.de 611 9. Acknowledgements 613 The authors would also like to thank Alexander Vainshtein, Dave 614 Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, 615 Maarten Vissers, Jia He and Nurit Sprecher for their comments and 616 enhancements to the text. 618 10. References 620 10.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 628 Label Switching Architecture", RFC 3031, 629 DOI 10.17487/RFC3031, January 2001, 630 . 632 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 633 "Requirements for Operations, Administration, and 634 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 635 DOI 10.17487/RFC5860, May 2010, 636 . 638 10.2. Informative References 640 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 641 L., and L. Berger, "A Framework for MPLS in Transport 642 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 643 . 645 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 646 Administration, and Maintenance Framework for MPLS-Based 647 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 648 September 2011, . 650 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 651 Profile (MPLS-TP) Survivability Framework", RFC 6372, 652 DOI 10.17487/RFC6372, September 2011, 653 . 655 Authors' Addresses 657 Alessandro D'Alessandro 658 Telecom Italia 659 Via Reiss Romoli, 274 660 Torino 10148 661 Italy 663 Email: alessandro.dalessandro@telecomitalia.it 665 Loa Andersson 666 Huawei Technologies 668 Email: loa@mail01.huawei.com 669 Satoshi Ueno 670 NTT Communications 672 Email: satoshi.ueno@ntt.com 674 Kaoru Arai 675 NTT 677 Email: arai.kaoru@lab.ntt.co.jp 679 Yoshinori Koike 680 NTT 682 Email: y.koike@vcd.nttbiz.com