idnits 2.17.1 draft-ietf-teas-gmpls-resource-sharing-proc-00.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 (December 8, 2014) is 3425 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 CCAMP Working Group Xian Zhang 3 Internet-Draft Haomian Zheng, Ed. 4 Intended Status: Informational Huawei 5 Expires: June 11, 2015 Rakesh Gandhi, Ed. 6 Zafar Ali 7 Gabriele Maria Galimberti 8 Cisco Systems, Inc. 9 Pawel Brzozowski 10 ADVA Optical 11 December 8, 2014 13 RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- 14 based LSP Setup and Teardown 16 draft-ietf-teas-gmpls-resource-sharing-proc-00 18 Abstract 20 In transport networks, there are requirements where Generalized 21 Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme 22 needs to employ restoration Label Switched Path (LSP) while keeping 23 resources for the working and/or restoration LSPs reserved in the 24 network after the failure occurs. This document reviews how the LSP 25 association is to be provided using Resource Reservation Protocol - 26 Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end- 27 to-end recovery when using restoration LSP where failed LSP is not 28 torn down. 30 This document compliments existing standards by explaining the 31 missing pieces of information during the RSVP-TE signaling procedure 32 in support of resource sharing-based LSP setup/teardown in 33 GMPLS-controlled circuit networks. No new procedures or mechanisms 34 are defined by this document, and it is strictly informative in 35 nature. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. GMPLS Restoration . . . . . . . . . . . . . . . . . . . . . 4 78 2.1.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . 4 79 2.1.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . 5 80 2.2. Resource Sharing-based LSP Setup/Teardown . . . . . . . . . 6 81 3. RSVP-TE Signaling For Restoration LSP Association . . . . . . . 7 82 4. RSVP-TE Signaling For Resource Sharing During LSP 83 Setup/Teardown . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.1. LSPs with Identical Tunnel ID . . . . . . . . . . . . . . . 8 85 4.1.1. Restoration LSP Setup . . . . . . . . . . . . . . . . . 8 86 4.1.2. LSP Reversion . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.2.1. Make-while-break Reversion . . . . . . . . . . . . 11 88 4.1.2.2. Make-before-break Reversion . . . . . . . . . . . . 13 89 4.1.3. Re-optimization LSP Setup and Reversion . . . . . . . . 15 90 4.2. LSPs with Different Tunnel IDs . . . . . . . . . . . . . . 15 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 93 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 97 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines 102 a set of protocols, including Open Shortest Path First - Traffic 103 Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 104 Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used 105 to create Label Switched Paths (LSPs) in a number of deployment 106 scenarios with various transport technologies. The GMPLS protocol 107 set extends MPLS, which supports only Packet Switch Capable (PSC) and 108 Layer 2 Switch Capable interfaces (L2SC), to also cater for 109 interfaces capable of Time Division Multiplexing (TDM), Lambda 110 Switching (LSC) and Fiber Switching (FSC). These switching 111 technologies provide several protection schemes [RFC4426][RFC4427] 112 (e.g., 1+1, 1:N and M:N). Resource Reservation Protocol - Traffic 113 Engineering (RSVP-TE) signaling has been extended to support various 114 GMPLS recovery schemes [RFC4872][RFC4873], to establish Label 115 Switched Paths (LSPs), typically for working LSP and protecting LSP. 116 [RFC4427] Section 7 specifies various schemes for GMPLS recovery. 118 In GMPLS recovery schemes generally considered, restoration LSP is 119 signaled after the failure has been detected and notified on the 120 working LSP. In non-revertive recovery mode, working LSP is assumed 121 to be removed from the network before restoration LSP is signaled. 122 For revertive recovery mode, a restoration LSP is signaled while 123 working LSP and/or protecting LSP are not torn down in control plane 124 due to a failure. In transport networks, as working LSPs are 125 typically signaled over a nominal path, service providers would like 126 to keep resources associated with the working LSPs reserved. This is 127 to make sure that the service (working LSP) can use the nominal path 128 when the failure is repaired to provide deterministic behavior and 129 guaranteed Service Level Agreement (SLA). Consequently, revertive 130 recovery mode is usually preferred by recovery schemes used in 131 transport networks. 133 The Make-Before-Break (MBB) mechanisms exploiting the Shared-Explicit 134 (SE) reservation style can be employed in MPLS networks to avoid 135 double booking of resource during the process of LSP re-optimization 136 as specified in [RFC3209]. This method is also used in GMPLS- 137 controlled networks [RFC4872] [RFC4873] for end-to-end and segment 138 recovery of LSPs. This was further generalized to support resource 139 sharing oriented applications in MPLS networks as well as non-LSP 140 contexts, as specified in [RFC6780]. 142 Due to the fact that the features of GMPLS-controlled networks 143 (specifically for TDM, LSC and FSC), are not identical to that of the 144 MPLS networks, additional considerations for resource sharing based 145 LSP association are needed. As defined in [RFC4872] and being 146 considered in this document, "fully dynamic rerouting switches normal 147 traffic to an alternate LSP that is not even partially established 148 only after the working LSP failure occurs. The new alternate route 149 is selected at the LSP head-end node, it may reuse resources of the 150 failed LSP at intermediate nodes and may include additional 151 intermediate nodes and/or links". During the signaling procedure for 152 resource sharing based LSP setup/teardown, the behaviors of the nodes 153 along the path may be different from that in the MPLS networks as 154 well as the effect it may have on the traffic delivery. 156 As described in [RFC6689], ASSOCIATION Object is used to identify the 157 LSPs for restoration using association type "Recovery" [RFC4872] and 158 for resource sharing using association type "Resource Sharing" 159 [RFC4873]. 161 Following section describes the problem statements for the GMPLS 162 restoration and resource sharing based LSP setup and teardown. 164 2. Problem Statement 166 Problem statements for the GMPLS restoration schemes and resource 167 sharing-based LSP setup and teardown are described in this section. 169 2.1. GMPLS Restoration 171 2.1.1. 1+R Restoration 173 One example of the recovery scheme considered in this document is 1+R 174 recovery. The 1+R recovery is exemplified in Figure 1. In this 175 example, working LSP on path A-B-C-Z is pre-established. Typically 176 after a failure detection and notification on the working LSP, a 177 second LSP on path A-H-I-J-Z is established as a restoration LSP. 178 Unlike protection LSP, restoration LSP is signaled per need basis. 180 +-----+ +-----+ +-----+ +-----+ 181 | A +----+ B +-----+ C +-----+ Z | 182 +--+--+ +-----+ +-----+ +--+--+ 183 \ / 184 \ / 185 +--+--+ +-----+ +--+--+ 186 | H +-------+ I +--------+ J | 187 +-----+ +-----+ +-----+ 189 Figure 1: An Example of 1+R Recovery Scheme 191 During failure switchover with 1+R recovery scheme, in general, 192 working LSP resources are not released and working and restoration 193 LSPs coexist in the network. Nonetheless, working and restoration 194 LSPs can share network resources. Typically when failure is 195 recovered on the working LSP, restoration LSP is no longer required 196 and torn down (e.g., revertive mode). 198 2.1.2. 1+1+R Restoration 200 Another example of the recovery scheme considered in this document is 201 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP 202 and/or the protecting LSP after the failure has been detected and 203 notified on the working LSP or the protecting LSP. The 1+1+R 204 recovery is exemplified in Figure 2. 206 +-----+ +-----+ +-----+ 207 | D +-------+ E +--------+ F | 208 +--+--+ +-----+ +--+--+ 209 / \ 210 / \ 211 +--+--+ +-----+ +-----+ +--+--+ 212 | A +----+ B +-----+ C +-----+ Z | 213 +--+--+ +-----+ +-----+ +--+--+ 214 \ / 215 \ / 216 +--+--+ +-----+ +--+--+ 217 | H +-------+ I +--------+ J | 218 +-----+ +-----+ +-----+ 220 Figure 2: An Example of 1+1+R Recovery Scheme 222 In this example, working LSP on path A-B-C-Z and protecting LSP on 223 path A-D-E-F-Z are pre-established. After a failure detection and 224 notification on a working LSP or protecting LSP, a third LSP on path 225 A-H-I-J-Z is established as a restoration LSP. The restoration LSP 226 in this case provides protection against a second order failure. 227 Restoration LSP is torn down when the failure on the working or 228 protecting LSP is repaired. 230 [RFC4872] Section 14 defines PROTECTION Object for GMPLS recovery 231 signaling. As defined, the PROTECTION Object is used to identify 232 primary and secondary LSPs using S bit and protecting and working 233 LSPs using P bit. Furthermore, [RFC4872] defines the usage of 234 ASSOCIATION Object for associating GMPLS working and protecting LSPs. 236 [RFC6689] Section 2.2 reviews the procedure for providing LSP 237 associations for GMPLS end-to-end recovery and covers the schemes 238 where the failed working LSP and/or protecting LSP are torn down. 240 This document reviews how the LSP association is to be provided for 241 GMPLS end-to-end recovery when using restoration LSP where working 242 and protecting LSP resources are kept reserved in the network after 243 the failure. 245 2.2. Resource Sharing-based LSP Setup/Teardown 247 +-----+ +-----+ 248 | F +------+ G +--------+ 249 +--+--+ +-----+ | 250 | | 251 | | 252 +-----+ +-----+ +--+--+ +-----+ +--+--+ 253 | A +----+ B +-----+ C +--X---+ D +-----+ E | 254 +-----+ +-----+ +-----+ +-----+ +-----+ 256 Figure 3: A Simple OTN Network 258 Using the Optical Transport Network (OTN) topology shown in Figure 3 259 as an example, GMPLS-controlled circuit LSP1 (A-B-C-D-E) is the 260 working LSP and it allows for resource sharing when the LSP is 261 dynamically rerouted due to link failure. Upon detecting the failure 262 of a link along the LSP1, e.g. Link C-D, node A needs to decide on 263 which alternate path it will establish an LSP to reroute the traffic. 264 In this case, A-B-C-F-G-E is chosen as the alternative path for the 265 LSP and the resources on the path segment A-B-C are re-used by this 266 LSP. Since this is an OTN network, which is different from the 267 packet-switching network, the label has a mapping into the data plane 268 resource used (e.g. wavelength) and also the nodes along the path 269 need to send triggering commands to data plane nodes for setting up 270 cross-connection accordingly during the RSVP-TE signaling process. 271 In this case, the following issues are left un-described in the 272 existing standards for resource sharing based LSP setup/teardown in 273 GMPLS-controlled circuit networks: 275 - Reservation style Shared-Explicit (SE) as defined in [RFC3209] may 276 not be applicable due to the nature of the GMPLS-controlled circuits. 277 It is not clear how reservation style is to be used by the GMPLS 278 LSPs for resource sharing. 280 - As described in [RFC3209], the purpose of Make-Before-Break (MBB) 281 is to "not disrupt traffic or adversely impact network operations 282 while TE tunnel rerouting is in progress". Due to the nature of the 283 GMPLS-controlled circuit networks, this may not be fulfilled under 284 certain scenarios. Thus, the name "Make-Before-Break" may no longer 285 hold true. 287 - The existing MBB method may not be sufficient to support LSP setup 288 and teardown with resource sharing. 290 - In [RFC3209], the MBB method assumes the old and new LSPs share the 291 same tunnel ID (i.e., sharing the same source and destination nodes). 292 [RFC4873] does not impose this constraint but limit the resource 293 sharing usage in LSP recoveries only. [RFC6780] generalizes the 294 resource sharing application, based on the ASSOCIATION Object, to be 295 useful in MPLS networks as well as in non-LSP association such as 296 Voice Call-Waiting. Recently, there are also requirements to 297 generalize resource sharing of LSPs with different tunnel IDs, such 298 as the one mentioned in [PCEP-RSO] and LSPs with LSP-stitching across 299 multi-domains. In this case, how the signaling process can make 300 intermediate nodes aware of the resource sharing constraint and 301 behave accordingly is an issue that needs to be described. 303 - The node behavior during traffic reversion in the GMPLS-controlled 304 circuit network is missing and should be clarified. 306 This document reviews the signaling procedure for resource 307 sharing-based LSP setup and teardown for GMPLS-based circuits in OTN 308 networks. This includes the node behavior description, besides 309 clarifying some un-discussed points for this process. Two typical 310 examples mentioned in this document are LSP restoration and LSP re- 311 optimization, where it is desirable to share resources. This 312 document does not define any RSVP-TE signaling extensions. If 313 necessary, discussion is provided to identify potential extensions to 314 the existing RSVP-TE protocol. It is expected that the extensions, 315 if there are any, will be addressed in separate documents. 317 3. RSVP-TE Signaling For Restoration LSP Association 319 Where GMPLS end-to-end recovery scheme needs to employ restoration 320 LSP while keeping resources for the working and/or protecting LSPs 321 reserved in the network after the failure, restoration LSP is 322 signaled with ASSOCIATION Object that has association type set to 323 "Recovery" [RFC4872] with the association ID set to the LSP ID of the 324 LSP it is restoring. For example, when a restoration LSP is signaled 325 for a working LSP, the ASSOCIATION Object in the restoration LSP 326 contains the association ID set to the LSP ID of the working LSP. 327 Similarly, when a restoration LSP is signaled for a protecting LSP, 328 the ASSOCIATION Object in the restoration LSP contains the 329 association ID set to the LSP ID of the protecting LSP. 331 The procedure for signaling the PROTECTION Object is specified in 332 [RFC4872]. Specifically, restoration LSP being used as a working LSP 333 is signaled with P bit cleared and being used as a protecting LSP is 334 signaled with P bit set. 336 As discussed in Section 2 of this document, [RFC6689] Section 2.2 337 reviews the procedure for providing LSP associations for the GMPLS 338 end-to-end recovery scheme using restoration LSP where the failed 339 working LSP and/or protecting LSP are torn down. 341 4. RSVP-TE Signaling For Resource Sharing During LSP Setup/Teardown 343 For LSP restoration upon failure, as explained in Section 11 of 344 [RFC4872], the purpose of using MBB is to re-use existing resources. 345 Thus, the behavior of the intermediate nodes during rerouting process 346 will not further impact traffic since it has been interrupted due to 347 the already broken working LSP. However, for the following two 348 cases, the behavior of intermediate nodes may impact the traffic 349 delivery: (1) LSP reversion; (2) LSP re-optimization. 351 Another dimension that needs separate attention is how to correlate 352 the two LSPs sharing resource. For the LSPs with the same Tunnel ID, 353 [RFC4872] and reviewed in this section. For the LSPs with different 354 Tunnel IDs, signaling procedure is clarified in Section 4.2 of this 355 document. 357 4.1. LSPs with Identical Tunnel ID 359 For resource sharing among LSPs with identical Tunnel IDs, SE flag 360 and ASSOCIATION Object are used together. The SE flag is to enable 361 resource sharing and the ASSOCIATION Object with association type 362 "Resource Sharing" [RFC4873] is to identify the associated LSPs. 364 As a first step, in order to allow resource sharing, the original LSP 365 setup should explicitly carry the SE flag in the SESSION_ATTRIBUTE 366 Object during the initial LSP setup, irrespective of the purpose of 367 resource sharing. 369 The basic signaling procedure for alternative LSP setup has been 370 described by the existing standards. In [RFC3209], it describes the 371 basic MBB signaling flow for MPLS-TE networks. [RFC4872] adds 372 additional information when using MBB for LSP rerouting. 374 As mentioned before, for LSP setup/teardown in GMPLS-controlled 375 circuit networks, the network elements along the path need to send 376 cross-connection setup/teardown commands to data plane node(s) either 377 during the PATH message forwarding phase or the RESV message 378 forwarding phase. 380 4.1.1. Restoration LSP Setup 382 For LSP restoration, the complete signaling flow processes for both 383 LSP restorations upon failure and LSP reversion upon link failure 384 recovery are described in this section. 386 Table 1: Node Behavior during Restoration LSP Setup 388 ---------+--------------------------------------------------------- 389 Category | Node Behavior during Restoration LSP setup 390 ---------+--------------------------------------------------------- 391 C1 + Reusing existing resource on both input and output 392 + interfaces. 393 + This type of nodes only needs to book the existing 394 + resource when receiving the PATH message and no cross- 395 + connection setup command is needed when receiving 396 + the RESV message. 397 ---------+---------------------------------------------------------- 398 C2 + Reusing existing resource only on one of the interfaces, 399 + either input or output interfaces and need to use new 400 + resource on the other interface. 401 + This type of nodes needs to book the resources on the 402 + interface where new resource are needed and re-use the 403 + existing resource on the other interface when it receives 404 + the PATH message. Upon receiving the RESV message, it 405 + needs to send the re-configuration the cross-connection 406 + command to its corresponding data plane node. 407 ---------+--------------------------------------------------------- 408 C3 + Using new resource on both interfaces. 409 + This type of nodes needs to book the new resource when 410 + receiving PATH and send the cross-connection setup 411 + command upon receiving RESV. 412 ---------+--------------------------------------------------------- 414 For LSP rerouting upon working LSP failure, using the network shown 415 in Figure 3 as an example. 417 Working LSP: A-B-C-D-E 418 Restoration LSP: A-B-C-F-G-E 420 The restoration LSP may be calculated by the head-end node or a Path 421 Computation Element (PCE) [RFC4655]. Assuming that the 422 cross-connection configuration command is sent by the control plane 423 nodes during the RESV forwarding phrase, the node behavior for 424 setting up the alternative LSP can be classified into the following 425 three categories as shown in Table 1. 427 +---+ +---+ +---+ +---+ +---+ +---+ 428 | A | | B | | C | | F | | G | | E | 429 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 430 | | | | | | 431 | PATH | | | | | 432 C1 +----------X+ C1 | | | | 433 | | PATH | | | | 434 | +----------X+ C2 | | | 435 | | | PATH | | | 436 | | +----------X+ C3 | | 437 | | | | PATH | | 438 | | | +----------X+ C3 | 439 | | | | | PATH | 440 | | | | +-----------X+ C2 441 | | | | | | 442 | | | | | | 443 | | | | | RESV | 444 | | | | C3 +X-----------+ C2 445 | | | | RESV | | 446 | | | C3 +X----------+ | 447 | | | RESV | | | 448 | | C2 +X----------+ | | 449 | | RESV | | | | 450 | C1 +X----------+ | | | 451 | RESV | | | | | 452 C1 +X----------+ | | | | 454 Figure 4: Restoration LSP Setup Signaling Procedure 456 As shown in Figure 4, depending on whether the resource is re-used or 457 not, the node behaviors differ. This deviates from normal LSP setup 458 since some nodes do not need to re-configure the cross-connection, 459 and thus should not be viewed as an error. Also, the judgment 460 whether the control plane node needs to send a cross-connection 461 setup/modification command to its corresponding data plane node(s) 462 relies on the check whether the following two cases holds true: (1) 463 the PATH message received include a SE reservation style; (2) the 464 PATH message identifies a LSP that sharing the same tunnel ID as the 465 LSP to share resource with. For the second point, the processing 466 rules and configuration of ASSOCIATION Object defined in [RFC4872] 467 are followed. 469 4.1.2. LSP Reversion 471 If the LSP rerouting is revertive, traffic can be reverted to the 472 working or protecting LSP after its failure is recovered. From 473 resource sharing perspective reversion can be divided into two types: 475 o Make-while-break reversion, where resources associated with 476 working or protecting LSP are reconfigured while removing 477 reservations for restoration LSP. 479 o Make-before-break reversion, where resources associated with 480 working or protecting LSP are reconfigured before removing 481 restoration LSP. 483 It is worth mentioning that in GMPLS-controlled circuit OTN networks 484 both reversion types will result in a short traffic disruption. 486 4.1.2.1. Make-while-break Reversion 488 In this technique, restoration LSP is simply requested to be deleted. 489 Removing reservations for restoration LSP triggers reconfiguration of 490 resources associated with working or protecting LSP on every node 491 where resources are shared. Hence, whenever reservation for 492 restoration LSP is removed from a node, data plane configuration 493 changes to reflect reservations of working or protection LSP as 494 signaling progresses. Eventually, after the whole restoration LSP is 495 deleted, data plane configuration will fully match working or 496 protecting LSP reservations on the whole path. Thus reversion is 497 complete. 499 +---+ +---+ +---+ +---+ +---+ +---+ 500 | A | | B | | C | | F | | G | | E | 501 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 502 | | | | | | 503 | PATHTEAR | | | | | 504 D1 +----------X+ D1 | | | | 505 | | PATHTEAR | | | | 506 | +----------X+ D2 | | | 507 | | | PATHTEAR | | | 508 | | +----------X+ D3 | | 509 | | | | PATHTEAR | | 510 | | | +----------X+ D3 | 511 | | | | | PATHTEAR | 512 | | | | +----------X+ D2 513 | | | | | | 515 Figure 5: Signaling Procedure for LSP Make-while-break Reversion 517 Figure 5 shows signaling process of make-while-break reversion of LSP 518 PathTear message. For alarm-free LSP deletion, the mechanisms 519 described in Section 6 of [RFC4208] should be followed. Resource 520 sharing between working and restoration LSP takes place on nodes A, 521 B, C and E. These are the nodes where reconfiguration of resources 522 associated with working LSP can take place. 524 Node behavior upon removing reservation for restoration LSP depends 525 on how resources are shared with working or protecting LSP: 527 Table 2: Node behavior during LSP make-while-break reversion 529 ---------+--------------------------------------------------------- 530 Category | Node behavior during LSP make-while-break reversion 531 ---------+--------------------------------------------------------- 532 D1 + Working and restoration LSP share resources on both 533 + incoming and outgoing interface. 534 + 535 + CP change: Reservation for restoration LSP is removed. 536 + DP change: None, as data plane configuration already 537 + reflects working LSP reservation. 538 ---------+---------------------------------------------------------- 539 D2 + Working and restoration LSP share resources on one of the 540 + interfaces. 541 + 542 + CP change: Reservation for restoration LSP is removed. 543 + DP change: Resource on the interface that is not shared 544 + between working and restoration LSP is freed. 545 + Cross-connection is updated to reflect working LSP 546 + reservation. 547 ---------+---------------------------------------------------------- 548 D3 + Working and restoration LSP do not share resources. 549 + 550 + CP change: Reservation for restoration LSP is removed. 551 + DP change: Resources associated with restoration LSP are 552 + freed. 553 ---------+---------------------------------------------------------- 555 Make-while-break, while being relatively simple in its logic, has a 556 few limitations which may be not acceptable in some implementations: 558 o No rollback 560 Deletion of a LSP is not a revertive process. If for some 561 reason reconfiguration of data plane on one of the nodes to 562 match working or protection LSP reservations fails, falling back 563 to restoration LSP is no longer an option, as its state might 564 have already been removed from other nodes. 566 o No completion guarantee 568 Deletion of a LSP provides no guarantees of completion. In 569 particular, if RSVP packets are lost due to nodal or DCN 570 failures it is probable for a LSP to be only partially deleted. 571 To mitigate this, RSVP could maintain soft state reservations 572 and hence eventually remove remaining reservations due to 573 refresh timeouts. This approach is not feasible in circuit 574 networks however, since control and data channels are often 575 separated and hence soft state reservations are not used. 577 Finally, one could argue that graceful LSP deletion [RFC3473] 578 would provide guarantee of completion. While this is true for 579 most cases, many implementations will timeout graceful deletion 580 if LSP is not removed within certain amount of time, e.g. due to 581 a transit node fault. After that, deletion procedures that 582 provide no completion guarantees will be attempted. Hence in 583 corner cases completion guarantee cannot be provided. 585 o No explicit notification of completion to ingress node 587 In some cases it may be useful for ingress node to know when the 588 data plane has been reconfigured to match working or protection 589 LSP reservations. This knowledge could be used for initiating 590 operations like enabling alarm monitoring, power equalization 591 and others. Unfortunately, for the reasons mentioned above, 592 make-while-break reversion lacks such explicit notification. 594 4.1.2.2. Make-before-break Reversion 596 MBB reversion can be used to overcome limitations of make-while-break 597 reversion. It is similar in spirit to MBB concept used for 598 restoration. Instead of relying on deletion of restoration LSP, it 599 chooses to establish a new LSP to reconfigure resources on the 600 working or protection LSP path. Only if setup of this LSP is 601 successful will other LSPs be deleted. MBB reversion consists of two 602 parts: 604 A) Make part: 605 Creating a new reversion LSP following working or protection 606 LSP's path - see Figure 6. Reversion LSP is sharing resources 607 both with working and restoration LSPs. As reversion LSP is 608 created, resources are reconfigured to match its reservations - 609 nodes follow procedures described in Table 1. Hence after 610 reversion LSP is created, data plane configuration essentially 611 reflects working or protecting LSP reservations. 613 B) Break part: 614 After 'make' part is finished, working and restoration LSPs are 615 torn down. Removing reservations for working and restoration 616 LSPs does not cause any resource reconfiguration on reversion 617 LSP's path - nodes follow same procedures as for 'break' part of 618 any MBB operation. Hence after working and restoration LSPs are 619 removed, data plane configuration is exactly the same as before 620 starting restoration. Thus reversion is complete. 622 +---+ +---+ +---+ +---+ +---+ 623 | A | | B | | C | | D | | E | 624 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 625 | | | | | 626 | PATH | | | | 627 C1 +----------X+ C1 | | | 628 | | PATH | | | 629 | +----------X+ C2 | | 630 | | | PATH | | 631 | | +----------X+ C1 | 632 | | | | PATH | 633 | | | +----------X+ C2 634 | | | | | 635 | | | | | 636 | | | | RESV | 637 | | | C1 +X----------+ C2 638 | | | RESV | | 639 | | C2 +X----------+ | 640 | | RESV | | | 641 | C1 +X----------+ | | 642 | RESV | | | | 643 C1 +X----------+ | | | 645 Figure 6: 'Make': Reversion LSP Setup follows Working LSP's Path 647 Figure 6 shows signaling process of reversion LSP setup for working 648 LSP from Section 4.1.1. In this example, resource sharing between 649 reversion and restoration LSP takes place on nodes A, B, C and E. 650 Resource sharing between working and reversion LSP takes place on 651 whole working LPS's path, i.e. A, B, C, D and E. Before reversion 652 LSP is signaled, data plane configuration on nodes A, B, C and E 653 match restoration LSP reservations. On node D data plane 654 configuration matches working LSP reservations. 656 As already mentioned, MBB reversion uses make-before-break 657 characteristics to overcome challenges related to make-while-break 658 reversion: 660 o Rollback 662 If 'make' part fails, restoration LSP will still be used to 663 carry existing traffic. Same logic applies here as for any MBB 664 operation failure. 666 o Completion guarantee 667 LSP setup is resilient against RSVP message loss, as PATH and 668 RESV messages are refreshed periodically. Hence, given that 669 network recovers its DCN eventually, setup is guaranteed to 670 finish with either success or failure. 672 o Explicit notification of completion to ingress node 674 Ingress knows that data plane has been reconfigured to match 675 working or protection LSP reservations when it receives RESV for 676 the reversion LSP. 678 4.1.3. Re-optimization LSP Setup and Reversion 680 For LSP re-optimization where the new LSP and old LSPs share 681 resource, the signaling flow for new LSP setup and old LSP teardown 682 is similar to those shown in Figures 4 and 5. 684 The issue that should be noted is the traffic will be disrupted if 685 the new path setup process changes the cross-connection configuration 686 of the nodes along the old LSP. If no traffic interruption is 687 desirable, it should either ensure that the old and new LSP do not 688 share the resource other than the source and destination nodes or use 689 other mechanisms. This is out the scope of this document. 691 Similarly, if LSP re-optimization fails and there is a need for LSP 692 reversion, the traffic may be disrupted when resources are shared and 693 cross-connections need to be reconfigured and reverted. 695 4.2. LSPs with Different Tunnel IDs 697 For two LSPs with different Tunnel IDs, the ASSOCIATION Object is 698 used to specify that they are sharing resource (by setting 699 ASSOCIATION type as "Resource Sharing" (value 2) as well as to 700 identify these correlated LSPs. There are two types: 702 (1) Sharing the common nodes, such as segment recovery, the source 703 and destination nodes of the segment recovery LSP is the 704 intermediate nodes along the working LSPs; 706 (2) Resource sharing is used in a generalized context (such as 707 multi-layer or multi-domain networks); it may result in either 708 sharing source nodes in common, or destination nodes in common, or 709 non end-points in common, if viewed from one domain's perspective. 711 The path computation can either be performed by the source node or 712 edge nodes for the path/path segment or carried out by the PCE, such 713 as the one explained in [PCEP-RSO]. This document does not impose 714 any constraint with regard to path computation. 716 [RFC4873] considers resource sharing for LSP segment recovery. The 717 ASSOCIATION Object usage is limited. [RFC6780] extends the usage of 718 ASSOCIATION Object to cover generalized resource sharing 719 applications. The extended ASSOCIATION Object is primarily defined 720 for MPLS-TP, but it can be applied in a wider scope [RFC6780]. It 721 can be used in the second types mentioned above. The configuration 722 and processing rules of extended ASSOCIATION Object defined in 723 [RFC6780] should be followed. The only issue that need pay attention 724 to is that uniqueness of LSP association for the second type should 725 be guaranteed when crossing the layer or domain boundary. The 726 mechanisms for how to ensure this are outside the scope of this 727 document. 729 Other than this, the signaling flow for this type of resource sharing 730 is similar to the description provided in Section 4.1.1. Similar to 731 what is discussed in previous sections, the traffic delivery may be 732 interrupted. Depending on whether the short traffic interruption is 733 acceptable or not, additional mechanisms may be needed and are 734 outside the scope of this document. 736 5. Security Considerations 738 This document reviews procedures defined in [RFC4872] and [RFC6689] 739 and does not define any new procedure. This document does not incur 740 any new security issues other than those already covered in [RFC3209] 741 [RFC4872] [RFC4873] and [RFC6780]. 743 6. IANA Considerations 745 This informational document does not make any requests for IANA 746 action. 748 7. Acknowledgement 750 The authors would like to thank George Swallow for the discussions on 751 the GMPLS restoration. 753 8. References 755 8.1. Normative References 757 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 758 Tunnels", RFC 3209, December 2001. 760 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 761 Switching (GMPLS) Signaling Resource ReserVation 762 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 763 3473, January 2003. 765 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 766 (GMPLS) Architecture", RFC 3945, October 2004. 768 [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in 769 Support of Generalized Multi-Protocol Label Switching 770 (GMPLS)", RFC 4203, October 2005. 772 [RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of End- 773 to-End Generalized Multi-Protocol Label Switching (GMPLS) 774 Recovery", RFC 4872, May 2007. 776 [RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May 777 2007. 779 [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 780 6689, July 2012. 782 [RFC6780] L. Berger et al, "RSVP ASSOCIATION Object Extensions", 783 RFC 6780, October 2012. 785 8.2. Informative References 787 [PCEP-RSO] X. Zhang, et al, "Extensions to Path Computation Element 788 Protocol (PCEP) to Support Resource Sharing-based Path 789 Computation", work in progress, February 2014. 791 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 792 "Generalized Multiprotocol Label Switching (GMPLS) 793 Recovery Functional Specification", RFC 4426, March 2006. 795 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 796 and Restoration) Terminology for Generalized Multi- 797 Protocol Label Switching", RFC 4427, March 2006. 799 [RFC4655] A. Farrel et al, "A Path Computation Element (PCE)-Based 800 Architecture", RFC 4655, August 2006. 802 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y., 803 "Generalized Multiprotocol Label Switching (GMPLS) 804 User-Network Interface (UNI): Resource ReserVation 805 Protocol-Traffic Engineering (RSVP-TE) Support for the 806 Overlay Model", RFC 4208, October 2005. 808 9. Authors' Addresses 810 Xian Zhang 811 Huawei Technologies 812 F3-1-B R&D Center, Huawei Base 813 Bantian, Longgang District 814 Shenzhen 518129 P.R.China 816 Email: zhang.xian@huawei.com 818 Haomian Zheng (editor) 819 Huawei Technologies 820 F3-1-B R&D Center, Huawei Base 821 Bantian, Longgang District 822 Shenzhen 518129 P.R.China 824 Email: zhenghaomian@huawei.com 826 Rakesh Gandhi (editor) 827 Cisco Systems, Inc. 829 Email: rgandhi@cisco.com 831 Zafar Ali 832 Cisco Systems, Inc. 834 Email: zali@cisco.com 836 Gabriele Maria Galimberti 837 Cisco Systems, Inc. 839 Email: ggalimbe@cisco.com 841 Pawel Brzozowski 842 ADVA Optical 844 Email: PBrzozowski@advaoptical.com