idnits 2.17.1 draft-ietf-mpls-tp-temporal-hitless-psm-07.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 (July 20, 2015) is 3195 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: January 21, 2016 Huawei Technologies 6 M. Paul 7 Deutsche Telekom 8 S. Ueno 9 NTT Communications 10 K. Arai 11 Y. Koike 12 NTT 13 July 20, 2015 15 Enhanced path segment monitoring 16 draft-ietf-mpls-tp-temporal-hitless-psm-07.txt 18 Abstract 20 The MPLS transport profile (MPLS-TP) has been standardized to enable 21 carrier-grade packet transport and complement converged packet 22 network deployments. Among the most attractive features of MPLS-TP 23 there are OAM functions, which enable network operators or service 24 providers to provide various maintenance characteristics, such as 25 fault location, survivability, performance monitoring and in-service/ 26 out of service measurements. 28 One of the most important mechanisms which is common for transport 29 network operation is fault location. A segment monitoring function 30 of a transport path is effective in terms of extension of the 31 maintenance work and indispensable particularly when the OAM function 32 is effective only between end points. However, the current approach 33 defined for MPLS-TP for the segment monitoring (SPME) has some 34 drawbacks. This document elaborates on the problem statement for the 35 Sub-path Maintenance Elements (SPMEs) which provides monitoring of a 36 portion of a set of transport paths (LSPs or MS-PWs). Based on the 37 problems, this document specifies new requirements to consider a new 38 improved mechanism of hitless transport path segment monitoring named 39 Enhanced Path Segment Monitoring (EPSM). 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 21, 2016. 58 Copyright Notice 60 Copyright (c) 2015 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions used in this document . . . . . . . . . . . . . . 3 77 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 78 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Network objectives for segment monitoring . . . . . . . . . . 4 80 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 81 5. OAM functions supported in segment monitoring . . . . . . . . 8 82 6. Requirements for enhanced segment monitoring . . . . . . . . 8 83 6.1. Non intrusive segment monitoring . . . . . . . . . . . . 9 84 6.2. Single and multiple levels monitoring . . . . . . . . . . 9 85 6.3. EPSM and end-to-end proactive monitoring independence . . 10 86 6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 87 6.5. Fault while EPSM is in place . . . . . . . . . . . . . . 12 88 6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13 89 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 93 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 A packet transport network enables carriers or service providers to 99 use network resources efficiently, reduces operational complexity and 100 provides carrier-grade network operation. Appropriate maintenance 101 functions, supporting fault location, survivability, performance 102 monitoring and preliminary or in-service measurements, are essential 103 to ensure quality and reliability of a network. They are essential 104 in transport networks and have evolved along with TDM, ATM, SDH and 105 OTN. 107 As legacy technologies, also MPLS-TP does not scale when an arbitrary 108 number of OAM functions are enabled. 110 According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], 111 mechanisms MUST be available for alerting a service provider of a 112 fault or defect affecting services. In addition, to ensure that 113 faults or degradations can be localized, operators need a method to 114 analyze or investigate the problem being end-to-end monitoring 115 insufficient. In fact using end-to-end OAM monitoring, an operator 116 is not able to localize a fault or degrade. 118 Thus, a specific segment monitoring function for detailed analysis, 119 by selecting and focusing on a specific portion of a transport path, 120 is indispensable to promptly and accurately localize the fault. 122 For MPLS-TP, a path segment monitoring function has been defined to 123 perform this task. However, as noted in the MPLS-TP OAM Framework 124 RFC 6371 [RFC6371], the current method for segment monitoring 125 function of a transport path has implications that hinder the usage 126 in an operator network. 128 This document elaborates on the problem statement for the path 129 segment monitoring function and proposes to consider a new improved 130 method for segment monitoring, following up the work done in RFC 6371 131 [RFC6371]. Moreover, this document explains detailed requirements on 132 the new temporal and hitless segment monitoring function which are 133 not covered in RFC 6371 [RFC6371]. 135 2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2.1. Terminology 143 EPSM - Enhanced Path Segment Monitoring 145 LSP - Label Switched Path 147 LSR - Label Switching Router 149 ME - Maintenance Entity 151 MEG - Maintenance Entity Group 153 MEP - Maintenance Entity Group End Point 155 MIP - Maintenance Entity Group Intermediate Point 157 OTN - Optical Transport Network 159 PST - Path Segment Tunnel 161 TCM - Tandem connection monitoring 163 SDH - Synchronous Digital Hierarchy 165 SPME - Sub-path Maintenance Element 167 2.2. Definitions 169 None. 171 3. Network objectives for segment monitoring 173 There are two required network objectives for MPLS-TP segment 174 monitoring as described in section 3.8 of RFC 6371 [RFC6371]. 176 1. The monitoring and maintenance of current transport paths has to 177 be conducted in-service without traffic disruption. 179 2. Segment monitoring must not modify the forwarding of the segment 180 portion of the transport path. 182 4. Problem Statement 184 Sub-Path Maintenance Element (SPME) is defined in RFC 5921 [RFC5921] 185 to monitor, protect, or manage portions of transport paths, such as 186 LSPs in MPLS-TP networks. The SPME is defined between the edges of 187 the portion of the transport path that needs to be monitored, 188 protected, or managed. This SPME is created by stacking the shim 189 header (MPLS header) according to RFC 3031 [RFC3031] and is defined 190 as the segment where the header is stacked. OAM messages can be 191 initiated at the edge of the SPME and sent to the peer edge of the 192 SPME or to a MIP along the SPME by setting the TTL value of the label 193 stack entry (LSE) and interface identifier value at the corresponding 194 hierarchical LSP level in case of per-node model. 196 This method has the following drawbacks, which impact on operation 197 costs: 199 (P-1) Lowering the bandwidth efficiency by increasing the overhead 200 by shim headers stacking 202 (P-2) Increasing network management complexity, as a new sublayer 203 and new MEPs and MIPs need to be configured for the SPME 205 Problem (P-1) comes from shim headers stacking that increase the 206 overhead. 208 Problem (P-2) is related to identifiers management issue. The 209 identification of each sub-layer in case of label stacking is 210 required for the segment monitoring in a MPLS-TP network. When SPME 211 is applied for on-demand OAM functions in MPLS-TP networks in a 212 similar manner to TCM for OTN or Ethernet transport networks, a 213 possible rule of differentiating those SPME/TCMs operationally will 214 be necessary at least within an administrative domain. This enforces 215 operators to create an additional permanent layer identification 216 policy only for temporal path segment monitoring. Moreover, from the 217 perspective of operation, increasing the managed addresses and the 218 managed layers is not desirable to keep transport networks as simple 219 as possible. Reducing the managed identifiers and managed sub-layers 220 should be the fundamental direction in designing the architecture. 222 The analogy for SPME in legacy transport networks is Tandem 223 Connection Monitoring (TCM), which is on-demand and does not change 224 the transport path. 226 Moreover, using currently defined methods, the temporal setting of 227 SPMEs also causes the following problems due to label stacking: 229 (P-3) Changing the original condition of transport path by 230 changing the length of MPLS frames and changing the value of 231 exposed label 233 (P-4) Disrupting client traffic over a transport path, if the SPME 234 is configured on demand. 236 Problem (P-3) has impacts on network objective (2). The monitoring 237 function should monitor the status without changing any conditions of 238 the targeted monitored segment or transport path. Changing the 239 settings of the original shim header should not be allowed because 240 those changes correspond to creating a new portion of the original 241 transport path, which differs from the original data plane 242 conditions. If the conditions of the transport path change, the 243 measured value or observed data will also change. This may make the 244 monitoring meaningless because the result of the monitoring would no 245 longer reflect the reality of the connection where the original fault 246 or degradation occurred. 248 Figure 1 shows an example of SPME setting. In the figure, X means 249 the label value expected on the tail-end node D of the original 250 transport path. "210" and "220" are label allocated for SPME. The 251 label values of the original path are modified as well as the values 252 of stacked label. As shown in Figure 1, SPME changes both the length 253 of MPLS frames and label value(s). This is no longer the monitoring 254 of the original transport path but the monitoring of a different 255 path. Particularly, performance monitoring measurement (e.g. Delay 256 measurement and packet loss measurement) are sensitive to those 257 changes. 259 (Before SPME settings) 260 --- --- --- --- --- 261 | | | | | | | | | | 262 | | | | | | | | | | 263 --- --- --- --- --- 264 A---100--B--110--C--120--D--130--E <= transport path 265 MEP MEP 267 (After SPME settings) 268 --- --- --- --- --- 269 | | | | | | | | | | 270 | | | | | | | | | | 271 --- --- --- --- --- 272 A---100--B-----------X---D--130--E <= transport path 273 MEP \ / MEP 274 --210--C--220-- <= SPME 275 MEP' MEP' 277 Figure 1: An Example of a SPME setting 279 Problem (P-4) can be avoided if the operator sets SPMEs in advance 280 until the end of life of a transport path, which is neither temporal 281 nor on demand. Furthermore SMPEs cannot be set arbitrarly because 282 overlapping of path segments is limited to nesting relationship. As 283 a result, possible SPME patterns of portions of an original transport 284 path are limited due to the characteristic of SPME shown in Figure 1, 285 even if SPMEs are pre- configured. 287 Although the make-before-break procedure in the survivability 288 document RFC 6372 [RFC6372] seemingly supports the hitless 289 configuration for monitoring according to the framework document RFC 290 5921 [RFC5921], the reality is that configurating an SPME is 291 impossible without violating network objective (2). These concerns 292 are reported in section 3.8 of RFC 6371 [RFC6371]. 294 Moreover, make-before-break approach might not be effective under the 295 static model without a control plane because the make-before-break is 296 a restoration application based on the control plane. So management 297 systems should provide support for SPME creation and for coordinated 298 traffic switching from original transport path to the SPME. 300 Other potential risks are also envisaged. Setting up a temporal SPME 301 will result in the LSRs within the monitoring segment only looking at 302 the added (stacked) labels and not at the labels of the original LSP. 303 This means that problems stemming from incorrect (or unexpected) 304 treatment of labels of the original LSP by the nodes within the 305 monitored segment could not be found when setting up SPME. This 306 might include hardware problems during label look-up, mis- 307 configuration etc. Therefore operators have to pay extra attention 308 to correctly setting and checking the label values of the original 309 LSP in the configuration. Of course, the inversion of this situation 310 is also possible, e.g., incorrect or unexpected treatment of SPME 311 labels can result in false detection of a fault where none of the 312 problem originally existed. 314 The utility of SPMEs is basically limited to inter-carrier or inter- 315 domain segment monitoring where they are typically pre-configured or 316 pre-instantiated. SPME instantiates a hierarchical transport path 317 (introducing MPLS label stacking) through which OAM packets can be 318 sent. SPME construct monitoring function is particularly important 319 mainly for protecting bundles of transport paths and carriers' 320 carrier solutions. SPME is expected to be mainly used for protection 321 purpose within one administrative domain. 323 To summarize, the problem statement is that the current sub-path 324 maintenance based on a hierarchical LSP (SPME) is problematic for 325 pre-configuration in terms of increasing bandwidth by label stacking 326 and managing objects by layer stacking and address management. A on- 327 demand/temporal configuration of SPME is one of the possible 328 approaches for minimizing the impact of these issues. However, the 329 current method is unfavorable because the temporal configuration for 330 monitoring can change the condition of the original monitored 331 transport path. To avoid the drawbacks discussed above, a more 332 efficient approach is required for MPLS-TP transport network 333 operation to overcome or minimize the impact of the above described 334 drawbacks. A monitoring mechanism, named on-demand Enhanced Path 335 Segment Monitoring (EPSM), supporting temporal and hitless path 336 segment monitoring is proposed. 338 5. OAM functions supported in segment monitoring 340 OAM functions that may useful exploited across on-demand EPSM are 341 basically limited to on-demand performance monitoring functions which 342 are defined in OAM framework document RFC 6371 [RFC6371]. Segment 343 performance monitoring is used to evaluate the performance and hence 344 the status of transport path segments. The "on-demand" attribute is 345 generally temporal for maintenance operation. 347 Packet loss and packet delay are OAM functions strongly required in 348 hitless and temporal segment monitoring because these functions are 349 supported only between end points of a transport path. If a defect 350 occurs, it might be quite hard to locate the defect or degradation 351 point without using the segment monitoring function. If an operator 352 cannot locate or narrow the cause of the fault, it is quite difficult 353 to take prompt actions to solve the problem. 355 Other on-demand monitoring functions, (e.g. and Delay variation 356 measurement) are desirable but not as necessary as the previous 357 mentioned functions. 359 Regarding out-of-service on-demand performance management functions 360 (e.g. Throughput measurement), there seems no need for EPSM. 361 However, OAM functions specifically designed for segment monitoring 362 should be developed to satisfy network objective (2) described in 363 section 3. 365 Finally, the solution for EPSM has to cover both per-node model and 366 per- interface model which are specified in RFC 6371 [RFC6371]. 368 6. Requirements for enhanced segment monitoring 370 In the following clauses, mandatory (M) and optional (O) requirements 371 are for the new segment monitoring function are listed. 373 6.1. Non intrusive segment monitoring 375 One of the major problem of legacy SPME that has been highlighted in 376 Sec. 4 is that it does not monitor the original transport path and it 377 could distrupt service traffic when set-up on demand. 379 (M1) EPSM must not change the original condition of transport path 380 (e.g. must not change the lenght of MPLS frames, the exposed label 381 values, etc.) 383 (M2) EPSM must be set on demand without traffic dispruption 385 6.2. Single and multiple levels monitoring 387 The new segment monitoring function is supposed to be applied mainly 388 for on-demand diagnostic purpose. We can differentiate this 389 monitoring from the proactive segment monitoring as on-demand multi- 390 level monitoring. The most serious problem at the moment is that 391 there is no way to localize the degraded portion of a path without 392 changing the conditions of the original path. Therefore, as a first 393 step, single layer segment monitoring not affecting the monitored 394 path is required for a new on-demand and hitless segment monitoring 395 function. A combination of multi-level and simultaneous segment 396 monitoring is the most powerful tool for accurately diagnosing the 397 performance of a transport path. However, on field, a single level 398 approach may be enough. 400 (M3) Single-level segment monitoring is required 402 (O1) Multi-level segment monitoring is desirable 404 Figure 2 shows an example of a multi-level on-demand segment 405 monitoring. 407 --- --- --- --- --- 408 | | | | | | | | | | 409 | A | | B | | C | | D | | E | 410 --- --- --- --- --- 411 MEP MEP <= ME of a transport path 412 *------------------* <=On-demand segm. monit. level 1 413 *-------------* <=On-demand segm. monit. level 2 414 *-* <=On-demand segm. monit. level 3 416 Figure 2: Example of multi-level on-demand segment monitoring 418 6.3. EPSM and end-to-end proactive monitoring independence 420 The necessity of simultaneous monitoring of current end-to-end 421 proactive monitoring and new on-demand path segment monitoring is 422 here below considered. Normally, the on-demand path segment 423 monitoring is configured in a segment of a maintenance entity of a 424 transport path. In such an environment, on-demand single-level 425 monitoring should be done without disrupting pro-active monitoring of 426 the targeted end- to-end transport path to avoid missing user traffic 427 performance monitoring. 429 Accordingly, 431 (M4) EPSM shall be established without changing or interfering 432 with the already in place end-to-end pro-active monitoring of 433 transport path 435 --- --- --- --- --- 436 | | | | | | | | | | 437 | A | | B | | C | | D | | E | 438 --- --- --- --- --- 439 MEP MEP <= ME of a transport path 440 +-----------------------------+ <= Proactive E2E monitoring 441 *------------------* <= On-demand segment monitoring 443 Figure 3: Independency between proactive end-to-end monitoring and 444 on-demand segment monitoring 446 6.4. Arbitrary segment monitoring 448 The main objective of on-demand segment monitoring is to diagnose the 449 fault points. One possible realistic diagnostic procedure is to fix 450 one end point of a segment at the MEP of the transport path under 451 observation and change progressively the length of the segments. 452 This example is shown in Figure 4. 454 --- --- --- --- --- 455 | | | | | | | | | | 456 | A | | B | | C | | D | | E | 457 --- --- --- --- --- 458 MEP MEP <= ME of a transport path 459 +-----------------------------+ <= Proactive E2E monitoring 460 *-----* <= 1st on-demand segment monitoring 461 *-------* <= 2nd on-demand segment monitoring 462 *------------* <= 3rd on-demand segment monitoring 463 | | 464 | | 465 *-----------------------* <= 6th on-demand segment monitoring 466 *-----------------------------*<= 7th on-demand segment monitoring 468 Figure 4: A procedure to localize a defect by consecutive on-demand 469 segments monitoring 471 Another possible scenario is depicted in Figure 5. In this case, the 472 operators want to diagnose a transport path from a transit node that 473 is located at the middle, because the end nodes(A and E) are located 474 at customer sites and consist of cost effective small box supporting 475 only a subset of OAM functions. In that case, if the source entities 476 of the diagnostic packets are limited to the position of MEPs, on- 477 demand segment monitoring will be ineffective because not all the 478 segments can be diagnosed (e.g. segment monitoring 3 in Figure 5 is 479 not available and it is not possible to precisely localize the fault 480 point). 482 Accordingly, 484 (M5) EPSM shall be set in an arbitrary segment of a transport path 485 and diagnostic packets should be inserted/terminated at any of 486 intermediate maintenance points of the original ME. 488 --- --- --- 489 --- | | | | | | --- 490 | A | | B | | C | | D | | E | 491 --- --- --- --- --- 492 MEP MEP <= ME of a transport path 493 +-----------------------------+ <= Proactive E2E monitoring 494 *-----* <= On-demand segment monitoring 1 495 *-----------------------*<= On-demand segment monitoring 2 496 *---------* <= On-demand segment monitoring 3 498 Figure 5: HSPM is configured at arbitrary segments 500 6.5. Fault while EPSM is in place 502 Node or link failures may occur while EPSM is active. In that case, 503 if no resiliency mechanism is set-up on the subtended transport path, 504 there is no particular requirement for EPSM while if the trasport 505 path is protected, EPSM function should be terminated to avoid 506 monitoring a new segment when a protection or restoration path is in 507 place. Therefore 509 (M5) EPSM function should avoid monitoring an unintended segment 510 when failures occur 512 The folowing examples are reported for clarification only and shall 513 not be intended to restrict any solution for meeting the requirements 514 of EPSM. A Protection scenario A is shown in figure 6. In this 515 scenario, a working LSP and a protection LSP are set. EPSM is set 516 between A and E. Considering a fault happens between nodes B and C, 517 the EPSM is not affected by protection and continues in the working 518 LSP path. As a result, requirement (M5) is satisfied. 520 A - B - C - D - E - F 521 \ / 522 G - H - I - L 524 Where: 525 - e2e LSP: A-B-C-D-E-F 526 - working LSP: A-B-C-D-E-F 527 - protection LSP: A-B-G-H-I-L-F 528 - EPSM: A-E 529 --------------- 531 Figure 6: Protection scenario A 533 Differently, figure 7 shows a scenario where only a portion of a 534 transport path is protected. In this case, when a fault happen 535 between node B and C along the working sub-path, traffic is switched 536 to protection sub-path B-G-H-D. In the hypotesis that OAM packets 537 termination depend only on TTL value of MPLS label header, the target 538 node of EPSM changes from E to D due to the difference of hop counts 539 between the working path route (ABCDE: 4 hops) and protection path 540 route (ABGHDE: 5 hops). As a result, requirement (M5) is not 541 satisfied. 543 A - B - C - D - E - F 544 \ / 545 G - H 547 - e2e LSP: A-B-C-D-E-F 548 - working sub-path: B-C-D 549 - protection sub-path: B-G-H-D 550 - EPSM: A-E 551 --------------- 553 Figure 7: Protection scenario B 555 6.6. EPSM maintenance points 557 An intermediate maintenance point supporting the EPSM has to be able 558 to generate and inject OAM packets. Although maintenance points for 559 the EPSM do not necessarily have to coincide with MIPs or MEPs in 560 terms of the architecture definition, 562 (M7) The same identifiers for MIPs and/or MEPs should be applied 563 to EPSM maintenance points 565 7. Summary 567 An enhanced monitoring mechanism is required to support temporal and 568 hitless segment monitoring which meets the two network objectives 569 described in section 3.8 of RFC 6371 [RFC6371] and reported in 570 Section 3 of this document. 572 The enhancements should minimize the issues described in Section 4, 573 i.e., P-1, P-2, P-3 and P-4. 575 The solution for the temporal and hitless segment monitoring has to 576 cover both per-node model and per-interface model which are specified 577 in RFC 6371 [RFC6371]. 579 The temporal and hitless segment monitoring solutions shall support 580 on-demand Packet Loss Measurement and Packet Delay Measurement 581 functions and optionally other performance monitoring /fault 582 management functions (e.g. Throughput measurement, Delay variation 583 measurement, Diagnostic test measurement, etc.). 585 8. Security Considerations 587 The security considerations defined for RFC 6378 apply to this 588 document as well. As this is simply a re-use of RFC 6378, there are 589 no new security considerations. 591 9. IANA Considerations 593 There are no requests for IANA actions in this document. 595 Note to the RFC Editor - this section can be removed before 596 publication. 598 10. Acknowledgements 600 The author would like to thank all members (including MPLS-TP 601 steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group 602 in ITU-T) involved in the definition and specification of MPLS 603 Transport Profile. 605 The authors would also like to thank Alexander Vainshtein, Dave 606 Allan, Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, 607 Malcolm Betts, Nurit Sprecher and Jia He for their comments and 608 enhancements to the text. 610 11. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 618 Label Switching Architecture", RFC 3031, 619 DOI 10.17487/RFC3031, January 2001, 620 . 622 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 623 "Requirements for Operations, Administration, and 624 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 625 DOI 10.17487/RFC5860, May 2010, 626 . 628 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 629 L., and L. Berger, "A Framework for MPLS in Transport 630 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 631 . 633 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 634 Administration, and Maintenance Framework for MPLS-Based 635 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 636 September 2011, . 638 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 639 Profile (MPLS-TP) Survivability Framework", RFC 6372, 640 DOI 10.17487/RFC6372, September 2011, 641 . 643 Authors' Addresses 645 Alessandro D'Alessandro 646 Telecom Italia 648 Email: alessandro.dalessandro@telecomitalia.it 650 Loa Andersson 651 Huawei Technologies 653 Email: loa@mail01.huawei.com 655 Manuel Paul 656 Deutsche Telekom 658 Email: Manuel.Paul@telekom.de 660 Satoshi Ueno 661 NTT Communications 663 Email: satoshi.ueno@ntt.com 665 Kaoru Arai 666 NTT 668 Email: arai.kaoru@lab.ntt.co.jp 669 Yoshinori Koike 670 NTT 672 Email: koike.yoshinori@lab.ntt.co.jp