idnits 2.17.1 draft-ietf-teas-gmpls-signaling-smp-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 (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 (October 17, 2021) is 916 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 481, but not defined == Missing Reference: 'B' is mentioned on line 238, but not defined == Missing Reference: 'C' is mentioned on line 238, but not defined == Missing Reference: 'D' is mentioned on line 481, but not defined == Missing Reference: 'H' is mentioned on line 483, but not defined == Missing Reference: 'I' is mentioned on line 238, but not defined == Missing Reference: 'J' is mentioned on line 238, but not defined == Missing Reference: 'K' is mentioned on line 483, but not defined == Missing Reference: 'E' is mentioned on line 483, but not defined == Missing Reference: 'F' is mentioned on line 483, but not defined == Missing Reference: 'G' is mentioned on line 483, 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: April 20, 2022 B. Yoon 7 ETRI 8 P. Park 9 KT 10 October 17, 2021 12 GMPLS Signaling Extensions for Shared Mesh Protection 13 draft-ietf-teas-gmpls-signaling-smp-08 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 April 20, 2022. 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. Operation of SMP with GMPLS Signaling Extension . . . . . . . 4 80 5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 5 81 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 82 5.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 6 83 5.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 6 84 5.4. SMP Preemption Priority . . . . . . . . . . . . . . . . . 7 85 5.5. Notifying Availability of Shared Resources . . . . . . . 8 86 5.6. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8 87 6. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 9 88 6.1. New Protection Type . . . . . . . . . . . . . . . . . . . 9 89 6.2. Updates on Notification and Operational Bits . . . . . . 9 90 6.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 10 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 94 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 97 11.2. Informative References . . . . . . . . . . . . . . . . . 12 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 100 1. Introduction 102 RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol 103 - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration 104 (SMR) mechanisms. SMR can be seen as a particular case of pre- 105 planned Label Switched Path (LSP) rerouting that reduces the recovery 106 resource requirements by allowing multiple protecting LSPs to share 107 common link and node resources. The recovery resources for the 108 protecting LSPs are pre-reserved during the provisioning phase, and 109 explicit restoration signaling is required to activate (i.e., commit 110 resource allocation at the data plane) a specific protecting LSP 111 instantiated during the provisioning phase. 113 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of 114 a shared mesh protection (SMP) mechanism, which are not specific to a 115 particular network technology in terms of architecture types, 116 preemption principle, and path monitoring methods, etc. ITU-T 117 Recommendation G.873.3 [G873.3] defines the protection switching 118 operation and associated protocol for SMP at the Optical Data Unit 119 (ODU) layer. RFC 7412 [RFC7412] provides requirements for any 120 mechanism that would be used to implement SMP in a Multi-Protocol 121 Label Switching - Transport Profile (MPLS-TP) network. 123 SMP differs from SMR in the activation/protection switching 124 operation. The former activates a protecting LSP via the automatic 125 protection switching (APS) protocol in the data plane when the 126 working LSP fails, while the latter does it via control plane 127 signaling. It is therefore necessary to distinguish SMP from SMR 128 during provisioning so that each node involved behaves appropriately 129 in the recovery phase when activation of a protecting LSP is done. 131 This document updates [RFC4872] to provide the extensions to the 132 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 133 support the control of the SMP mechanism. Only the generic aspects 134 for signaling SMP are addressed by this document. The technology- 135 specific aspects are expected to be addressed by other documents. 137 2. Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 In addition, the reader is assumed to be familiar with the 146 terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 147 [RFC6372]. 149 3. SMP Definition 151 [G808.3] defines the generic aspects of an SMP mechanism. [G873.3] 152 defines the protection switching operation and associated protocol 153 for SMP at the ODU layer. [RFC7412] provides requirements for any 154 mechanism that would be used to implement SMP in a MPLS-TP network. 156 The SMP mechanism is based on pre-computed protecting LSPs that are 157 pre-configured into the network elements. Pre-configuration here 158 means pre-reserving resources for the protecting LSPs without 159 activating a particular protecting LSP (e.g., in circuit networks, 160 the cross-connects in the intermediate nodes of the protecting LSP 161 are not pre-established). Pre-configuring but not activating a 162 protecting LSP allows the common link and node resources in the 163 protecting LSP to be shared by multiple working LSPs that are 164 physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) 165 disjoint. Protecting LSPs are activated in response to failures of 166 working LSPs or operator's commands by means of the APS protocol that 167 operates in the data plane. The APS protocol messages are exchanged 168 along the protecting LSP. SMP is always revertive. 170 SMP has a lot of similarity to SMR except that the activation in case 171 of SMR is achieved by control plane signaling during the recovery 172 operation, while SMP is done by the APS protocol in the data plane. 173 SMP has advantages with regard to the recovery speed compared with 174 SMR. 176 4. Operation of SMP with GMPLS Signaling Extension 178 Consider the following network topology: 180 A---B---C---D 181 \ / 182 E---F---G 183 / \ 184 H---I---J---K 186 Figure 1: An example of SMP topology 188 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the 189 protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 190 3209 [RFC3209], in order to achieve resource sharing during the 191 signaling of these protecting LSPs, they MUST have the same Tunnel 192 Endpoint Address (as part of their SESSION object). However, these 193 addresses are not the same in this example. Similar to SMR, this 194 document defines a new LSP Protection Type of the secondary LSP as 195 "Shared Mesh Protection" (see Section 6.1) to allow resource sharing 196 along nodes E, F, and G. Examples of shared resources include the 197 capacity of a link and the cross-connects in a node. In this case, 198 the protecting LSPs are not merged (which is useful since the paths 199 diverge at G), but the resources along E, F, G can be shared. 201 When a failure, such as Signal Fail (SF) and Signal Degrade (SD), 202 occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 203 end-node (say node A) that detects the failure initiates the 204 protection switching operation. End-node A will send a protection 205 switching request APS message (for example, SF) to its adjacent 206 (downstream) intermediate node (say node E) to activate the 207 corresponding protecting LSP and will wait for a confirmation message 208 from node E. 210 If the protection resource is available, node E will send the 211 confirmation APS message to the end-node A and forward the switching 212 request APS message to its adjacent (downstream) node (say node F). 213 When the confirmation APS message is received by node A, the cross- 214 connection on node A is established. At this time the traffic is 215 bridged to and selected from the protecting LSP at node A. After 216 forwarding the switching request APS message, node E will wait for a 217 confirmation APS message from node F, which triggers node E to set up 218 the cross-connection for the protecting LSP being activated. 220 If the protection resource is not available (due to failure or being 221 used by higher priority connections), the switching will not be 222 successful; the intermediate node (node E) MUST send a message to 223 notify the end node (see Section 5.5). If the resource is in use by 224 a lower priority protecting LSP, the lower priority service will be 225 removed and then the intermediate node will follow the procedure as 226 described for the case when the protection resource is available for 227 the higher priority protecting LSP. 229 5. GMPLS Signaling Extension for SMP 231 The following subsections detail how LSPs using SMP can be signaled 232 in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 233 3473 [RFC3473]). This includes: 235 (1) the ability to identify a "secondary protecting LSP" (LSP 236 [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, hereby called the 237 "secondary LSP") used to recover another "primary working LSP" 238 (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the 239 "protected LSP"), 241 (2) the ability to associate the secondary LSP with the protected 242 LSP, 244 (3) the capability to include information about the resources used 245 by the protected LSP while instantiating the secondary LSP, 247 (4) the capability to instantiate during the provisioning phase 248 several secondary LSPs in an efficient manner, and 250 (5) the capability to support activation of a secondary LSP after 251 failure occurrence via APS protocol in the data plane. 253 5.1. Identifiers 255 To simplify association operations, both LSPs (i.e., the protected 256 and the secondary LSPs) belong to the same session. Thus, the 257 SESSION object MUST be the same for both LSPs. The LSP ID, however, 258 MUST be different to distinguish between the protected LSP carrying 259 normal traffic and the secondary LSP. 261 A new LSP Protection Type "Shared Mesh Protection" is introduced to 262 the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two 263 LSPs. This LSP Protection Type value is applicable only to 264 bidirectional LSPs as required in [G808.3]. 266 5.2. Signaling Primary LSPs 268 The PROTECTION object (see [RFC4872]) is included in the Path message 269 during signaling of the primary working LSPs, with the LSP Protection 270 Type value set to "Shared Mesh Protection". 272 Primary working LSPs are signaled by setting in the PROTECTION object 273 the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION 274 object, the Association ID to the associated secondary protecting 275 LSP_ID. 277 Note: N bit is set to indicate that the protection switching 278 signaling is done via data plane. 280 5.3. Signaling Secondary LSPs 282 The PROTECTION object (see [RFC4872]) is included in the Path message 283 during signaling of the secondary protecting LSPs, with the LSP 284 Protection Type value set to "Shared Mesh Protection". 286 Secondary protecting LSPs are signaled by setting in the PROTECTION 287 object the S bit and the P bit to 1, the N bit to 1 and in the 288 ASSOCIATION object, the Association ID to the associated primary 289 working LSP_ID, which MUST be known before signaling of the secondary 290 LSP. Moreover, the Path message used to instantiate the secondary 291 LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see 292 [RFC4872]) that further allows for recovery resource sharing at each 293 intermediate node along the secondary path. 295 With this setting, the resources for the secondary LSP SHOULD be pre- 296 reserved, but not committed at the data plane level, meaning that the 297 internals of the switch need not be established until explicit action 298 is taken to activate this LSP. Activation of a secondary LSP and 299 protection switching to the activated protecting LSP is done using 300 APS protocol in the data plane. 302 After protection switching completes the protecting LSP SHOULD be 303 signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION 304 object. At this point, the link and node resources MUST be allocated 305 for this LSP that becomes a primary LSP (ready to carry normal 306 traffic). The formerly working LSP MAY be signaled with the A bit 307 set in the ADMIN_STATUS object (see [RFC3473]). 309 Support for extra traffic in SMP is for further study. Therefore, 310 mechanisms to setup LSPs for extra traffic are also for further 311 study. 313 5.4. SMP Preemption Priority 315 The SMP preemption priority of a protecting LSP that the APS protocol 316 uses to resolve the competition for shared resources among multiple 317 protecting LSPs, is indicated in Preemption Priority field of the 318 PROTECTION object in the Path message of the protecting LSP. 320 In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE 321 object can be used by GMPLS to control LSP preemption, but, they are 322 not used by the APS to resolve the competition among multiple 323 protecting LSPs. This avoids the need to define a complex policy for 324 defining Setup and Holding priorities when used for both GMPLS 325 control plane LSP preemption and SMP shared resource competition 326 resolution. 328 When an intermediate node on the protecting LSP receives the Path 329 message, the priority value in the Preemption Priority field MUST be 330 stored for that protecting LSP. When resource competition among 331 multiple protecting LSPs occurs, the APS protocol will use their 332 priority values to resolve the competition. 334 In SMP, a preempted LSP SHOULD NOT be torn down. Once the working 335 LSP and the protecting LSP are configured or pre-configured, the end 336 node SHOULD keep refreshing both working and protecting LSPs 337 regardless of failure or preempted situation. 339 5.5. Notifying Availability of Shared Resources 341 When a lower priority protecting LSP is preempted, the intermediate 342 node that performed preemption MUST send a Notify message with error 343 code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared 344 resources unavailable" (TBA1) to the end nodes of that protecting 345 LSP. Upon receipt of this Notify message, the end node MUST stop 346 sending and selecting normal traffic to/from its protecting LSP and 347 try switching the traffic to another protection LSP, if available. 349 When the shared resources become unavailable, including a case of the 350 shared resources failure, the same Notify message MUST also be 351 generated by the intermediate node to all the end nodes of the 352 protecting LSPs that have lower SMP preemption priorities than the 353 one that has occupied the shared resources. These end nodes, in case 354 of a failure of the working LSP, MUST avoid trying to switch the 355 traffic to these protection LSPs that have been configured to use the 356 shared resources and try switching the traffic to other protection 357 LSPs, if available. 359 When the shared resources become available, a Notify message with 360 error code "Notify Error" (25) and error sub-code "Shared resources 361 available" (TBA2) MUST be generated by the intermediate node. The 362 recipients of this Notify message are the end nodes of the lower 363 priority protecting LSPs that have been preempted and/or all the end 364 nodes of the protecting LSPs that have lower SMP preemption 365 priorities than the one that does not need the shared resources any 366 more. 368 5.6. SMP APS Configuration 370 SMP relies on APS protocol messages being exchanged between the nodes 371 along the path to activate an SMP protecting LSP. 373 In order to allow exchange of APS protocol messages, an APS channel 374 has to be configured between adjacent nodes along the path of the SMP 375 protecting LSP. This should be done before any SMP protecting LSP 376 has been setup by other means than GMPL signaling which are therefore 377 outside the scope of this document. 379 Depending on the APS protocol message format, the APS protocol may 380 use different identifiers than GMPLS signaling to identify the SMP 381 protecting LSP. 383 Since APS protocol is for further study in [G808.3], it can be 384 assumed that APS message format and identifiers are technology- 385 specific and/or vendor-specific. Therefore, additional requirements 386 for APS configuration are outside the scope of this document. 388 6. Updates to PROTECTION Object 390 GMPLS extension requirements for SMP introduce several updates to the 391 Protection Object (see [RFC4872]). 393 6.1. New Protection Type 395 A new LSP protection type "Shared Mesh Protection" is added in the 396 PROTECTION object. This LSP Protection Type value is applicable to 397 only bidirectional LSPs. 399 LSP (Protection Type) Flags: 401 0x11: Shared Mesh Protection 403 According to the rules defined in Section 14.2 of [RFC4872], all the 404 nodes along an SMP LSP MUST be SMP aware and therefore there are no 405 backward compatibility issues. 407 6.2. Updates on Notification and Operational Bits 409 N bit and O bit in the PROTECTION object as defined in [RFC4872] are 410 also updated to include applicability to SMP. 412 Notification (N): 1 bit 414 When set to 1, this bit indicates that the control plane message 415 exchange is only used for notification during protection 416 switching. When set to 0 (default), it indicates that the control 417 plane message exchanges are used for protection-switching 418 purposes. The N bit is only applicable when the LSP Protection 419 Type Flag is set to either 0x04 (1:N Protection with Extra- 420 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 421 Bidirectional Protection). In SMP, N bit MUST be set to 1. The N 422 bit MUST be set to 0 in any other case. 424 Operational (O): 1 bit 426 When set to 1, this bit indicates that the protecting LSP is 427 carrying the normal traffic after protection switching. The O bit 428 is only applicable when the P bit is set to 1, and the LSP 429 Protection Type Flag is set to either 0x04 (1:N Protection with 430 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 431 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 432 The O bit MUST be set to 0 in any other case. 434 6.3. Preemption Priority 436 The 32-bit Reserved field in the PROTECTION object defined in 437 [RFC4872] is updated as follows: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Reserved | Preempt Prio | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Preemption Priority (Preempt Prio): 8 bit 447 This field indicates the SMP preemption priority of a protecting 448 LSP, when the LSP Protection Type field indicates "Shared Mesh 449 Protection". The SMP preemption priority value is configured at 450 the end nodes of the protecting LSP by a network operator. A 451 lower value has a higher priority. The decision of how many 452 priority levels to be operated in an SMP network is a network 453 operator's choice. 455 7. IANA Considerations 457 IANA maintains a registry called "Resource Reservation Protocol 458 (RSVP) Parameters" with a subregistry called "Error Codes and 459 Globally-Defined Error Value Sub-Codes". Within this subregistry 460 there is a definition of the "Notify Error" error code (25). The 461 definition lists a number of error value sub-codes that may be used 462 with this error code. IANA is requested to allocate further error 463 value sub-codes for use with this error code as described in this 464 document. 466 Value Description Reference 467 ----- ---------------------------- --------------- 468 TBA1 Shared resources unavailable (this document) 469 TBA2 Shared resources available (this document) 471 8. Security Considerations 473 Since this document makes use of the exchange of RSVP messages 474 including a Notify message, the security threats discussed in 475 [RFC4872] also apply to this document. 477 Additionally, it may be possible to cause disruption to traffic on 478 one protecting LSP by targeting a link used by the primary LSP of 479 another, higher priority LSP somewhere completely different in the 480 network. For example, in Figure 1, assume that the preemption 481 priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] 482 and the protecting LSP [H,E,F,G,K] is being used to transport 483 traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be 484 disrupted. To prevent such an additional risk factor, it is 485 important not only to use security mechanisms as discussed in 486 [RFC4872] but also to preserve privacy of information about 487 protecting LSPs within the network. 489 9. Acknowledgements 491 The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram, 492 Tom Petch, and Ines Robles for their valuable comments and 493 suggestions on this document. 495 10. Contributor 497 The following person contributed significantly to the content of this 498 document and should be considered as a co-author. 500 Yuji Tochio 501 Fujitsu 502 Email: tochio@fujitsu.com 504 11. References 506 11.1. Normative References 508 [G808.3] International Telecommunication Union, "Generic protection 509 switching - Shared mesh protection", ITU-T Recommendation 510 G.08.3, October 2012. 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 518 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 519 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 520 . 522 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 523 Switching (GMPLS) Signaling Resource ReserVation Protocol- 524 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 525 DOI 10.17487/RFC3473, January 2003, 526 . 528 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 529 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 530 Recovery Functional Specification", RFC 4426, 531 DOI 10.17487/RFC4426, March 2006, 532 . 534 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 535 Ed., "RSVP-TE Extensions in Support of End-to-End 536 Generalized Multi-Protocol Label Switching (GMPLS) 537 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 538 . 540 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 541 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 542 May 2017, . 544 11.2. Informative References 546 [G873.3] International Telecommunication Union, "Optical transport 547 network - Shared mesh protection", ITU-T Recommendation 548 G.873.3, September 2017. 550 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 551 Profile (MPLS-TP) Survivability Framework", RFC 6372, 552 DOI 10.17487/RFC6372, September 2011, 553 . 555 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 556 Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) 557 Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, 558 December 2014, . 560 Authors' Addresses 562 Jia He 563 Huawei Technologies 564 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District 565 Shenzhen 566 China 568 Email: hejia@huawei.com 570 Italo Busi 571 Huawei Technologies 573 Email: italo.busi@huawei.com 574 Jeong-dong Ryoo 575 ETRI 576 218 Gajeongno 577 Yuseong-gu, Daejeon 34129 578 South Korea 580 Phone: +82-42-860-5384 581 Email: ryoo@etri.re.kr 583 Bin Yeong Yoon 584 ETRI 586 Email: byyun@etri.re.kr 588 Peter Park 589 KT 591 Email: peter.park@kt.com