idnits 2.17.1 draft-ietf-mpls-tp-temporal-hitless-psm-08.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 (December 2, 2015) is 3061 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5921 ** Downref: Normative reference to an Informational RFC: RFC 6371 ** Downref: Normative reference to an Informational RFC: RFC 6372 Summary: 3 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: Standards Track L. Andersson 5 Expires: June 4, 2016 Huawei Technologies 6 M. Paul 7 Deutsche Telekom 8 S. Ueno 9 NTT Communications 10 K. Arai 11 Y. Koike 12 NTT 13 December 2, 2015 15 Enhanced path segment monitoring 16 draft-ietf-mpls-tp-temporal-hitless-psm-08.txt 18 Abstract 20 The MPLS transport profile (MPLS-TP) has been standardized to enable 21 carrier-grade packet transport and to complement converged packet 22 network deployments. The most attractive features of MPLS-TP are the 23 OAM functions. These functions enable maintenance tools that may be 24 exploited by network operators and service providers for fault 25 location, survivability, performance monitoring, in-service and out- 26 of-service measurements. 28 One of the most important mechanisms that is common for transport 29 network operation is fault localisation. A segment monitoring 30 function of a transport path is effective in terms of extension of 31 the maintenance work and indispensable, particularly when the OAM 32 function is activated only between end points. However, the current 33 approach defined for MPLS-TP of segment monitoring has some 34 drawbacks. This document elaborates on the problem statement for the 35 Sub-path Maintenance Elements (SPMEs) which provide monitoring of a 36 segment of a set of transport paths (LSPs or MS-PWs). Based on the 37 identified problems, this document provides considerations for the 38 specification of new requirements to consider a new improved 39 mechanism for hitless transport path segment monitoring to be named 40 Enhanced Path Segment Monitoring (EPSM). 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on June 4, 2016. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions used in this document . . . . . . . . . . . . . . 3 78 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 79 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Network objectives for segment monitoring . . . . . . . . . . 4 81 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 82 5. OAM functions supported in segment monitoring . . . . . . . . 8 83 6. Requirements for enhanced segment monitoring . . . . . . . . 9 84 6.1. Non-intrusive segment monitoring . . . . . . . . . . . . 9 85 6.2. Single and multiple level monitoring . . . . . . . . . . 9 86 6.3. EPSM and end-to-end proactive monitoring independence . . 10 87 6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 11 88 6.5. Fault while EPSM is operational . . . . . . . . . . . . . 12 89 6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13 90 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 94 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 A packet transport network enables carriers and service providers to 100 use network resources efficiently. It reduces operational complexity 101 and provides carrier-grade network operation. Appropriate 102 maintenance functions that support fault location, survivability, 103 pro-active performance monitoring, pre-service and in-service 104 measurements, are essential to ensure the quality of service and the 105 reliability of a network. They are essential in transport networks 106 and have evolved along with PDH, ATM, SDH and OTN. 108 Similar to legacy technologies, MPLS-TP does also not scale when an 109 arbitrary number of OAM functions is enabled. 111 According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], 112 mechanisms MUST be available for alerting a service provider of a 113 fault or defect that affects their services. In addition, to ensure 114 that faults or service degradation can be localized, operators need a 115 function to diagnose the detected problem. Using end-to-end 116 monitoring for this purpose is insufficient. In fact by using end- 117 to-end OAM monitoring, an operator will not be able to localize a 118 fault or service degradation accurately. 120 Thus, a dedicated segment monitoring function that can focus on a 121 specific segment of a transport path and can provide a detailed 122 analysis is indispensable to promptly and accurately localize the 123 fault. 125 For MPLS-TP, a path segment monitoring function has been defined to 126 perform this task. However, as noted in the MPLS-TP OAM Framework 127 RFC 6371 [RFC6371], the current method for segment monitoring of a 128 transport path has implications that hinder the usage in an operator 129 network. 131 This document elaborates on the problem statement for the path 132 segment monitoring function and proposes to consider a new improved 133 method for segment monitoring, following up the description in RFC 134 6371 [RFC6371]. This document also provides additional detailed 135 requirements for a new temporary and hitless segment monitoring 136 function which is not covered in RFC 6371 [RFC6371]. 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2.1. Terminology 146 ATM - Asynchronous Transfer Mode 148 EPSM - Enhanced Path Segment Monitoring 150 LSP - Label Switched Path 152 LSR - Label Switching Router 154 ME - Maintenance Entity 156 MEG - Maintenance Entity Group 158 MEP - Maintenance Entity Group End Point 160 MIP - Maintenance Entity Group Intermediate Point 162 OTN - Optical Transport Network 164 PDH - Plesiochronous Digital Hierarchy 166 PST - Path Segment Tunnel 168 TCM - Tandem connection monitoring 170 SDH - Synchronous Digital Hierarchy 172 SPME - Sub-path Maintenance Element 174 2.2. Definitions 176 None. 178 3. Network objectives for segment monitoring 180 There are two network objectives for MPLS-TP segment monitoring 181 described in section 3.8 of RFC 6371 [RFC6371]: 183 1. The monitoring and maintenance of current transport paths has to 184 be conducted in-service without traffic disruption. 186 2. Segment monitoring must not modify the forwarding of the segment 187 portion of the transport path. 189 4. Problem Statement 191 The Sub-Path Maintenance Element (SPME) function is defined in RFC 192 5921 [RFC5921]. It is used to monitor, protect, and/or manage 193 segments of transport paths, such as LSPs in MPLS-TP networks. The 194 SPME is defined between the edges of the segment of a transport path 195 that needs to be monitored, protected, or managed. This SPME is 196 created by stacking the shim header (MPLS header) according to RFC 197 3031 [RFC3031] and is defined as the segment where the header is 198 stacked. OAM messages can be initiated at the edge of the SPME and 199 sent to the peer edge of the SPME or to a MIP along the SPME by 200 setting the TTL value of the label stack entry (LSE) and interface 201 identifier value at the corresponding hierarchical LSP level in case 202 of a per-node model. 204 This method has the following drawbacks that impact the operation 205 costs: 207 (P-1) It lowers the bandwidth efficiency. 209 (P-2) It increases network management complexity, because a new 210 sublayer and new MEPs and MIPs have to be configured for the SPME. 212 Problem (P-1) is caused by the shim headers stacking that increases 213 the overhead. 215 Problem (P-2) is related to an identifier management issue. In the 216 case of label stacking the identification of each sub-layer is 217 required for segment monitoring in a MPLS-TP network. When SPME is 218 applied for on-demand OAM functions in MPLS-TP networks in a similar 219 manner as Tandem Connection Monitoring (TCM) in the Optical Transport 220 Networks (OTN) and Ethernet transport networks, a rule for 221 operationally differentiating those SPME/TCMs will be required; at 222 least within an administrative domain. This forces operators to 223 create an additional permanent layer identification policy that will 224 only be used for temporary path segment monitoring. Additionally, 225 from the perspective of operation, increasing the number of managed 226 addresses and managed layers is not desirable in view of keeping the 227 transport networks as simple as possible. Reducing the number of 228 managed identifiers and managed sub-layers should be the fundamental 229 objective in designing the architecture. 231 The analogy for SPME in legacy transport networks is TCM, which is 232 on-demand and does not affect the transport path. 234 Also, using the currently defined methods, temporary setting of SPMEs 235 causes the following problems due to additional label stacking: 237 (P-3) The original condition of the transport path is affected by 238 changing the length of MPLS frames and changing the value of 239 exposed label. 241 (P-4) The client traffic over a transport path is disrupted when 242 the SPME is configured on-demand. 244 Problem (P-3) impacts network objective (2) in Section 3. The 245 monitoring function should monitor the status without changing any 246 conditions of the targeted, to be monitored, segment or transport 247 path. Changing the settings of the original shim header should not 248 be allowed because this change corresponds to creating a new segment 249 of the original transport path. And this differs from the original 250 data plane conditions. When the conditions of the transport path 251 change, the measured values or observed data will also change and 252 this may make the monitoring meaningless because the result of the 253 measurement would no longer reflect the performance of the connection 254 where the original fault or degradation occurred. 256 Figure 1 shows an example of SPME settings. In the figure, "X" is 257 the label value of the original transport path expected at the tail- 258 end of node D. "210" and "220" are label values allocated for SPME. 259 The label values of the original path are modified as well as the 260 values of the stacked labels. As shown in Figure 1, SPME changes 261 both the length of MPLS frames and the label value(s). This means 262 that it is no longer monitoring the original transport path but it is 263 monitoring a different path. In particular, performance monitoring 264 measurements (e.g. Delay Measurement and Packet Loss Measurement) 265 are sensitive to these changes. 267 (Before SPME settings) 268 --- --- --- --- --- 269 | | | | | | | | | | 270 | | | | | | | | | | 271 --- --- --- --- --- 272 A--100--B--110--C--120--D--130--E <= transport path 273 MEP MEP 275 (After SPME settings) 276 --- --- --- --- --- 277 | | | | | | | | | | 278 | | | | | | | | | | 279 --- --- --- --- --- 280 A--100--B-----------X---D--130--E <= transport path 281 MEP \ / MEP 282 --210--C--220-- <= SPME 283 MEP' MEP' 285 Figure 1: An Example of a SPME settings 287 Problem (P-4) can be avoided if the operator sets SPMEs in advance 288 and maintains it until the end of life of a transport path, which is 289 neither temporary nor on-demand. Furthermore SMPEs cannot be set 290 arbitrarily because overlapping of path segments is limited to 291 nesting relationships. As a result, possible SPME configurations of 292 segments of an original transport path are limited due to the 293 characteristic of SPME shown in Figure 1, even if SPMEs are pre- 294 configured. 296 Although the make-before-break procedure in the survivability 297 document RFC 6372 [RFC6372] seemingly supports the hitless 298 configuration for monitoring according to the framework document RFC 299 5921 [RFC5921], the reality is that configuration of an SPME is 300 impossible without violating network objective (2) in Section 3. 301 These concerns are described in section 3.8 of RFC 6371 [RFC6371]. 303 Additionally, the make-before-break approach might not be usable in 304 the static model without a control plane. This is because the make- 305 before-break is a restoration function based on a control plane. 306 Consequently the management systems should support SPME creation and 307 coordinated traffic switching from original transport path to the 308 SPME. 310 Other potential risks are also envisaged. Setting up a temporary 311 SPME will result in the LSRs within the monitoring segment only 312 looking at the added (stacked) labels and not at the labels of the 313 original LSP. This means that problems stemming from incorrect (or 314 unexpected) treatment of labels of the original LSP by the nodes 315 within the monitored segment can not be identified when setting up 316 SPME. This might include hardware problems during label look-up, 317 mis-configuration, etc. Therefore operators have to pay extra 318 attention to correctly setting and checking the label values of the 319 original LSP in the configuration. Of course, the reverse of this 320 situation is also possible, e.g., an incorrect or unexpected 321 treatment of SPME labels can result in false detection of a fault 322 where no problem existed originally. 324 The utilisation of SPMEs is basically limited to inter-carrier or 325 inter-domain segment monitoring where they are typically pre- 326 configured or pre-instantiated. SPME instantiates a hierarchical 327 transport path (introducing MPLS label stacking) through which OAM 328 packets can be sent. The SPME monitoring function is mainly 329 important for protecting bundles of transport paths and carriers' 330 carrier solutions within one administrative domain. 332 To summarize: the problem statement is that the current sub-path 333 maintenance based on a hierarchical LSP (SPME) is problematic for 334 pre-configuration in terms of increasing the bandwidth by label 335 stacking and increasing the number of managing objects by layer 336 stacking and address management. An on-demand/temporary 337 configuration of SPME is one of the possible approaches for 338 minimizing the impact of these issues. However, the current 339 procedure is unfavorable because the temporary configuration for 340 monitoring can change the condition of the original monitored 341 transport path. To avoid or minimize the impact of the drawbacks 342 discussed above, a more efficient approach is required for the 343 operation of an MPLS-TP transport network. A monitoring mechanism, 344 named on-demand Enhanced Path Segment Monitoring (EPSM), supporting 345 temporary and hitless path segment monitoring is proposed. 347 5. OAM functions supported in segment monitoring 349 OAM functions that may usefully be exploited across on-demand EPSM 350 are basically the on-demand performance monitoring functions which 351 are defined in OAM framework document RFC 6371 [RFC6371]. Segment 352 performance monitoring is used to verify the performance and hence 353 the status of transport path segments. The "on-demand" attribute is 354 generally temporary for maintenance operation. 356 Packet Loss and Packet Delay measurement are OAM functions strongly 357 required in hitless and temporary segment monitoring because these 358 functions are normally only supported at the end points of a 359 transport path. If a defect occurs, it might be quite hard to locate 360 the defect or degradation point without using the segment monitoring 361 function. If an operator cannot locate or narrow down the cause of 362 the fault, it is quite difficult to take prompt actions to solve the 363 problem. 365 Other on-demand monitoring functions, (e.g. Delay Variation 366 measurement) are desirable but not as necessary as the functions 367 mentioned above. 369 Regarding out-of-service on-demand performance management functions 370 (e.g. Throughput measurement) there seems no need for EPSM. 371 However, OAM functions specifically designed for segment monitoring 372 should be developed to satisfy network objective (2) described in 373 Section 3. 375 Finally, the solution for EPSM has to cover both the per-node model 376 and the per-interface model as specified in RFC 6371 [RFC6371]. 378 6. Requirements for enhanced segment monitoring 380 In the following sections, mandatory (M) and optional (O) 381 requirements for the enhanced segment monitoring function are listed. 383 6.1. Non-intrusive segment monitoring 385 One of the major problems of legacy SPME highlighted in section 4 is 386 that it may not monitor the original transport path and it could 387 distrupt service traffic when set-up on demand. 389 (M1) EPSM must not change the original condition of transport path 390 (e.g. must not change the length of MPLS frames, the exposed 391 label values, etc.) 393 (M2) EPSM must be provisioned on-demand without traffic 394 disruption. 396 6.2. Single and multiple level monitoring 398 The new enhanced segment monitoring function is supposed to be 399 applied mainly for on-demand diagnostic purposes. We can 400 differentiate this monitoring from the existing proactive segment 401 monitoring by referring to is as on-demand multi-level monitoring. 402 Currently the most serious problem is that there is no way to locate 403 the degraded segment of a path without changing the conditions of the 404 original path. Therefore, as a first step, single layer segment 405 monitoring, not affecting the monitored path, is required for a new 406 on-demand and hitless segment monitoring function. A combination of 407 multi-level and simultaneous segment monitoring is the most powerful 408 tool for accurately diagnosing the performance of a transport path. 409 However, in the field, a single level approach may be enough. 411 (M3) Single-level segment monitoring is required 413 (O1) Multi-level segment monitoring is desirable 415 Figure 2 shows an example of multi-level on-demand segment 416 monitoring. 418 --- --- --- --- --- 419 | | | | | | | | | | 420 | A | | B | | C | | D | | E | 421 --- --- --- --- --- 422 MEP MEP <= ME of a transport path 423 *-----------------* <=On-demand segm. mon. level 1 424 *-------------* <=On-demand segm. mon. level 2 425 *-* <=On-demand segm. mon. level 3 427 Figure 2: Example of multi-level on-demand segment monitoring 429 6.3. EPSM and end-to-end proactive monitoring independence 431 The need for simultaneously using existing end-to-end proactive 432 monitoring and the enhanced on-demand path segment monitoring is 433 considered. Normally, the on-demand path segment monitoring is 434 configured on a segment of a maintenance entity of a transport path. 435 In such an environment, on-demand single-level monitoring should be 436 performed without disrupting the pro-active monitoring of the 437 targeted end-to-end transport path to avoid affecting user traffic 438 performance monitoring. 440 Therefore: 442 (M4) EPSM shall be configured without changing or interfering with 443 the already in place end-to-end pro-active monitoring of the 444 transport path. 446 --- --- --- --- --- 447 | | | | | | | | | | 448 | A | | B | | C | | D | | E | 449 --- --- --- --- --- 450 MEP MEP <= ME of a transport path 451 +-----------------------------+ <= Pro-active end-to-end mon. 452 *------------------* <= On-demand segment mon. 454 Figure 3: Independency between proactive end-to-end monitoring and 455 on-demand segment monitoring 457 6.4. Arbitrary segment monitoring 459 The main objective for enhanced on-demand segment monitoring is to 460 diagnose the fault locations. A possible realistic diagnostic 461 procedure is to fix one end point of a segment at the MEP of the 462 transport path under observation and change progressively the length 463 of the segments. This example is shown in Figure 4. 465 --- --- --- --- --- 466 | | | | | | | | | | 467 | A | | B | | C | | D | | E | 468 --- --- --- --- --- 469 MEP MEP <= ME of a transport path 470 +-----------------------------+ <= Pro-active end-to-end mon. 471 *-----* <= 1st on-demand segment mon. 472 *-------* <= 2nd on-demand segment mon. 473 *------------* <= 3rd on-demand segment mon. 474 | | 475 | | 476 *-----------------------* <= 6th on-demand segment mon. 477 *-----------------------------* <= 7th on-demand segment mon. 479 Figure 4: A procedure to localize a defect by consecutive on-demand 480 segment monitoring 482 Another possible scenario is depicted in Figure 5. In this case, the 483 operator wants to diagnose a transport path starting at a transit 484 node, because the end nodes(A and E) are located at customer sites 485 and consist of cost effective small boxes supporting only a subset of 486 OAM functions. In this case, where the source entities of the 487 diagnostic packets are limited to the position of MEPs, on-demand 488 segment monitoring will be ineffective because not all the segments 489 can be diagnosed (e.g. segment monitoring 3 in Figure 5 is not 490 available and it is not possible to determine the fault location 491 exactly). 493 Therefore: 495 (M5) it shall be possible to provision EPSM on an arbitrary 496 segment of a transport path and diagnostic packets should be 497 inserted/terminated at any of intermediate maintenance points of 498 the original ME. 500 --- --- --- 501 --- | | | | | | --- 502 | A | | B | | C | | D | | E | 503 --- --- --- --- --- 504 MEP MEP <= ME of a transport path 505 +-----------------------------+ <= Pro-active end-to-end mon. 506 *-----* <= On-demand segment mon. 1 507 *-----------------------* <= On-demand segment mon. 2 508 *---------* <= On-demand segment mon. 3 510 Figure 5: ESPM configured at arbitrary segments 512 6.5. Fault while EPSM is operational 514 Node or link failures may occur while EPSM is active. In this case, 515 if no resiliency mechanism is set-up on the subtended transport path, 516 there is no particular requirement for the EPSM function. If the 517 transport path is protected, the EPSM function should be terminated 518 to avoid monitoring a new segment when a protection or restoration 519 path is active. 521 Therefore: 523 (M6) the EPSM function should avoid monitoring an unintended 524 segment when one or more failures occur 526 The following examples are provided for clarification only and they 527 are not intended to restrict any solution for meeting the 528 requirements of EPSM. 530 Protection scenario A is shown in figure 6. In this scenario a 531 working LSP and a protection LSP are set-up. EPSM is activated 532 between nodes A and E. When a fault occurs between nodes B and C, 533 the operation of EPSM is not affected by the protection switch and 534 continues on the active LSP path. As a result requirement (M6) is 535 satisfied. 537 A - B - C - D - E - F 538 \ / 539 G - H - I - L 541 Where: 542 - end-to-end LSP: A-B-C-D-E-F 543 - working LSP: A-B-C-D-E-F 544 - protection LSP: A-B-G-H-I-L-F 545 - EPSM: A-E 547 Figure 6: Protection scenario A 549 Protection scenario B is shown in figure 7. The difference with 550 scenario A is that only a portion of the transport path is protected. 551 In this case, when a fault occurs between nodes B and C on the 552 working sub-path B-C-D, traffic will be switched to protection sub- 553 path B-G-H-D. Assuming that OAM packet termination depends only on 554 the TTL value of the MPLS label header, the target node of the EPSM 555 changes from E to D due to the difference of hop counts between the 556 working path route (A-B-C-D-E: 4 hops) and protection path route 557 (A-B-G-H-D-E: 5 hops). As a result requirement (M6) is not 558 satisfied. 560 A - B - C - D - E - F 561 \ / 562 G - H 564 - end-to-end LSP: A-B-C-D-E-F 565 - working sub-path: B-C-D 566 - protection sub-path: B-G-H-D 567 - EPSM: A-E 569 Figure 7: Protection scenario B 571 6.6. EPSM maintenance points 573 An intermediate maintenance point supporting the EPSM function has to 574 be able to generate and inject OAM packets. However, maintenance 575 points for the EPSM do not necessarily have to coincide with MIPs or 576 MEPs defined in the architecture. 578 Therefore: 580 (M7) The same identifiers for MIPs and/or MEPs should be applied 581 to EPSM maintenance points 583 7. Summary 585 An enhanced path segment monitoring (EPSM) mechanism is required to 586 provide temporary and hitless segment monitoring. It shall meet the 587 two network objectives described in section 3.8 of RFC 6371 [RFC6371] 588 and repeated in Section 3 of this document. 590 The enhancements should minimize the problems described in Section 4, 591 i.e., (P-1), (P-2), (P-3) and (P-4). 593 The solution for the temporary and hitless segment monitoring has to 594 cover both the per-node model and the per-interface model specified 595 in RFC 6371 [RFC6371]. 597 The temporary and hitless segment monitoring solutions shall support 598 on-demand Packet Loss Measurement and Packet Delay Measurement 599 functions and optionally other performance monitoring and fault 600 management functions (e.g. Throughput measurement, Delay variation 601 measurement, Diagnostic test, etc.). 603 8. Security Considerations 605 The security considerations defined for RFC 6378 apply to this 606 document as well. As this is simply a re-use of RFC 6378, there are 607 no new security considerations. 609 9. IANA Considerations 611 There are no requests for IANA actions in this document. 613 Note to the RFC Editor - this section can be removed before 614 publication. 616 10. Acknowledgements 618 The author would like to thank all members (including MPLS-TP 619 steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group 620 in ITU-T) involved in the definition and specification of MPLS 621 Transport Profile. 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 11. Normative References 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 636 Label Switching Architecture", RFC 3031, 637 DOI 10.17487/RFC3031, January 2001, 638 . 640 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 641 "Requirements for Operations, Administration, and 642 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 643 DOI 10.17487/RFC5860, May 2010, 644 . 646 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 647 L., and L. Berger, "A Framework for MPLS in Transport 648 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 649 . 651 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 652 Administration, and Maintenance Framework for MPLS-Based 653 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 654 September 2011, . 656 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 657 Profile (MPLS-TP) Survivability Framework", RFC 6372, 658 DOI 10.17487/RFC6372, September 2011, 659 . 661 Authors' Addresses 663 Alessandro D'Alessandro 664 Telecom Italia 666 Email: alessandro.dalessandro@telecomitalia.it 668 Loa Andersson 669 Huawei Technologies 671 Email: loa@mail01.huawei.com 672 Manuel Paul 673 Deutsche Telekom 675 Email: Manuel.Paul@telekom.de 677 Satoshi Ueno 678 NTT Communications 680 Email: satoshi.ueno@ntt.com 682 Kaoru Arai 683 NTT 685 Email: arai.kaoru@lab.ntt.co.jp 687 Yoshinori Koike 688 NTT 690 Email: y.koike@vcd.nttbiz.com