idnits 2.17.1 draft-ietf-teas-gmpls-signaling-smp-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 (Using the creation date from RFC4872, updated by this document, for RFC5378 checks: 2004-04-06) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2021) is 1038 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) == Missing Reference: 'A' is mentioned on line 197, but not defined == Missing Reference: 'B' is mentioned on line 197, but not defined == Missing Reference: 'C' is mentioned on line 197, but not defined == Missing Reference: 'D' is mentioned on line 197, but not defined == Missing Reference: 'H' is mentioned on line 185, but not defined == Missing Reference: 'I' is mentioned on line 184, but not defined == Missing Reference: 'J' is mentioned on line 184, but not defined == Missing Reference: 'K' is mentioned on line 185, but not defined == Missing Reference: 'E' is mentioned on line 185, but not defined == Missing Reference: 'F' is mentioned on line 185, but not defined == Missing Reference: 'G' is mentioned on line 185, but not defined Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. He 3 Internet-Draft I. Busi 4 Updates: 4872 (if approved) Huawei Technologies 5 Intended status: Standards Track J. Ryoo 6 Expires: December 18, 2021 B. Yoon 7 ETRI 8 P. Park 9 KT 10 June 16, 2021 12 GMPLS Signaling Extensions for Shared Mesh Protection 13 draft-ietf-teas-gmpls-signaling-smp-07 15 Abstract 17 ITU-T Recommendation G.808.3 defines the generic aspects of a Shared 18 Mesh Protection (SMP) mechanism, where the difference between SMP and 19 Shared Mesh Restoration (SMR) is also identified. ITU-T 20 Recommendation G.873.3 defines the protection switching operation and 21 associated protocol for SMP at the Optical Data Unit (ODU) layer. 22 RFC 7412 provides requirements for any mechanism that would be used 23 to implement SMP in a Multi-Protocol Label Switching - Transport 24 Profile (MPLS-TP) network. 26 This document updates RFC 4872 to provide the extensions to the 27 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 28 support the control of the SMP. 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 https://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 December 18, 2021. 47 Copyright Notice 49 Copyright (c) 2021 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 (https://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 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 78 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4 80 4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 82 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 83 4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8 84 5. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 8 85 5.1. New Protection Type . . . . . . . . . . . . . . . . . . . 8 86 5.2. Updates on Notification and Operational Bits . . . . . . 9 87 5.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 9 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 91 9. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 10.2. Informative References . . . . . . . . . . . . . . . . . 11 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol 101 - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration 102 (SMR) mechanisms. SMR can be seen as a particular case of pre- 103 planned Label Switched Path (LSP) rerouting that reduces the recovery 104 resource requirements by allowing multiple protecting LSPs to share 105 common link and node resources. The recovery resources for the 106 protecting LSPs are pre-reserved during the provisioning phase, and 107 explicit restoration signaling is required to activate (i.e., commit 108 resource allocation at the data plane) a specific protecting LSP 109 instantiated during the provisioning phase. 111 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of 112 a shared mesh protection (SMP) mechanism. ITU-T Recommendation 113 G.873.3 [G873.3] defines the protection switching operation and 114 associated protocol for SMP at the Optical Data Unit (ODU) layer. 115 RFC 7412 [RFC7412] provides requirements for any mechanism that would 116 be used to implement SMP in a Multi-Protocol Label Switching - 117 Transport Profile (MPLS-TP) network. 119 SMP differs from SMR in the activation/protection switching 120 operation. The former activates a protecting LSP via the automatic 121 protection switching (APS) protocol in the data plane when the 122 working LSP fails, while the latter does it via control plane 123 signaling. It is therefore necessary to distinguish SMP from SMR 124 during provisioning so that each node involved behaves appropriately 125 in the recovery phase when activation of a protecting LSP is done. 127 This document updates [RFC4872] to provide the extensions to the 128 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 129 support the control of the SMP mechanism. Only the generic aspects 130 for signaling SMP are addressed by this document. The technology- 131 specific aspects are expected to be addressed by other documents. 133 2. Conventions Used in This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 In addition, the reader is assumed to be familiar with the 142 terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 143 [RFC6372]. 145 3. SMP Definition 147 [G808.3] defines the generic aspects of an SMP mechanism. [G873.3] 148 defines the protection switching operation and associated protocol 149 for SMP at the ODU layer. [RFC7412] provides requirements for any 150 mechanism that would be used to implement SMP in a MPLS-TP network. 152 The SMP mechanism is based on pre-computed protecting LSPs that are 153 pre-configured into the network elements. Pre-configuration here 154 means pre-reserving resources for the protecting LSPs without 155 activating a particular protecting LSP (e.g., in circuit networks, 156 the cross-connects in the intermediate nodes of the protecting LSP 157 are not pre-established). Pre-configuring but not activating a 158 protecting LSP allows the common link and node resources in the 159 protecting LSP to be shared by multiple working LSPs that are 160 physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) 161 disjoint. Protecting LSPs are activated in response to failures of 162 working LSPs or operator's commands by means of the APS protocol that 163 operates in the data plane. The APS protocol messages are exchanged 164 along the protecting LSP. SMP is always revertive. 166 SMP has a lot of similarity to SMR except that the activation in case 167 of SMR is achieved by control plane signaling during the recovery 168 operation, while SMP is done by the APS protocol in the data plane. 169 SMP has advantages with regard to the recovery speed compared with 170 SMR. 172 4. GMPLS Signaling Extension for SMP 174 Consider the following network topology: 176 A---B---C---D 177 \ / 178 E---F---G 179 / \ 180 H---I---J---K 182 Figure 1: An example of SMP topology 184 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 185 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], 186 in order to achieve resource sharing during the signaling of these 187 protecting LSPs, they MUST have the same Tunnel Endpoint Address (as 188 part of their SESSION object). However, these addresses are not the 189 same in this example. Similar to SMR, this document defines a new 190 LSP Protection Type of the secondary LSP as "Shared Mesh Protection" 191 (see Section 5.1) to allow resource sharing along nodes E, F, and G. 192 In this case, the protecting LSPs are not merged (which is useful 193 since the paths diverge at G), but the resources along E, F, G can be 194 shared. 196 When a failure, such as Signal Fail (SF) and Signal Degrade (SD), 197 occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 198 end-node (say node A) that detects the failure initiates the 199 protection switching operation. End-node A will send a protection 200 switching request APS message (for example, SF) to its adjacent 201 (downstream) intermediate node (say node E) to activate the 202 corresponding protecting LSP and will wait for a confirmation message 203 from node E. If the protection resource is available, node E will 204 send the confirmation APS message to the end-node A and forward the 205 switching request APS message to its adjacent (downstream) node (say 206 node F). When the confirmation APS message is received by node A, 207 the cross-connection on node A is established. At this time the 208 traffic is bridged to and selected from the protecting LSP at node A. 209 After forwarding the switching request APS message, node E will wait 210 for a confirmation APS message from node F, which triggers node E to 211 set up the cross-connection for the protecting LSP being activated. 212 If the protection resource is not available (due to failure or being 213 used by higher priority connections), the switching will not be 214 successful; the intermediate node MUST send a message to notify the 215 end node. If the resource is in use by a lower priority protecting 216 LSP, the lower priority service will be removed and then the 217 intermediate node will follow the procedure as described for the case 218 when the protection resource is available for the higher priority 219 protecting LSP. 221 The SMP preemption priority of a protecting LSP that the APS protocol 222 uses to resolve the competition for shared resources among multiple 223 protecting LSPs, is indicated in Preemption Priority field of the 224 PROTECTION object in the Path message of the protecting LSP. 226 In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE 227 object can be used by GMPLS to control LSP preemption, but, they are 228 not used by the APS to resolve the competition among multiple 229 protecting LSPs. This avoids the need to define a complex policy for 230 defining Setup and Holding priorities when used for both GMPLS 231 control plane LSP preemption and SMP shared resource competition 232 resolution. 234 When an intermediate node on the protecting LSP receives the Path 235 message, the priority value in the Preemption Priority field MUST be 236 stored for that protecting LSP. When resource competition among 237 multiple protecting LSPs occurs, the APS protocol will use their 238 priority values to resolve the competition. 240 In SMP, a preempted LSP SHOULD NOT be torn down. Once the working 241 LSP and the protecting LSP are configured or pre-configured, the end 242 node SHOULD keep refreshing both working and protecting LSPs 243 regardless of failure or preempted situation. 245 When a lower priority protecting LSP is preempted, the intermediate 246 node that performed preemption MUST send a Notify message with a new 247 sub-code "Shared resources unavailable" under "Notify Error" code 248 (see [RFC4872]) to the end nodes of that protecting LSP. Upon 249 receipt of this Notify message, the end node MUST stop sending and 250 selecting normal traffic to/from its protecting LSP and try switching 251 the traffic to another protection LSP, if available. 253 When the shared resources become unavailable, including a case of the 254 shared resources failure, the same Notify message MUST also be 255 generated by the intermediate node to all the end nodes of the 256 protecting LSPs that have lower SMP preemption priorities than the 257 one that has occupied the shared resources. These end nodes, in case 258 of a failure of the working LSP, MUST avoid trying to switch the 259 traffic to these protection LSPs that have been configured to use the 260 shared resources and try switching the traffic to other protection 261 LSPs, if available. 263 When the shared resources become available, a Notify message with a 264 new sub-code "Shared resources available" under "Notify Error" code 265 MUST be generated by the intermediate node. The recipients of this 266 Notify message are the end nodes of the lower priority protecting 267 LSPs that have been preempted and/or all the end nodes of the 268 protecting LSPs that have lower SMP preemption priorities than the 269 one that does not need the shared resources any more. 271 The following subsections detail how LSPs using SMP can be signaled 272 in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 273 3473 [RFC3473]). This includes: 275 (1) the ability to identify a "secondary protecting LSP" (hereby 276 called the "secondary LSP") used to recover another primary 277 working LSP (hereby called the "protected LSP"), 279 (2) the ability to associate the secondary LSP with the protected 280 LSP, 282 (3) the capability to include information about the resources used 283 by the protected LSP while instantiating the secondary LSP, 285 (4) the capability to instantiate during the provisioning phase 286 several secondary LSPs in an efficient manner, and 287 (5) the capability to support activation of a secondary LSP after 288 failure occurrence via APS protocol in the data plane. 290 4.1. Identifiers 292 To simplify association operations, both LSPs (i.e., the protected 293 and the secondary LSPs) belong to the same session. Thus, the 294 SESSION object MUST be the same for both LSPs. The LSP ID, however, 295 MUST be different to distinguish between the protected LSP carrying 296 normal traffic and the secondary LSP. 298 A new LSP Protection Type "Shared Mesh Protection" is introduced to 299 the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two 300 LSPs. This LSP Protection Type value is applicable only to 301 bidirectional LSPs as required in [G808.3]. 303 4.2. Signaling Primary LSPs 305 The PROTECTION object (see [RFC4872]) is included in the Path message 306 during signaling of the primary working LSPs, with the LSP Protection 307 Type value set to "Shared Mesh Protection". 309 Primary working LSPs are signaled by setting in the PROTECTION object 310 the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION 311 object, the Association ID to the associated secondary protecting 312 LSP_ID. 314 Note: N bit is set to indicate that the protection switching 315 signaling is done via data plane. 317 4.3. Signaling Secondary LSPs 319 The PROTECTION object (see [RFC4872]) is included in the Path message 320 during signaling of the secondary protecting LSPs, with the LSP 321 Protection Type value set to "Shared Mesh Protection". 323 Secondary protecting LSPs are signaled by setting in the PROTECTION 324 object the S bit and the P bit to 1, the N bit to 1 and in the 325 ASSOCIATION object, the Association ID to the associated primary 326 working LSP_ID, which MUST be known before signaling of the secondary 327 LSP. Moreover, the Path message used to instantiate the secondary 328 LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see 329 [RFC4872]) that further allows for recovery resource sharing at each 330 intermediate node along the secondary path. 332 With this setting, the resources for the secondary LSP SHOULD be pre- 333 reserved, but not committed at the data plane level, meaning that the 334 internals of the switch need not be established until explicit action 335 is taken to activate this LSP. Activation of a secondary LSP and 336 protection switching to the activated protecting LSP is done using 337 APS protocol in the data plane. 339 After protection switching completes the protecting LSP SHOULD be 340 signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION 341 object. At this point, the link and node resources MUST be allocated 342 for this LSP that becomes a primary LSP (ready to carry normal 343 traffic). The formerly working LSP MAY be signaled with the A bit 344 set in the ADMIN_STATUS object (see [RFC3473]). 346 Support for extra traffic in SMP is for further study. Therefore, 347 mechanisms to setup LSPs for extra traffic are also for further 348 study. 350 4.4. SMP APS Configuration 352 SMP relies on APS protocol messages being exchanged between the nodes 353 along the path to activate an SMP protecting LSP. 355 In order to allow exchange of APS protocol messages, an APS channel 356 has to be configured between adjacent nodes along the path of the SMP 357 protecting LSP. This should be done before any SMP protecting LSP 358 has been setup by other means than GMPL signaling which are therefore 359 outside the scope of this document. 361 Depending on the APS protocol message format, the APS protocol may 362 use different identifiers than GMPLS signaling to identify the SMP 363 protecting LSP. 365 Since APS protocol is for further study in [G808.3], it can be 366 assumed that APS message format and identifiers are technology- 367 specific and/or vendor-specific. Therefore, additional requirements 368 for APS configuration are outside the scope of this document. 370 5. Updates to PROTECTION Object 372 GMPLS extension requirements for SMP introduce several updates to the 373 Protection Object (see [RFC4872]). 375 5.1. New Protection Type 377 A new LSP protection type "Shared Mesh Protection" is added in the 378 PROTECTION object. This LSP Protection Type value is applicable to 379 only bidirectional LSPs. 381 LSP (Protection Type) Flags: 383 0x11: Shared Mesh Protection 385 According to the rules defined in Section 14.2 of [RFC4872], all the 386 nodes along an SMP LSP MUST be SMP aware and therefore there are no 387 backward compatibility issues. 389 5.2. Updates on Notification and Operational Bits 391 N bit and O bit in the PROTECTION object as defined in [RFC4872] are 392 also updated to include applicability to SMP. 394 Notification (N): 1 bit 396 When set to 1, this bit indicates that the control plane message 397 exchange is only used for notification during protection 398 switching. When set to 0 (default), it indicates that the control 399 plane message exchanges are used for protection-switching 400 purposes. The N bit is only applicable when the LSP Protection 401 Type Flag is set to either 0x04 (1:N Protection with Extra- 402 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 403 Bidirectional Protection). In SMP, N bit MUST be set to 1. The N 404 bit MUST be set to 0 in any other case. 406 Operational (O): 1 bit 408 When set to 1, this bit indicates that the protecting LSP is 409 carrying the normal traffic after protection switching. The O bit 410 is only applicable when the P bit is set to 1, and the LSP 411 Protection Type Flag is set to either 0x04 (1:N Protection with 412 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 413 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 414 The O bit MUST be set to 0 in any other case. 416 5.3. Preemption Priority 418 The 32-bit Reserved field in the PROTECTION object defined in 419 [RFC4872] is updated as follows: 421 0 1 2 3 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Reserved | Preempt Prio | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Preemption Priority (Preempt Prio): 8 bit 429 This field indicates the SMP preemption priority of a protecting 430 LSP, when the LSP Protection Type field indicates "Shared Mesh 431 Protection". The SMP preemption priority value is configured at 432 the end nodes of the protecting LSP by a network operator. A 433 lower value has a higher priority. The decision of how many 434 priority levels to be operated in an SMP network is a network 435 operator's choice. 437 6. IANA Considerations 439 This document requests IANA to define two new sub-code values under 440 "Notify Error" code in Resource Reservation Protocol (RSVP) 441 parameters. 443 Value Description Reference 444 ----- ---------------------------- --------------- 445 TBD1 Shared resources unavailable (this document) 446 TBD2 Shared resources available (this document) 448 7. Security Considerations 450 The security threats discussed in [RFC4872] also apply to this 451 document. Additionally, it may be possible to cause disruption to 452 traffic on one protecting LSP by targeting a link used by the primary 453 LSP of another, higher priority LSP somewhere completely different in 454 the network. To prevent such an additional risk factor, it is 455 important not only to use security mechanisms as discussed in 456 [RFC4872] but also to preserve privacy of information about 457 protecting LSPs within the network. 459 8. Acknowledgements 461 The authors would like to thank Adrian Farrel for his valuable 462 comments and suggestions on this document. 464 9. Contributor 466 The following person contributed significantly to the content of this 467 document and should be considered as a co-author. 469 Yuji Tochio 470 Fujitsu 471 Email: tochio@fujitsu.com 473 10. References 474 10.1. Normative References 476 [G808.3] International Telecommunication Union, "Generic protection 477 switching - Shared mesh protection", ITU-T Recommendation 478 G.08.3, October 2012. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 486 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 487 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 488 . 490 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 491 Switching (GMPLS) Signaling Resource ReserVation Protocol- 492 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 493 DOI 10.17487/RFC3473, January 2003, 494 . 496 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 497 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 498 Recovery Functional Specification", RFC 4426, 499 DOI 10.17487/RFC4426, March 2006, 500 . 502 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 503 Ed., "RSVP-TE Extensions in Support of End-to-End 504 Generalized Multi-Protocol Label Switching (GMPLS) 505 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 506 . 508 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 509 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 510 May 2017, . 512 10.2. Informative References 514 [G873.3] International Telecommunication Union, "Optical transport 515 network - Shared mesh protection", ITU-T Recommendation 516 G.873.3, September 2017. 518 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 519 Profile (MPLS-TP) Survivability Framework", RFC 6372, 520 DOI 10.17487/RFC6372, September 2011, 521 . 523 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 524 Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) 525 Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, 526 December 2014, . 528 Authors' Addresses 530 Jia He 531 Huawei Technologies 532 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District 533 Shenzhen 534 China 536 Email: hejia@huawei.com 538 Italo Busi 539 Huawei Technologies 541 Email: italo.busi@huawei.com 543 Jeong-dong Ryoo 544 ETRI 545 218 Gajeongno 546 Yuseong-gu, Daejeon 34129 547 South Korea 549 Phone: +82-42-860-5384 550 Email: ryoo@etri.re.kr 552 Bin Yeong Yoon 553 ETRI 555 Email: byyun@etri.re.kr 557 Peter Park 558 KT 560 Email: peter.park@kt.com