idnits 2.17.00 (12 Aug 2021) /tmp/idnits9624/draft-ietf-teas-gmpls-resource-sharing-proc-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 (January 26, 2017) is 1934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group X. Zhang 3 Internet-Draft H. Zheng, Ed. 4 Intended Status: Informational Huawei Technologies 5 Expires: July 30, 2017 R. Gandhi, Ed. 6 Z. Ali 7 Cisco Systems, Inc. 8 P. Brzozowski 9 ADVA Optical 10 January 26, 2017 12 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and 13 Resource Sharing 14 draft-ietf-teas-gmpls-resource-sharing-proc-08 16 Abstract 18 In non-packet transport networks, there are requirements where 19 Generalized Multi-Protocol Label Switching (GMPLS) end-to-end 20 recovery scheme needs to employ restoration Label Switched Path (LSP) 21 while keeping resources for the working and/or protecting LSPs 22 reserved in the network after the failure occurs. 24 This document reviews how the LSP association is to be provided using 25 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 26 signaling in the context of GMPLS end-to-end recovery scheme when 27 using restoration LSP where failed LSP is not torn down. In 28 addition, this document discusses resource sharing-based setup and 29 teardown of LSPs as well as LSP reversion procedures. No new 30 signaling extensions are defined by this document, and it is strictly 31 informative in nature. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 72 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4 74 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Examples of Restoration Schemes . . . . . . . . . . . . . 5 76 3.1.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . 5 77 3.1.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . 5 78 3.1.2.1. 1+1+R Restoration - Variants . . . . . . . . . . . 6 79 3.2. Resource Sharing by Restoration LSP . . . . . . . . . . . 7 80 4. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 8 81 4.1. Restoration LSP Association . . . . . . . . . . . . . . . 8 82 4.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 8 83 4.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 10 84 4.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 10 85 4.3.2. Make-before-break Reversion . . . . . . . . . . . . . 11 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines 98 a set of protocols, including Open Shortest Path First - Traffic 99 Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 100 Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used 101 to set up Label Switched Paths (LSPs) in non-packet transport 102 networks. The GMPLS protocol extends MPLS to support interfaces 103 capable of Time Division Multiplexing (TDM), Lambda Switching and 104 Fiber Switching. These switching technologies provide several 105 protection schemes [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). 107 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 108 signaling has been extended to support various GMPLS recovery 109 schemes, such as end-to-end recovery [RFC4872] and segment recovery 110 [RFC4873]. As described in [RFC6689], an ASSOCIATION object with 111 Association Type "Recovery" [RFC4872] can be signaled in the RSVP 112 Path message to identify the LSPs for restoration. Also, an 113 ASSOCIATION object with Association Type "Resource Sharing" [RFC4873] 114 can be signaled in the RSVP Path message to identify the LSPs for 115 resource sharing. [RFC6689] Section 2.2 reviews the procedure for 116 providing LSP associations for GMPLS end-to-end recovery and Section 117 2.4 reviews the procedure for providing LSP associations for sharing 118 resources. 120 Generally GMPLS end-to-end recovery schemes have the restoration LSP 121 set up after the failure has been detected and notified on the 122 working LSP. For recovery scheme with revertive behavior, a 123 restoration LSP is set up while working LSP and/or protecting LSP are 124 not torn down in control plane due to a failure. In non-packet 125 transport networks, as working LSPs are typically set up over 126 preferred paths, service providers would like to keep resources 127 associated with the working LSPs reserved. This is to make sure that 128 the service can be reverted to the preferred path (working LSP) when 129 the failure is repaired to provide deterministic behavior and 130 guaranteed Service Level Agreement (SLA). 132 In this document, we review procedures for GMPLS LSP associations, 133 resource sharing based LSP setup, teardown, and LSP reversion for 134 non-packet transport networks, including the following: 136 o Review the procedure for providing LSP associations for the GMPLS 137 end-to-end recovery using restoration LSP where working and 138 protecting LSPs are not torn down and resources are kept reserved 139 in the network after the failure. 141 o In [RFC3209], the make-before-break (MBB) method assumes the old 142 and new LSPs share the SESSION object and signal Shared Explicit 143 (SE) flag in SESSION_ATTRIBUTE object for sharing resources. 144 According to [RFC6689], an ASSOCIATION object with Association 145 Type "Resource Sharing" in the Path message enables the sharing of 146 resources across LSPs with different SESSION objects. The 147 procedure for resource sharing using the SE flag in conjunction 148 with an ASSOCIATION object is discussed in this document. 150 o When using end-to-end recovery scheme with revertive behavior, 151 methods for LSP reversion and resource sharing are summarized in 152 this document. 154 This document is strictly informative in nature and does not define 155 any RSVP-TE signaling extensions. 157 2. Conventions Used in This Document 159 2.1. Terminology 161 The reader is assumed to be familiar with the terminology in 162 [RFC3209], [RFC3473], [RFC4872] and [RFC4873]. The terminology for 163 GMPLS recovery is defined in [RFC4427]. 165 2.2. Acronyms and Abbreviations 167 GMPLS: Generalized Multi-Protocol Label Switching 169 LSP: An MPLS Label Switched Path 171 MBB: Make Before Break 173 MPLS: Multi-Protocol Label Switching 175 RSVP: Resource ReSerVation Protocol 177 SE: Shared Explicit flag 179 TDM: Time Division Multiplexing 181 TE: Traffic Engineering 183 3. Overview 185 The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and 186 being considered in this document, switches normal traffic to an 187 alternate LSP that is not even partially established only after the 188 working LSP failure occurs. The new alternate route is selected at 189 the LSP head-end node, it may reuse resources of the failed LSP at 190 intermediate nodes and may include additional intermediate nodes 191 and/or links. 193 3.1. Examples of Restoration Schemes 195 Two forms of end-to-end recovery schemes, 1+R restoration and 1+1+R 196 restoration are described in the following sections. Other forms of 197 end-to-end recovery schemes also exist and they can use these 198 signaling techniques. 200 3.1.1. 1+R Restoration 202 One example of the recovery scheme considered in this document is 1+R 203 recovery. The 1+R recovery scheme is exemplified in Figure 1. In 204 this example, a working LSP on path A-B-C-Z is pre-established. 205 Typically after a failure detection and notification on the working 206 LSP, a second LSP on path A-H-I-J-Z is established as a restoration 207 LSP. Unlike a protecting LSP which is set up before the failure, a 208 restoration LSP is set up when needed, after the failure. 210 +-----+ +-----+ +-----+ +-----+ 211 | A +----+ B +-----+ C +-----+ Z | 212 +--+--+ +-----+ +-----+ +--+--+ 213 \ / 214 \ / 215 +--+--+ +-----+ +--+--+ 216 | H +-------+ I +--------+ J | 217 +-----+ +-----+ +-----+ 219 Figure 1: An Example of 1+R Recovery Scheme 221 During failure switchover with 1+R recovery scheme, in general, 222 working LSP resources are not released so that working and 223 restoration LSPs coexist in the network. Nonetheless, working and 224 restoration LSPs can share network resources. Typically when the 225 failure has recovered on the working LSP, the restoration LSP is no 226 longer required and is torn down while the traffic is reverted to the 227 original working LSP. 229 3.1.2. 1+1+R Restoration 231 Another example of the recovery scheme considered in this document is 232 1+1+R. In 1+1+R, a restoration LSP is set up for the working LSP 233 and/or the protecting LSP after the failure has been detected, and 234 this recovery scheme is exemplified in Figure 2. 236 +-----+ +-----+ +-----+ 237 | D +-------+ E +--------+ F | 238 +--+--+ +-----+ +--+--+ 239 / \ 240 / \ 241 +--+--+ +-----+ +-----+ +--+--+ 242 | A +----+ B +-----+ C +-----+ Z | 243 +--+--+ +-----+ +-----+ +--+--+ 244 \ / 245 \ / 246 +--+--+ +-----+ +--+--+ 247 | H +-------+ I +--------+ J | 248 +-----+ +-----+ +-----+ 250 Figure 2: An Example of 1+1+R Recovery Scheme 252 In this example, a working LSP on path A-B-C-Z and a protecting LSP 253 on path A-D-E-F-Z are pre-established. After a failure detection and 254 notification on the working LSP or protecting LSP, a third LSP on 255 path A-H-I-J-Z is established as a restoration LSP. The restoration 256 LSP in this case provides protection against failure of both the 257 working and protecting LSPs. During failure switchover with 1+1+R 258 recovery scheme, in general, failed LSP resources are not released so 259 that working, protecting and restoration LSPs coexist in the network. 260 The restoration LSP can share network resources with the working 261 LSP, and it can share network resources with the protecting LSP. 262 Typically, the restoration LSP is torn down when the traffic is 263 reverted to the original LSP and it is no longer needed. 265 There are two possible models when using a restoration LSP with 1+1+R 266 recovery scheme: 268 o A restoration LSP is set up after either a working or protecting 269 LSP fails. Only one restoration LSP is present at a time. 271 o A restoration LSP is set up after both working and protecting LSPs 272 fail. Only one restoration LSP is present at a time. 274 3.1.2.1. 1+1+R Restoration - Variants 276 Two other possible variants exist when using a restoration LSP with 277 1+1+R recovery scheme: 279 o A restoration LSP is set up after either a working or protecting 280 LSP fails. Two different restoration LSPs may be present, one for 281 the working LSP and one for the protecting LSP. 283 o Two different restoration LSPs are set up after both working and 284 protecting LSPs fail, one for the working LSP and one for the 285 protecting LSP. 287 In all these models, if a restoration LSP also fails, it is torn down 288 and a new restoration LSP is set up. 290 3.2. Resource Sharing by Restoration LSP 292 +-----+ +-----+ 293 | F +------+ G +--------+ 294 +--+--+ +-----+ | 295 | | 296 | | 297 +-----+ +-----+ +--+--+ +-----+ +--+--+ 298 | A +----+ B +-----+ C +--X---+ D +-----+ E | 299 +-----+ +-----+ +-----+ +-----+ +-----+ 301 Figure 3: Resource Sharing in 1+R Recovery Scheme 303 Using the network shown in Figure 3 as an example using 1+R recovery 304 scheme, LSP1 (A-B-C-D-E) is the working LSP, and assume it allows for 305 resource sharing when the LSP traffic is dynamically restored. Upon 306 detecting the failure of a link along the LSP1, e.g. Link C-D, node A 307 needs to decide which alternative path it will use to signal 308 restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is 309 chosen as the restoration LSP path and the resources on the path 310 segment A-B-C are re-used by this LSP. The working LSP is not torn 311 down and co-exists with the restoration LSP. When the head-end node 312 A signals the restoration LSP, nodes C, F, G and E reconfigure the 313 resources (as listed in Table 1 of this document) to set up the LSP 314 by sending cross-connection command to the data plane. 316 In the recovery scheme employing revertive behavior, after the 317 failure is repaired, the resources on nodes C and E need to be 318 reconfigured to set up the working LSP (using a procedure described 319 in Section 4.3 of this document) by sending cross-connection command 320 to the data plane. The traffic is then reverted back to the original 321 working LSP. 323 4. RSVP-TE Signaling Procedure 325 4.1. Restoration LSP Association 327 Where GMPLS end-to-end recovery scheme needs to employ a restoration 328 LSP while keeping resources for the working and/or protecting LSPs 329 reserved in the network after the failure, the restoration LSP is set 330 up with an ASSOCIATION object that has Association Type set to 331 "Recovery" [RFC4872], the Association ID and the Association Source 332 set to the corresponding Association ID and the Association Source 333 signaled in the Path message of the LSP it is restoring. For 334 example, when a restoration LSP is signaled for a failed working LSP, 335 the ASSOCIATION object in the Path message of the restoration LSP 336 contains the Association ID and Association Source set to the 337 Association ID and Association Source signaled in the working LSP for 338 the "Recovery" Association Type. Similarly, when a restoration LSP 339 is set up for a failed protecting LSP, the ASSOCIATION object in the 340 Path message of the restoration LSP contains the Association ID and 341 Association Source set to the Association ID and Association Source 342 signaled in the protecting LSP for the "Recovery" Association Type. 344 The procedure for signaling the PROTECTION object is specified in 345 [RFC4872]. Specifically, the restoration LSP used for a working LSP 346 is set up with P bit cleared in the PROTECTION object in the Path 347 message of the restoration LSP and the restoration LSP used for a 348 protecting LSP is set up with P bit set in the PROTECTION object in 349 the Path message of the restoration LSP. 351 4.2. Resource Sharing-based Restoration LSP Setup 353 GMPLS LSPs can share resources during LSP setup if they have Shared 354 Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [RFC3209] in 355 the Path messages that create them and: 357 o As defined in [RFC3209], LSPs have identical SESSION objects 358 and/or 360 o As defined in [RFC6689], LSPs have matching ASSOCIATION object 361 with Association Type set to "Resource Sharing" signaled in their 362 Path messages. LSPs in this case can have different SESSION 363 objects i.e. different Tunnel ID, Source and/or Destination 364 signaled in their Path messages. 366 As described in [RFC3209], Section 2.5, the purpose of make-before- 367 break is not to disrupt traffic, or adversely impact network 368 operations while TE tunnel rerouting is in progress. In non-packet 369 transport networks during the RSVP-TE signaling procedure, the nodes 370 set up cross-connections along the LSP accordingly. Because the 371 cross-connection cannot simultaneously connect a shared resource to 372 different resources in two alternative LSPs, nodes may not be able to 373 fulfill this request when LSPs share resources. 375 For LSP restoration upon failure, as explained in Section 11 of 376 [RFC4872], the reroute procedure may re-use existing resources. The 377 action of the intermediate nodes during the rerouting process to 378 reconfigure cross-connections does not further impact the traffic 379 since it has been interrupted due to the already failed LSP. 381 The node actions for setting up the restoration LSP can be 382 categorized into the following: 384 -----------------------------------+--------------------------------- 385 | Category | Action | 386 -----------------------------------+--------------------------------- 387 | Reusing existing resource on | This type of node needs to | 388 | both input and output interfaces | reserve the existing resources | 389 | (nodes A & B in Figure 3). | and no cross-connection | 390 | | command is needed. | 391 -----------------------------------+--------------------------------- 392 | Reusing existing resource only | This type of node needs to | 393 | on one of the interfaces, either | reserve the resources and send | 394 | input or output interfaces and | the re-configuration | 395 | using new resource on the | cross-connection command to its| 396 | other interfaces. | corresponding data plane | 397 | (nodes C & E in Figure 3). | node on the interfaces where | 398 | | new resources are needed and | 399 | | it needs to re-use the existing| 400 | | resources on the other | 401 | | interfaces. | 402 -----------------------------------+--------------------------------- 403 | Using new resources on both | This type of node needs to | 404 | interfaces. | reserve the new resources | 405 | (nodes F & G in Figure 3). | and send the cross-connection | 406 | | command on both interfaces. | 407 -----------------------------------+--------------------------------- 409 Table 1: Node Actions During Restoration LSP Setup 411 Depending on whether the resource is re-used or not, the node actions 412 differ. This deviates from normal LSP setup since some nodes do not 413 need to re-configure the cross-connection. Also, the judgment 414 whether the control plane node needs to send a cross-connection setup 415 or modification command to its corresponding data plane node(s) 416 relies on the check whether the LSPs are sharing resources. 418 4.3. LSP Reversion 420 If the end-to-end LSP recovery scheme employs the revertive behavior, 421 as described in Section 3 of this document, traffic can be reverted 422 from the restoration LSP to the working or protecting LSP after its 423 failure is recovered. The LSP reversion can be achieved using two 424 methods: 426 1. Make-while-break Reversion, where resources associated with a 427 working or protecting LSP are reconfigured while removing 428 reservations for the restoration LSP. 430 2. Make-before-break Reversion, where resources associated with a 431 working or protecting LSP are reconfigured before removing 432 reservations for the restoration LSP. 434 In non-packet transport networks, both of the above reversion methods 435 will result in some traffic disruption when the restoration LSP and 436 the LSP being restored are sharing resources and the 437 cross-connections need to be reconfigured on intermediate nodes. 439 4.3.1. Make-while-break Reversion 441 In this reversion method, restoration LSP is simply requested to be 442 deleted by the head-end. Removing reservations for restoration LSP 443 triggers reconfiguration of resources associated with a working or 444 protecting LSP on every node where resources are shared. The working 445 or protecting LSP state was not removed from the nodes when the 446 failure occurred. Whenever reservation for restoration LSP is 447 removed from a node, data plane configuration changes to reflect 448 reservations of working or protecting LSP as signaling progresses. 449 Eventually, after the whole restoration LSP is deleted, data plane 450 configuration will fully match working or protecting LSP reservations 451 on the whole path. Thus reversion is complete. 453 Make-while-break, while being relatively simple in its logic, has a 454 few limitations as follows which may not be acceptable in some 455 networks: 457 o No rollback 459 If for some reason reconfiguration of data plane on one of the nodes 460 to match working or protecting LSP reservations fails, falling back 461 to restoration LSP is no longer an option, as its state might have 462 already been removed from other nodes. 464 o No completion guarantee 465 Deletion of an LSP provides no guarantees of completion. In 466 particular, if RSVP packets are lost due to a node or link failure it 467 is possible for an LSP to be only partially deleted. To mitigate 468 this, RSVP could maintain soft state reservations and hence 469 eventually remove remaining reservations due to refresh timeouts. 470 This approach is not feasible in non-packet transport networks 471 however, where control and data channels are often separated and 472 hence soft state reservations are not useful. 474 Finally, one could argue that graceful LSP deletion [RFC3473] would 475 provide guarantee of completion. While this is true for most cases, 476 many implementations will time out graceful deletion if LSP is not 477 removed within certain amount of time, e.g. due to a transit node 478 fault. After that, deletion procedures which provide no completion 479 guarantees will be attempted. Hence, in corner cases a completion 480 guarantee cannot be provided. 482 o No explicit notification of completion to head-end node 484 In some cases, it may be useful for a head-end node to know when the 485 data plane has been reconfigured to match working or protecting LSP 486 reservations. This knowledge could be used for initiating operations 487 like enabling alarm monitoring, power equalization and others. 488 Unfortunately, for the reasons mentioned above, make-while-break 489 reversion lacks such explicit notification. 491 4.3.2. Make-before-break Reversion 493 This reversion method can be used to overcome limitations of 494 make-while-break reversion. It is similar in spirit to MBB concept 495 used for re-optimization. Instead of relying on deletion of the 496 restoration LSP, the head-end chooses to establish a new reversion 497 LSP that duplicates the configuration of the resources on the working 498 or protecting LSP, and uses identical ASSOCIATION and PROTECTION 499 objects in the Path message of that LSP. Only if setup of this LSP 500 is successful will other (restoration and working or protecting) LSPs 501 be deleted by the head-end. MBB reversion consists of two parts: 503 A) Make part: 505 Creating a new reversion LSP following working or protecting LSP's 506 path. The reversion LSP shares all of the resources of the working 507 or protecting LSP and may share resources with the restoration LSP. 508 As reversion LSP is created, resources are reconfigured to match its 509 reservations. Hence, after reversion LSP is created, data plane 510 configuration reflects working or protecting LSP reservations. 512 B) Break part: 514 After "make" part is finished, the original working or protecting and 515 restoration LSPs are torn down, and the reversion LSP becomes the new 516 working or protecting LSP. Removing reservations for working or 517 restoration LSPs does not cause any resource reconfiguration on 518 reversion LSP's path - nodes follow same procedures as for "break" 519 part of any MBB operation. Hence, after working or protecting and 520 restoration LSPs are removed, data plane configuration is exactly the 521 same as before starting restoration. Thus, reversion is complete. 523 MBB reversion uses make-before-break characteristics to overcome 524 challenges related to make-while-break reversion as follow: 526 o Rollback 528 If "make" part fails, (existing) restoration LSP will still be used 529 to carry existing traffic as the restoration LSP state was not 530 removed. Same logic applies here as for any MBB operation failure. 532 o Completion guarantee 534 LSP setup is resilient against RSVP message loss, as Path and Resv 535 messages are refreshed periodically. Hence, given that network 536 recovers from node and link failures eventually, reversion LSP setup 537 is guaranteed to finish with either success or failure. 539 o Explicit notification of completion to head-end node 541 Head-end knows that data plane has been reconfigured to match working 542 or protecting LSP reservations on intermediate nodes when it receives 543 Resv for the reversion LSP. 545 5. Security Considerations 547 This document reviews procedures defined in [RFC3209] [RFC4872] 548 [RFC4873] and [RFC6689] and does not define any new procedure. This 549 document does not introduce any new security issues other than those 550 already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. 552 6. IANA Considerations 554 This informational document does not make any request for IANA 555 action. 557 7. References 559 7.1. Normative References 561 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 562 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 563 Tunnels", RFC 3209, December 2001. 565 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 566 Switching (GMPLS) Signaling Resource ReserVation 567 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 568 3473, January 2003. 570 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 571 Ed., "RSVP-TE Extensions in Support of End-to-End 572 Generalized Multi-Protocol Label Switching (GMPLS) 573 Recovery", RFC 4872, May 2007. 575 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 576 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 578 [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 579 6689, July 2012. 581 7.2. Informative References 583 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 584 (GMPLS) Architecture", RFC 3945, October 2004. 586 [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in 587 Support of Generalized Multi-Protocol Label Switching 588 (GMPLS)", RFC 4203, October 2005. 590 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 591 "Generalized Multiprotocol Label Switching (GMPLS) 592 Recovery Functional Specification", RFC 4426, March 2006. 594 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 595 and Restoration) Terminology for Generalized 596 Multi-Protocol Label Switching", RFC 4427, March 2006. 598 Acknowledgements 600 The authors would like to thank George Swallow for the discussions on 601 the GMPLS restoration. The authors would like to thank Lou Berger 602 for the guidance on this work. The authors would also like to thank 603 Lou Berger, Vishnu Pavan Beeram and Christian Hopps for reviewing 604 this document and providing valuable comments. A special thanks to 605 Dale Worley for his thorough review of this document. 607 Contributors 609 Gabriele Maria Galimberti 610 Cisco Systems, Inc. 612 EMail: ggalimbe@cisco.com 614 Authors' Addresses 616 Xian Zhang 617 Huawei Technologies 618 F3-1-B R&D Center, Huawei Base 619 Bantian, Longgang District 620 Shenzhen 518129 P.R.China 622 EMail: zhang.xian@huawei.com 624 Haomian Zheng (editor) 625 Huawei Technologies 626 F3-1-B R&D Center, Huawei Base 627 Bantian, Longgang District 628 Shenzhen 518129 P.R.China 630 EMail: zhenghaomian@huawei.com 632 Rakesh Gandhi (editor) 633 Cisco Systems, Inc. 635 EMail: rgandhi@cisco.com 637 Zafar Ali 638 Cisco Systems, Inc. 640 EMail: zali@cisco.com 642 Pawel Brzozowski 643 ADVA Optical 645 EMail: PBrzozowski@advaoptical.com