idnits 2.17.1 draft-ietf-teas-gmpls-resource-sharing-proc-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 == Line 357 has weird spacing: '...ignaled in th...' -- The document date (January 14, 2017) is 2656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 18, 2017 R. Gandhi, Ed. 6 Z. Ali 7 Cisco Systems, Inc. 8 P. Brzozowski 9 ADVA Optical 10 January 14, 2017 12 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and 13 Resource Sharing 14 draft-ietf-teas-gmpls-resource-sharing-proc-07 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 . . . . . . . . . . . . . . . . . 7 81 4.1. Restoration LSP Association . . . . . . . . . . . . . . . 7 82 4.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 8 83 4.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9 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 behaviour, 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], [RFC4873] and [RFC4427]. 164 2.2. Acronyms and Abbreviations 166 GMPLS: Generalized Multi-Protocol Label Switching 168 LSP: An MPLS Label Switched Path 170 MBB: Make Before Break 172 MPLS: Multi-Protocol Label Switching 174 RSVP: Resource ReSerVation Protocol 176 SE: Shared Explicit flag 178 TDM: Time Division Multiplexing 180 TE: Traffic Engineering 182 3. Overview 184 The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and 185 being considered in this document, switches normal traffic to an 186 alternate LSP that is not even partially established only after the 187 working LSP failure occurs. The new alternate route is selected at 188 the LSP head-end node, it may reuse resources of the failed LSP at 189 intermediate nodes and may include additional intermediate nodes 190 and/or links. 192 3.1. Examples of Restoration Schemes 194 Two forms of end-to-end recovery schemes, 1+R restoration and 1+1+R 195 restoration are described in the following sections. Other forms of 196 end-to-end recovery schemes also exist and they can use these 197 signaling techniques. 199 3.1.1. 1+R Restoration 201 One example of the recovery scheme considered in this document is 1+R 202 recovery. The 1+R recovery scheme is exemplified in Figure 1. In 203 this example, a working LSP on path A-B-C-Z is pre-established. 204 Typically after a failure detection and notification on the working 205 LSP, a second LSP on path A-H-I-J-Z is established as a restoration 206 LSP. Unlike a protecting LSP which is set up before the failure, a 207 restoration LSP is set up per need basis, after the failure. 209 +-----+ +-----+ +-----+ +-----+ 210 | A +----+ B +-----+ C +-----+ Z | 211 +--+--+ +-----+ +-----+ +--+--+ 212 \ / 213 \ / 214 +--+--+ +-----+ +--+--+ 215 | H +-------+ I +--------+ J | 216 +-----+ +-----+ +-----+ 218 Figure 1: An Example of 1+R Recovery Scheme 220 During failure switchover with 1+R recovery scheme, in general, 221 working LSP resources are not released so that working and 222 restoration LSPs coexist in the network. Nonetheless, working and 223 restoration LSPs can share network resources. Typically when the 224 failure has recovered on the working LSP, the restoration LSP is no 225 longer required and is torn down while the traffic is reverted to the 226 original working LSP. 228 3.1.2. 1+1+R Restoration 230 Another example of the recovery scheme considered in this document is 231 1+1+R. In 1+1+R, a restoration LSP is set up for the working LSP 232 and/or the protecting LSP after the failure has been detected, and 233 this recovery scheme is exemplified in Figure 2. 235 +-----+ +-----+ +-----+ 236 | D +-------+ E +--------+ F | 237 +--+--+ +-----+ +--+--+ 238 / \ 239 / \ 240 +--+--+ +-----+ +-----+ +--+--+ 241 | A +----+ B +-----+ C +-----+ Z | 242 +--+--+ +-----+ +-----+ +--+--+ 243 \ / 244 \ / 245 +--+--+ +-----+ +--+--+ 246 | H +-------+ I +--------+ J | 247 +-----+ +-----+ +-----+ 249 Figure 2: An Example of 1+1+R Recovery Scheme 251 In this example, a working LSP on path A-B-C-Z and a protecting LSP 252 on path A-D-E-F-Z are pre-established. After a failure detection and 253 notification on the working LSP or protecting LSP, a third LSP on 254 path A-H-I-J-Z is established as a restoration LSP. The restoration 255 LSP in this case provides protection against failure of both the 256 working and protecting LSPs. During failure switchover with 1+1+R 257 recovery scheme, in general, failed LSP resources are not released so 258 that working, protecting and restoration LSPs coexist in the network. 259 The restoration LSP can share network resources with the working 260 LSP, and it can share network resources with the protecting LSP. 261 Typically, the restoration LSP is torn down when the traffic is 262 reverted to the original LSP and it is no longer needed. 264 There are two possible models when using a restoration LSP with 1+1+R 265 recovery scheme: 267 o A restoration LSP is set up after either a working or protecting 268 LSP fails. Only one restoration LSP is present at a time. 270 o A restoration LSP is set up after both working and protecting LSPs 271 fail. Only one restoration LSP is present at a time. 273 3.1.2.1. 1+1+R Restoration - Variants 275 Two other possible variants exist when using a restoration LSP with 276 1+1+R recovery scheme: 278 o A restoration LSP is set up after either a working or protecting 279 LSP fails. Two different restoration LSPs may be present, one for 280 the working LSP and one for the protecting LSP. 282 o Two different restoration LSPs are set up after both working and 283 protecting LSPs fail, one for the working LSP and one for the 284 protecting LSP. 286 In all these models, if a restoration LSP also fails, it is torn down 287 and a new restoration LSP is set up. 289 3.2. Resource Sharing By Restoration LSP 291 +-----+ +-----+ 292 | F +------+ G +--------+ 293 +--+--+ +-----+ | 294 | | 295 | | 296 +-----+ +-----+ +--+--+ +-----+ +--+--+ 297 | A +----+ B +-----+ C +--X---+ D +-----+ E | 298 +-----+ +-----+ +-----+ +-----+ +-----+ 300 Figure 3: Resource Sharing in 1+R Recovery Scheme 302 Using the network shown in Figure 3 as an example using 1+R recovery 303 scheme, LSP1 (A-B-C-D-E) is the working LSP, and assume it allows for 304 resource sharing when the LSP traffic is dynamically restored. Upon 305 detecting the failure of a link along the LSP1, e.g. Link C-D, node A 306 needs to decide which alternative path it will use to signal 307 restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is 308 chosen as the restoration LSP path and the resources on the path 309 segment A-B-C are re-used by this LSP. The working LSP is not torn 310 down and co-exists with the restoration LSP. Nodes A and B 311 reconfigure the resources to set up the restoration LSP by sending 312 cross-connection command to the data plane. 314 In the recovery scheme employing revertive behavior, after the 315 failure is repaired, the resources on nodes A and B need to be 316 reconfigured to set up the working LSP. The traffic is then reverted 317 back to the original working LSP. 319 4. RSVP-TE Signaling Procedure 321 4.1. Restoration LSP Association 323 Where GMPLS end-to-end recovery scheme needs to employ a restoration 324 LSP while keeping resources for the working and/or protecting LSPs 325 reserved in the network after the failure, the restoration LSP is set 326 up with an ASSOCIATION object that has Association Type set to 327 "Recovery" [RFC4872], the Association ID and the Association Source 328 set to the corresponding Association ID and the Association Source 329 signaled in the Path message of the LSP it is restoring. For 330 example, when a restoration LSP is signaled for a failed working LSP, 331 the ASSOCIATION object in the Path message of the restoration LSP 332 contains the Association ID and Association Source set to the 333 Association ID and Association Source signaled in the working LSP for 334 the "Recovery" Association Type. Similarly, when a restoration LSP 335 is set up for a failed protecting LSP, the ASSOCIATION object in the 336 Path message of the restoration LSP contains the Association ID and 337 Association Source set to the Association ID and Association Source 338 signaled in the protecting LSP for the "Recovery" Association Type. 340 The procedure for signaling the PROTECTION object is specified in 341 [RFC4872]. Specifically, the restoration LSP used for a working LSP 342 is set up with P bit cleared in the PROTECTION object in the Path 343 message of the restoration LSP and the restoration LSP used for a 344 protecting LSP is set up with P bit set in the PROTECTION object in 345 the Path message of the restoration LSP. 347 4.2. Resource Sharing-based Restoration LSP Setup 349 GMPLS LSPs can share resources during LSP setup if they have Shared 350 Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [RFC3209] in 351 the Path messages that create them and: 353 o As defined in [RFC3209], LSPs have identical SESSION objects 354 and/or 356 o As defined in [RFC6689], LSPs have matching ASSOCIATION object 357 with Association Type set to "Resource Sharing" signaled in their 358 Path messages. LSPs in this case can have different SESSION 359 objects i.e. different Tunnel ID, Source and/or Destination 360 signaled in their Path messages. 362 As described in [RFC3209], Section 2.5, the purpose of make-before- 363 break is not to disrupt traffic, or adversely impact network 364 operations while TE tunnel rerouting is in progress. In non-packet 365 transport networks during the RSVP-TE signaling procedure, the nodes 366 set up cross-connections along the LSP accordingly. Because the 367 cross-connection cannot simultaneously connect a shared resource to 368 different resources in two alternative LSPs, nodes may not be able to 369 fulfill this request when LSPs share resources. 371 For LSP restoration upon failure, as explained in Section 11 of 372 [RFC4872], the reroute procedure may re-use existing resources. The 373 action of the intermediate nodes during the rerouting process to 374 reconfigure cross-connections does not further impact the traffic 375 since it has been interrupted due to the already failed LSP. 377 The node actions for setting up the restoration LSP can be 378 categorized into the following: 380 -----------------------------------+--------------------------------- 381 | Category | Action | 382 -----------------------------------+--------------------------------- 383 | Reusing existing resource on | This type of node needs to | 384 | both input and output interfaces | reserve the existing resources | 385 | (nodes A & B in Figure 3). | and no cross-connection | 386 | | command is needed. | 387 -----------------------------------+--------------------------------- 388 | Reusing existing resource only | This type of node needs to | 389 | on one of the interfaces, either | reserve the resources and send | 390 | input or output interfaces and | the re-configuration | 391 | using new resource on the | cross-connection command to its| 392 | other interfaces. | corresponding data plane | 393 | (nodes C & E in Figure 3). | node on the interfaces where | 394 | | new resources are needed and | 395 | | it needs to re-use the existing| 396 | | resources on the other | 397 | | interfaces. | 398 -----------------------------------+--------------------------------- 399 | Using new resources on both | This type of node needs to | 400 | interfaces. | reserve the new resources | 401 | (nodes F & G in Figure 3). | and send the cross-connection | 402 | | command on both interfaces. | 403 -----------------------------------+--------------------------------- 405 Table 1: Node Actions During Restoration LSP Setup 407 Depending on whether the resource is re-used or not, the node actions 408 differ. This deviates from normal LSP setup since some nodes do not 409 need to re-configure the cross-connection. Also, the judgment 410 whether the control plane node needs to send a cross-connection setup 411 or modification command to its corresponding data plane node(s) 412 relies on the check whether the LSPs are sharing resources. 414 4.3. LSP Reversion 416 If the end-to-end LSP recovery scheme employs the revertive behavior, 417 as described in Section 3 of this document, traffic can be reverted 418 from the restoration LSP to the working or protecting LSP after its 419 failure is recovered. The LSP reversion can be achieved using two 420 methods: 422 1. Make-while-break Reversion, where resources associated with a 423 working or protecting LSP are reconfigured while removing 424 reservations for the restoration LSP. 426 2. Make-before-break Reversion, where resources associated with a 427 working or protecting LSP are reconfigured before removing 428 reservations for the restoration LSP. 430 In non-packet transport networks, both of the above reversion methods 431 will result in some traffic disruption when the restoration LSP and 432 the LSP being restored are sharing resources and the 433 cross-connections need to be reconfigured on intermediate nodes. 435 4.3.1. Make-while-break Reversion 437 In this reversion method, restoration LSP is simply requested to be 438 deleted by the head-end. Removing reservations for restoration LSP 439 triggers reconfiguration of resources associated with a working or 440 protecting LSP on every node where resources are shared. The working 441 or protecting LSP state was not removed from the nodes when the 442 failure occurred. Whenever reservation for restoration LSP is 443 removed from a node, data plane configuration changes to reflect 444 reservations of working or protecting LSP as signaling progresses. 445 Eventually, after the whole restoration LSP is deleted, data plane 446 configuration will fully match working or protecting LSP reservations 447 on the whole path. Thus reversion is complete. 449 Make-while-break, while being relatively simple in its logic, has a 450 few limitations as follows which may not be acceptable in some 451 networks: 453 o No rollback 455 If for some reason reconfiguration of data plane on one of the nodes 456 to match working or protecting LSP reservations fails, falling back 457 to restoration LSP is no longer an option, as its state might have 458 already been removed from other nodes. 460 o No completion guarantee 462 Deletion of an LSP provides no guarantees of completion. In 463 particular, if RSVP packets are lost due to a node or link failure it 464 is possible for an LSP to be only partially deleted. To mitigate 465 this, RSVP could maintain soft state reservations and hence 466 eventually remove remaining reservations due to refresh timeouts. 467 This approach is not feasible in non-packet transport networks 468 however, where control and data channels are often separated and 469 hence soft state reservations are not useful. 471 Finally, one could argue that graceful LSP deletion [RFC3473] would 472 provide guarantee of completion. While this is true for most cases, 473 many implementations will time out graceful deletion if LSP is not 474 removed within certain amount of time, e.g. due to a transit node 475 fault. After that, deletion procedures which provide no completion 476 guarantees will be attempted. Hence, in corner cases a completion 477 guarantee cannot be provided. 479 o No explicit notification of completion to head-end node 481 In some cases, it may be useful for a head-end node to know when the 482 data plane has been reconfigured to match working or protecting LSP 483 reservations. This knowledge could be used for initiating operations 484 like enabling alarm monitoring, power equalization and others. 485 Unfortunately, for the reasons mentioned above, make-while-break 486 reversion lacks such explicit notification. 488 4.3.2. Make-before-break Reversion 490 This reversion method can be used to overcome limitations of 491 make-while-break reversion. It is similar in spirit to MBB concept 492 used for re-optimization. Instead of relying on deletion of the 493 restoration LSP, the head-end chooses to establish a new reversion 494 LSP that duplicates the configuration of the resources on the working 495 or protecting LSP, and uses identical ASSOCIATION and PROTECTION 496 objects in the Path message of that LSP. Only if setup of this LSP 497 is successful will other (restoration and working or protecting) LSPs 498 be deleted by the head-end. MBB reversion consists of two parts: 500 A) Make part: 502 Creating a new reversion LSP following working or protecting LSP's 503 path. The reversion LSP shares all of the resources of the working 504 or protecting LSP and may share resources with the restoration LSP. 505 As reversion LSP is created, resources are reconfigured to match its 506 reservations. Hence, after reversion LSP is created, data plane 507 configuration reflects working or protecting LSP reservations. 509 B) Break part: 511 After "make" part is finished, the original working or protecting and 512 restoration LSPs are torn down, and the reversion LSP becomes the new 513 working or protecting LSP. Removing reservations for working or 514 restoration LSPs does not cause any resource reconfiguration on 515 reversion LSP's path - nodes follow same procedures as for "break" 516 part of any MBB operation. Hence, after working or protecting and 517 restoration LSPs are removed, data plane configuration is exactly the 518 same as before starting restoration. Thus, reversion is complete. 520 MBB reversion uses make-before-break characteristics to overcome 521 challenges related to make-while-break reversion as follow: 523 o Rollback 525 If "make" part fails, (existing) restoration LSP will still be used 526 to carry existing traffic as the restoration LSP state was not 527 removed. Same logic applies here as for any MBB operation failure. 529 o Completion guarantee 531 LSP setup is resilient against RSVP message loss, as Path and Resv 532 messages are refreshed periodically. Hence, given that network 533 recovers from node and link failures eventually, reversion LSP setup 534 is guaranteed to finish with either success or failure. 536 o Explicit notification of completion to head-end node 538 Head-end knows that data plane has been reconfigured to match working 539 or protecting LSP reservations on intermediate nodes when it receives 540 Resv for the reversion LSP. 542 5. Security Considerations 544 This document reviews procedures defined in [RFC3209] [RFC4872] 545 [RFC4873] and [RFC6689] and does not define any new procedure. This 546 document does not introduce any new security issues other than those 547 already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. 549 6. IANA Considerations 551 This informational document does not make any request for IANA 552 action. 554 7. References 556 7.1. Normative References 558 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 559 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 560 Tunnels", RFC 3209, December 2001. 562 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 563 Switching (GMPLS) Signaling Resource ReserVation 564 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 565 3473, January 2003. 567 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 568 Ed., "RSVP-TE Extensions in Support of End-to-End 569 Generalized Multi-Protocol Label Switching (GMPLS) 570 Recovery", RFC 4872, May 2007. 572 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 573 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 575 [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 576 6689, July 2012. 578 7.2. Informative References 580 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 581 (GMPLS) Architecture", RFC 3945, October 2004. 583 [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in 584 Support of Generalized Multi-Protocol Label Switching 585 (GMPLS)", RFC 4203, October 2005. 587 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 588 "Generalized Multiprotocol Label Switching (GMPLS) 589 Recovery Functional Specification", RFC 4426, March 2006. 591 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 592 and Restoration) Terminology for Generalized 593 Multi-Protocol Label Switching", RFC 4427, March 2006. 595 Acknowledgements 597 The authors would like to thank George Swallow for the discussions on 598 the GMPLS restoration. The authors would like to thank Lou Berger 599 for the guidance on this work. The authors would also like to thank 600 Lou Berger, Vishnu Pavan Beeram and Christian Hopps for reviewing 601 this document and providing valuable comments. 603 Contributors 605 Gabriele Maria Galimberti 606 Cisco Systems, Inc. 608 EMail: ggalimbe@cisco.com 610 Authors' Addresses 612 Xian Zhang 613 Huawei Technologies 614 F3-1-B R&D Center, Huawei Base 615 Bantian, Longgang District 616 Shenzhen 518129 P.R.China 618 EMail: zhang.xian@huawei.com 620 Haomian Zheng (editor) 621 Huawei Technologies 622 F3-1-B R&D Center, Huawei Base 623 Bantian, Longgang District 624 Shenzhen 518129 P.R.China 626 EMail: zhenghaomian@huawei.com 628 Rakesh Gandhi (editor) 629 Cisco Systems, Inc. 631 EMail: rgandhi@cisco.com 633 Zafar Ali 634 Cisco Systems, Inc. 636 EMail: zali@cisco.com 638 Pawel Brzozowski 639 ADVA Optical 641 EMail: PBrzozowski@advaoptical.com