idnits 2.17.1 draft-ietf-teas-gmpls-resource-sharing-proc-01.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 30, 2015) is 3371 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PCEP-RSO' is defined on line 504, but no explicit reference was found in the text 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 Xian Zhang 3 Internet-Draft Haomian Zheng, Ed. 4 Intended Status: Informational Huawei 5 Expires: August 3, 2015 Rakesh Gandhi, Ed. 6 Zafar Ali 7 Gabriele Maria Galimberti 8 Cisco Systems, Inc. 9 Pawel Brzozowski 10 ADVA Optical 11 January 30, 2015 13 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and 14 Resource Sharing 15 draft-ietf-teas-gmpls-resource-sharing-proc-01 17 Abstract 19 In transport networks, there are requirements where Generalized 20 Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme 21 needs to employ restoration Label Switched Path (LSP) while keeping 22 resources for the working and/or protecting LSPs reserved in the 23 network after the failure occurs. 25 This document reviews how the LSP association is to be provided using 26 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 27 signaling in the context of GMPLS end-to-end recovery scheme when 28 using restoration LSP where failed LSP is not torn down. In 29 addition, this document clarifies the RSVP-TE signaling procedure to 30 support resource sharing-based setup and teardown of LSPs as well as 31 LSP reversion. No new extensions are defined by this document, and 32 it is strictly informative in nature. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4 74 2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5 75 2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6 76 3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 6 77 3.1. Restoration LSP Association . . . . . . . . . . . . . . . 6 78 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 79 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 8 80 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 8 81 3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 9 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines 93 a set of protocols, including Open Shortest Path First - Traffic 94 Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 95 Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used 96 to setup Label Switched Paths (LSPs) in transport networks. The 97 GMPLS protocol extends MPLS to support interfaces capable of Time 98 Division Multiplexing (TDM), Lambda Switching and Fiber Switching. 99 These switching technologies provide several protection schemes 100 [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). 102 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 103 signaling has been extended to support various GMPLS recovery 104 schemes, such as end-to-end recovery [RFC4872] and segment recovery 105 [RFC4873]. As described in [RFC6689], ASSOCIATION object can be used 106 to identify the LSPs for restoration using Association Type set to 107 "Recovery" [RFC4872]. [RFC6689] Section 2.2 reviews the procedure 108 for providing LSP associations for GMPLS end-to-end recovery and 109 covers the schemes where the failed working LSP and/or protecting LSP 110 are torn down. 112 In GMPLS end-to-end recovery schemes generally considered, 113 restoration LSP is signaled after the failure has been detected and 114 notified on the working LSP. For revertive recovery mode, a 115 restoration LSP is signaled while working LSP and/or protecting LSP 116 are not torn down in control plane due to a failure. In transport 117 networks, as working LSPs are typically signaled over a nominal path, 118 service providers would like to keep resources associated with the 119 working LSPs reserved. This is to make sure that the service 120 (working LSP) can be reverted to the nominal path when the failure is 121 repaired to provide deterministic behavior and guaranteed Service 122 Level Agreement (SLA). 124 Following behaviors are not fully documented in the existing 125 standards for LSP associations, resource sharing based LSP setup, 126 teardown and LSP reversion in transport networks: 128 o The procedure for providing LSP associations for the GMPLS 129 recovery using restoration LSP where working and protecting LSPs are 130 not torn down after the failure is not clearly documented. 132 o In [RFC3209], the MBB method assumes the old and new LSPs share 133 the SESSION object and signal Shared Explicit (SE) flag in 134 SESSION_ATTRIBUTE object. According to [RFC6689], ASSOCIATION object 135 with Association Type "Resource sharing" enables the sharing of 136 resources across LSPs with different SESSION objects. However, 137 existing documents do not mention the usage of SE flag for resource 138 sharing with ASSOCIATION object. 140 o As described in [RFC3209], Section 2.5, the purpose of make before 141 break (MBB) is "not to disrupt traffic, or adversely impact network 142 operations while TE tunnel rerouting is in progress". In transport 143 networks, the label has a mapping into the data plane resource used 144 and the nodes along the LSP need to send triggering commands to data 145 plane for setting up cross-connections accordingly during the RSVP-TE 146 signaling procedure. Due to the nature of transport networks, node 147 may not be able to fulfill this purpose when sharing resources in 148 some scenarios. 150 o When using end-to-end recovery with revertive mode, methods for 151 LSP reversion and resource sharing have not been described. 153 This document reviews how the LSP association is to be provided for 154 GMPLS end-to-end recovery when using restoration LSP where working 155 and protecting LSP resources are kept reserved in the network after 156 the failure. In addition, this document clarifies the signaling 157 procedure for sharing resources during setup and teardown of LSPs as 158 well as LSP reversion. This document is strictly informative in 159 nature and does not define any RSVP-TE signaling extensions. 161 2. Overview 163 The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and 164 being considered in this document, "fully dynamic rerouting switches 165 normal traffic to an alternate LSP that is not even partially 166 established only after the working LSP failure occurs. The new 167 alternate route is selected at the LSP head-end node, it may reuse 168 resources of the failed LSP at intermediate nodes and may include 169 additional intermediate nodes and/or links". Two examples, 1+R and 170 1+1+R are described in the following sections. 172 2.1. 1+R Restoration 174 One example of the recovery scheme considered in this document is 1+R 175 recovery. The 1+R recovery is exemplified in Figure 1. In this 176 example, working LSP on path A-B-C-Z is pre-established. Typically 177 after a failure detection and notification on the working LSP, a 178 second LSP on path A-H-I-J-Z is established as a restoration LSP. 179 Unlike protection LSP, restoration LSP is signaled per need basis. 181 +-----+ +-----+ +-----+ +-----+ 182 | A +----+ B +-----+ C +-----+ Z | 183 +--+--+ +-----+ +-----+ +--+--+ 184 \ / 185 \ / 186 +--+--+ +-----+ +--+--+ 187 | H +-------+ I +--------+ J | 188 +-----+ +-----+ +-----+ 190 Figure 1: An Example of 1+R Recovery Scheme 192 During failure switchover with 1+R recovery scheme, in general, 193 working LSP resources are not released so that working and 194 restoration LSPs coexist in the network. Nonetheless, working and 195 restoration LSPs can share network resources. Typically when failure 196 is recovered on the working LSP, restoration LSP is no longer 197 required and torn down, while the traffic is reverted to the original 198 working LSP. 200 2.2. 1+1+R Restoration 202 Another example of the recovery scheme considered in this document is 203 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP 204 and/or the protecting LSP after the failure has been detected, and 205 this recovery is exemplified in Figure 2. 207 +-----+ +-----+ +-----+ 208 | D +-------+ E +--------+ F | 209 +--+--+ +-----+ +--+--+ 210 / \ 211 / \ 212 +--+--+ +-----+ +-----+ +--+--+ 213 | A +----+ B +-----+ C +-----+ Z | 214 +--+--+ +-----+ +-----+ +--+--+ 215 \ / 216 \ / 217 +--+--+ +-----+ +--+--+ 218 | H +-------+ I +--------+ J | 219 +-----+ +-----+ +-----+ 221 Figure 2: An Example of 1+1+R Recovery Scheme 223 In this example, working LSP on path A-B-C-Z and protecting LSP on 224 path A-D-E-F-Z are pre-established. After a failure detection and 225 notification on a working LSP or protecting LSP, a third LSP on path 226 A-H-I-J-Z is established as a restoration LSP. The restoration LSP 227 in this case provides protection against a second order failure. 229 During failure switchover with 1+1+R recovery scheme, in general, 230 failed LSP resources are not released so that working, protecting and 231 restoration LSPs coexist in the network. Nonetheless, restoration 232 LSP with working LSP it is restoring as well as restoration LSP with 233 protecting LSP it is restoring can share network resources. 234 Typically, restoration LSP is torn down when the failure on the 235 working or protecting LSP is repaired and while the traffic is 236 reverted to the original LSP. 238 2.3. Resource Sharing By Restoration LSP 240 +-----+ +-----+ 241 | F +------+ G +--------+ 242 +--+--+ +-----+ | 243 | | 244 | | 245 +-----+ +-----+ +--+--+ +-----+ +--+--+ 246 | A +----+ B +-----+ C +--X---+ D +-----+ E | 247 +-----+ +-----+ +-----+ +-----+ +-----+ 249 Figure 3: Resource Sharing in 1+R Recovery Scheme 251 Using the network shown in Figure 3 as an example, LSP1 (A-B-C-D-E) 252 is the working LSP and it allows for resource sharing when the LSP is 253 dynamically rerouted due to link failure. Upon detecting the failure 254 of a link along the LSP1, e.g. Link C-D, node A needs to decide which 255 alternative path it will use to signal restoration LSP and reroute 256 traffic. In this case, A-B-C-F-G-E is chosen as the restoration LSP 257 path and the resources on the path segment A-B-C are re-used by this 258 LSP when working LSP is not torn down as in 1+R recovery scheme. 260 3. RSVP-TE Signaling Procedure 262 3.1. Restoration LSP Association 264 Where GMPLS end-to-end recovery scheme needs to employ restoration 265 LSP while keeping resources for the working and/or protecting LSPs 266 reserved in the network after the failure, restoration LSP is 267 signaled with ASSOCIATION object that has Association Type set to 268 "Recovery" [RFC4872] with the association ID set to the LSP ID of the 269 LSP it is restoring. For example, when a restoration LSP is signaled 270 for a working LSP, the ASSOCIATION object in the restoration LSP 271 contains the association ID set to the LSP ID of the working LSP. 272 Similarly, when a restoration LSP is signaled for a protecting LSP, 273 the ASSOCIATION object in the restoration LSP contains the 274 association ID set to the LSP ID of the protecting LSP. 276 The procedure for signaling the PROTECTION object is specified in 278 [RFC4872]. Specifically, restoration LSP being used as a working LSP 279 is signaled with P bit cleared and being used as a protecting LSP is 280 signaled with P bit set. 282 3.2. Resource Sharing-based Restoration LSP Setup 284 GMPLS LSPs can share resources if they have Shared Explicit (SE) flag 285 set in their SESSION_ATTRIBUTE objects and: 287 o As defined in [RFC3209], LSPs have identical SESSION objects 288 and/or 290 o As defined in [RFC6689], LSPs have matching ASSOCIATION object 291 with Association Type set to "Resource Sharing". LSPs in this case 292 can have different SESSION objects i.e. different tunnel ID, source 293 and destination. 295 For LSP restoration upon failure, as explained in Section 11 of 296 [RFC4872], reroute procedure may re-use existing resources. The 297 behavior of the intermediate nodes during rerouting process to 298 reconfigure cross-connections does not further impact the traffic 299 since it has been interrupted due to the already failed LSP. 301 The node behavior for setting up the restoration LSP can be 302 categorized into the following three categories: 304 Table 1: Node Behavior during Restoration LSP Setup 305 ---------+--------------------------------------------------------- 306 Category | Node Behavior during Restoration LSP Setup 307 ---------+--------------------------------------------------------- 308 C1 + Reusing existing resource on both input and output 309 + interfaces (node A & B in Figure 3). 310 + 311 + This type of nodes only needs to book the existing 312 + resources and no cross-connection setup 313 + command is needed. 314 ---------+--------------------------------------------------------- 315 C2 + Reusing existing resource only on one of the interfaces, 316 + either input or output interfaces and need to use new 317 + resource on the other interface. (node C & E in Figure 3). 318 + 319 + This type of nodes needs to book the resources and send 320 + the re-configuration cross-connection command to its 321 + corresponding data plane node on the interfaces where new 322 + resources are needed and re-use the 323 + existing resources on the other interfaces. 324 ---------+--------------------------------------------------------- 325 C3 + Using new resources on both interfaces. 327 + (node F & G in Figure 3). 328 + 329 + This type of nodes needs to book the new resources 330 + and send the cross-connection setup 331 + command on both interfaces. 332 ---------+--------------------------------------------------------- 334 Depending on whether the resource is re-used or not, the node 335 behaviors differ. This deviates from normal LSP setup since some 336 nodes do not need to re-configure the cross-connection, and it should 337 not be viewed as an error. Also, the judgment whether the control 338 plane node needs to send a cross-connection setup/modification 339 command to its corresponding data plane node(s) relies on the check 340 whether the LSPs are sharing resources. 342 3.3. LSP Reversion 344 If the end-to-end LSP recovery is revertive, as described in Section 345 2, traffic can be reverted from the restoration LSP to the working or 346 protecting LSP after its failure is recovered. The LSP reversion can 347 be achieved using two methods: 349 1. Make-while-break reversion, where resources associated with 350 working or protecting LSP are reconfigured while removing 351 reservations for the restoration LSP. 353 2. Make-before-break reversion, where resources associated with 354 working or protecting LSP are reconfigured before removing the 355 restoration LSP. 357 In transport networks, both of the above reversion methods will 358 result in some traffic disruption when the restoration LSP and the 359 LSP being restored are sharing resources and the cross-connections 360 need to be reconfigured on intermediate nodes. 362 3.3.1. Make-while-break Reversion 364 In this reversion method, restoration LSP is simply requested to be 365 deleted by the head-end. Removing reservations for restoration LSP 366 triggers reconfiguration of resources associated with working or 367 protecting LSP on every node where resources are shared. Whenever 368 reservation for restoration LSP is removed from a node, data plane 369 configuration changes to reflect reservations of working or 370 protection LSP as signaling progresses. Eventually, after the whole 371 restoration LSP is deleted, data plane configuration will fully match 372 working or protecting LSP reservations on the whole path. Thus 373 reversion is complete. 375 Make-while-break, while being relatively simple in its logic, has few 376 limitations as follows which may not be acceptable in some networks: 378 o No rollback 380 Deletion of restoration LSPs is not a revertive process. If for some 381 reason reconfiguration of data plane on one of the nodes to match 382 working or protection LSP reservations fails, falling back to 383 restoration LSP is no longer an option, as its state might have 384 already been removed from other nodes. 386 o No completion guarantee 388 Deletion of an LSP provides no guarantees of completion. In 389 particular, if RSVP packets are lost due to nodal or DCN failures it 390 is possible for an LSP to be only partially deleted. To mitigate 391 this, RSVP could maintain soft state reservations and hence 392 eventually remove remaining reservations due to refresh timeouts. 393 This approach is not feasible in transport networks however, where 394 control and data channels are often separated and hence soft state 395 reservations are not useful. 397 Finally, one could argue that graceful LSP deletion [RFC3473] would 398 provide guarantee of completion. While this is true for most cases, 399 many implementations will time out graceful deletion if LSP is not 400 removed within certain amount of time, e.g. due to a transit node 401 fault. After that, deletion procedures which provide no completion 402 guarantees will be attempted. Hence, in corner cases completion 403 guarantee cannot be provided. 405 o No explicit notification of completion to head-end node 407 In some cases, it may be useful for a head-end node to know when the 408 data plane has been reconfigured to match working or protection LSP 409 reservations. This knowledge could be used for initiating operations 410 like enabling alarm monitoring, power equalization and others. 411 Unfortunately, for the reasons mentioned above, make-while-break 412 reversion lacks such explicit notification. 414 3.3.2. Make-before-break Reversion 416 This reversion method can be used to overcome limitations of 417 make-while-break reversion. It is similar in spirit to MBB concept 418 used for re-optimization. Instead of relying on deletion of 419 restoration LSP, head-end chooses to establish a new LSP to 420 reconfigure resources on the working or protection LSP path, and uses 421 identical ASSOCIATION and PROTECTION objects from the LSP it is 422 replacing. Only if setup of this LSP is successful will other 423 (restoration and working/protecting) LSPs be deleted by the head-end. 424 MBB reversion consists of two parts: 426 A) Make part: 428 Creating a new reversion LSP following working or protection LSP's 429 path. Reversion LSP is sharing resources both with working and 430 restoration LSPs. As reversion LSP is created, resources are 431 reconfigured to match its reservations. Hence, after reversion LSP 432 is created, data plane configuration essentially reflects working or 433 protecting LSP reservations. 435 B) Break part: 437 After "make" part is finished, working and restoration LSPs are torn 438 down. Removing reservations for working and restoration LSPs does 439 not cause any resource reconfiguration on reversion LSP's path - 440 nodes follow same procedures as for "break" part of any MBB 441 operation. Hence, after working and restoration LSPs are removed, 442 data plane configuration is exactly the same as before starting 443 restoration. Thus reversion is complete. 445 MBB reversion uses make-before-break characteristics to overcome 446 challenges related to make-while-break reversion as follow: 448 o Rollback 450 If "make" part fails, (existing) restoration LSP will still be used 451 to carry existing traffic. Same logic applies here as for any MBB 452 operation failure. 454 o Completion guarantee 456 LSP setup is resilient against RSVP message loss, as Path and Resv 457 messages are refreshed periodically. Hence, given that network 458 recovers its DCN eventually, reversion LSP setup is guaranteed to 459 finish with either success or failure. 461 o Explicit notification of completion to head-end node 463 Head-end knows that data plane has been reconfigured to match working 464 or protection LSP reservations on intermediate nodes when it receives 465 Resv for the reversion LSP. 467 4. Security Considerations 469 This document reviews procedures defined in [RFC3209] [RFC4872] 471 [RFC4873] and [RFC6689] and does not define any new procedure. This 472 document does not introduce any new security issues other than those 473 already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. 475 5. IANA Considerations 477 This informational document does not make any request for IANA 478 action. 480 6. Acknowledgement 482 The authors would like to thank George Swallow for the discussions on 483 the GMPLS restoration. 485 7. References 487 7.1. Normative References 489 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 490 Tunnels", RFC 3209, December 2001. 492 [RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of 493 End-to-End Generalized Multi-Protocol Label Switching 494 (GMPLS) Recovery", RFC 4872, May 2007. 496 [RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May 497 2007. 499 [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 500 6689, July 2012. 502 7.2. Informative References 504 [PCEP-RSO] X. Zhang, et al, "Extensions to Path Computation Element 505 Protocol (PCEP) to Support Resource Sharing-based Path 506 Computation", work in progress, February 2014. 508 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 509 Switching (GMPLS) Signaling Resource ReserVation 510 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 511 3473, January 2003. 513 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 514 (GMPLS) Architecture", RFC 3945, October 2004. 516 [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in 517 Support of Generalized Multi-Protocol Label Switching 518 (GMPLS)", RFC 4203, October 2005. 520 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 521 "Generalized Multiprotocol Label Switching (GMPLS) 522 Recovery Functional Specification", RFC 4426, March 2006. 524 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 525 and Restoration) Terminology for Generalized Multi- 526 Protocol Label Switching", RFC 4427, March 2006. 528 8. Authors' Addresses 530 Xian Zhang 531 Huawei Technologies 532 F3-1-B R&D Center, Huawei Base 533 Bantian, Longgang District 534 Shenzhen 518129 P.R.China 536 Email: zhang.xian@huawei.com 538 Haomian Zheng (editor) 539 Huawei Technologies 540 F3-1-B R&D Center, Huawei Base 541 Bantian, Longgang District 542 Shenzhen 518129 P.R.China 544 Email: zhenghaomian@huawei.com 546 Rakesh Gandhi (editor) 547 Cisco Systems, Inc. 549 Email: rgandhi@cisco.com 551 Zafar Ali 552 Cisco Systems, Inc. 554 Email: zali@cisco.com 556 Gabriele Maria Galimberti 557 Cisco Systems, Inc. 559 Email: ggalimbe@cisco.com 561 Pawel Brzozowski 562 ADVA Optical 564 Email: PBrzozowski@advaoptical.com