idnits 2.17.1 draft-ietf-mpls-summary-frr-rsvpte-04.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 (May 22, 2019) is 1801 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 804 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Taillon 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track T. Saad, Ed. 5 Expires: November 23, 2019 Juniper Networks 6 R. Gandhi 7 Cisco Systems, Inc. 8 A. Deshmukh 9 Juniper Networks 10 M. Jork 11 128 Technology 12 V. Beeram 13 Juniper Networks 14 May 22, 2019 16 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 17 draft-ietf-mpls-summary-frr-rsvpte-04 19 Abstract 21 This document defines Resource Reservation Protocol (RSVP) Traffic- 22 Engineering (TE) signaling extensions that reduce the amount of RSVP 23 signaling required for Fast Reroute (FRR) procedures and subsequently 24 improve the scalability of the RSVP-TE signaling when undergoing FRR 25 convergence after a link or node failure. Such extensions allow the 26 RSVP message exchange between the Point of Local Repair (PLR) and the 27 Merge Point (MP) to be independent of the number of protected Label 28 Switched Paths (LSPs) traversing between them when facility bypass 29 FRR protection is used. The signaling extensions are fully backwards 30 compatible with nodes that do not support them. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 23, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 68 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 70 3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 4 71 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 5 72 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 6 73 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 7 74 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 10 75 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID . . . . . 11 76 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID . . . . . 12 77 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 13 78 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 13 79 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 14 80 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 15 81 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 15 82 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 15 83 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 16 84 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 9.2. Informative References . . . . . . . . . . . . . . . . . 18 92 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 The Fast Reroute (FRR) procedures defined in [RFC4090] describe the 98 mechanisms for the Point of Local Repair (PLR) to reroute traffic and 99 signaling of a protected RSVP-TE LSP onto the bypass tunnel in the 100 event of a TE link or node failure. Such signaling procedures are 101 performed individually for each affected protected LSP. This may 102 eventually lead to control plane scalability and latency issues on 103 the PLR and/or the MP due to limited memory and CPU processing 104 resources. This condition is exacerbated when the failure affects 105 large number of protected LSPs that traverse the same PLR and Merge 106 Point (MP) nodes. 108 For example, in a large scale RSVP-TE LSPs deployment, a single LSR 109 acting as a PLR node may host tens of thousands of protected RSVP-TE 110 LSPs egressing the same link, and also act as a MP node for similar 111 number of LSPs ingressing the same link. In the event of the failure 112 of the link or neighbor node, the RSVP-TE control plane of the node 113 when acting as PLR becomes busy rerouting protected LSPs signaling 114 over the bypass tunnel(s) in one direction, and when acting as an MP 115 node becomes busy merging RSVP states from signaling received over 116 bypass tunnels for LSP(s) in the reverse direction. Subsequently, 117 the head-end LER(s) that are notified of the local repair at 118 downstream LSR will attempt to (re)converge affected RSVP- TE LSPs 119 onto newly computed paths - possibly traversing the same previously 120 affected LSR(s). As a result, the RSVP-TE control plane at the PLR 121 and MP becomes overwhelmed by the amount of FRR RSVP-TE processing 122 overhead following the link or node failure, and the competing other 123 control plane protocol(s) (e.g. the IGP) that undergo their 124 convergence at the same time. 126 The extensions defined in this document enable a MP node to become 127 aware of the PLR node's bypass tunnel assignment group and allow FRR 128 procedures between PLR node and MP node to be signaled and processed 129 on groups of LSPs. 131 As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to 132 refresh the RSVP Path and Resv states to help with the scale. The 133 MESSAGE_ID information for the rerouted PATH and RESV states are 134 exchanged between PLR and MP nodes between PLR and MP nodes a priori 135 to the fault such that Summary Refresh procedures defined in 136 [RFC2961] can continue to be used to refresh the rerouted state(s) 137 after FRR has occurred. 139 2. Conventions Used in This Document 141 2.1. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in BCP 14, RFC 2119 146 [RFC2119]. 148 2.2. Acronyms and Abbreviations 150 The reader is assumed to be familiar with terms and abbreviations 151 used in [RFC3209] and [RFC4090]. 153 The following abbreviations are also used in this document: 155 LSR: Label Switching Router 157 LER: Label Edge Router 159 MPLS: Multiprotocol Label Switching 161 LSP: Label Switched Path 163 MP: Merge Point node as defined in [RFC4090] 165 PLR: Point of Local Repair node as defined in [RFC4090] 167 FRR: Fast Reroute as defined in [RFC4090] 169 B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION 170 object. Added by the PLR for each LSP protected by the bypass 171 tunnel. 173 B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION 174 object. Used to notify the MP node of one ore more groups of 175 protected LSP(s) that are being protected by the specified bypass 176 tunnel are being rerouted. 178 3. Extensions for Summary FRR Signaling 180 The RSVP ASSOCIATION object is defined in [RFC4872] as a means to 181 associate LSPs with each other. For example, in the context of 182 GMPLS-controlled LSP(s), the object is used to associate recovery 183 LSPs with the LSP they are protecting. The Extended ASSOCIATION 184 object is introduced in [RFC6780] to expand on the possible usage of 185 the ASSOCIATION object and generalize the definition of the Extended 186 Association ID field. 188 This document proposes the use of the Extended ASSOCIATION object to 189 carry the Summary FRR information and associate the protected LSP(s) 190 with the bypass tunnel that protects them. Two new Association Types 191 for the Extended ASSOCIATION object, and new Extended Association IDs 192 are proposed in this draft to describe the Bypass Summary FRR Ready 193 (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active) 194 associations. 196 The PLR creates and manages the Summary FRR LSP groups 197 (Bypass_Group_Identifiers) and shares them with the MP via signaling. 198 Protected LSPs sharing the same egress link and bypass assignment are 199 grouped together and are assigned the same group. The MP maintains 200 the PLR group assignments learned via signaling, and acknowledges the 201 group assignments via signaling. Once the PLR receives the 202 acknowledgment, FRR signaling can proceed as group based. 204 The PLR node that supports Summary FRR procedures adds the Extended 205 ASSOCIATION object with Type B-SFRR-Ready and respective Extended 206 Association ID in the RSVP Path message of the protected LSP to 207 inform the MP of the PLR's assigned bypass tunnel, Summary FRR 208 Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to 209 refresh the protected LSP PATH state after FRR occurs. 211 The MP node that supports Summary FRR procedures adds the B-SFRR- 212 Ready Extended ASSOCIATION object and respective Extended Association 213 ID in the RSVP Resv message of the protected LSP to acknowledge the 214 PLR's bypass tunnel assignment, and provide the MESSAGE_ID object 215 that the MP node will use to refresh the protected LSP RESV state 216 after FRR occurs. 218 This document also defines a new Association Type for the Extended 219 ASSOCIATION object and new Extended Association ID to describe the B- 220 SFRR-Active association. The B-SFRR-Active Extended ASSOCIATION 221 object and Extended Association ID are sent by PLR after activating 222 FRR procedures on the PLR. The B-SFRR-Active Extended ASSOCIATION 223 object and Extended Association ID are sent within the RSVP Path 224 message of the bypass LSP to inform the MP node that one or more 225 groups of protected LSPs protected by the bypass tunnel are now being 226 rerouted over the bypass tunnel. 228 3.1. B-SFRR-Ready Extended ASSOCIATION Object 230 The Extended ASSOCIATION object is populated using the rules defined 231 below to associate a protected LSP with the bypass LSP that is 232 protecting it when Summary FRR procedures are enabled. 234 The Association Type, Association ID, and Association Source MUST be 235 set as defined in [RFC4872] for the ASSOCIATION Object. More 236 specifically: 238 Association Source: 240 The Association Source is set to an address of the PLR node. 242 Association Type: 244 A new Association Type is defined for B-SFRR-Ready as follows: 246 Value Type 247 ------- ------ 248 (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) 250 Extended ASSOCIATION ID for B-SFRR-Ready: 252 The B-SFRR-Ready Extended ASSOCIATION ID is 253 populated by the PLR for the Bypass Summary FRR Ready association. 254 The rules to populate the Extended ASSOCIATION ID in this case are 255 described below. 257 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID 259 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association 260 type has the following format: 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Bypass_Tunnel_ID | Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Bypass_Source_IPv4_Address | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Bypass_Destination_IPv4_Address | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Bypass_Group_Identifier | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | MESSAGE_ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready 278 Bypass_Tunnel_ID: 16 bits 280 The bypass tunnel identifier. 282 Reserved: 16 bits 284 Reserved for future use. 286 Bypass_Source_IPv4_Address: 32 bits 288 The bypass tunnel source IPV4 address. 290 Bypass_Destination_IPv4_Address: 32 bits 292 The bypass tunnel destination IPV4 address. 294 Bypass_Group_Identifier: 32 bits 296 The bypass tunnel group identifier. 298 MESSAGE_ID 300 A MESSAGE_ID object as defined by [RFC2961]. 302 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID 304 The IPv6 Extended ASSOCIATION ID field for the B-SFRR-Ready 305 association type has the following format: 307 0 1 2 3 308 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Bypass_Tunnel_ID | Reserved | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 + + 314 | | 315 + Bypass_Source_IPv6_Address + 316 | | 317 + + 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 + + 322 | | 323 + Bypass_Destination_IPv6_Address + 324 | | 325 + + 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Bypass_Group_Identifier | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | MESSAGE_ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready 335 Bypass_Tunnel_ID: 16 bits 337 The bypass tunnel identifier. 339 Reserved: 16 bits 341 Reserved for future use. 343 Bypass_Source_IPv6_Address: 128 bits 345 The bypass tunnel source IPV6 address. 347 Bypass_Destination_IPv6_Address: 128 bits 349 The bypass tunnel destination IPV6 address. 351 Bypass_Group_Identifier: 32 bits 353 The bypass tunnel group identifier. 355 MESSAGE_ID 357 A MESSAGE_ID object as defined by [RFC2961]. 359 The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each 360 protected LSP. The same Bypass_Group_Identifier is used for the set 361 of protected LSPs that share the same bypass tunnel and traverse the 362 same egress link and are not already rerouted. The PLR also 363 generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and 364 Message_Identifier MUST be set according to [RFC2961]). 366 The PLR MUST generate a new Message_Identifier each time the contents 367 of the B-SFRR-Ready Extended ASSOCIATION ID changes; for example, 368 when PLR node changes the bypass tunnel assignment. 370 The PLR node notifies the MP node of the bypass tunnel assignment via 371 adding a B-SFRR-Ready Extended ASSOCIATION object and Association ID 372 in the RSVP Path message for the protected LSP using procedures 373 described in Section 3.4. 375 The MP node acknowledges the PLR node assignment by signaling the B- 376 SFRR-Ready Extended ASSOCIATION object and Association ID within the 377 RSVP Resv message of the protected LSP. With exception of the 378 MESSAGE_ID objects, all other fields of the received in the B-SFRR- 379 Ready Extended ASSOCIATION ID in the RSVP Path message are copied 380 into the B-SFRR-Ready Extended ASSOCIATION ID to be added in the Resv 381 message. The MESSAGE_ID object is set according to [RFC2961] with 382 the Flags being clear. A new Message_Identifier MUST be used to 383 acknowledge an updated PLR assignment. 385 The PLR considers the protected LSP as Summary FRR capable only if 386 all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are 387 sent in the RSVP Path message and the ones received in the RSVP Resv 388 message (with exception of the MESSAGE_ID) match. If it does not 389 match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a 390 subsequent refresh, the PLR node MUST consider the protected LSP as 391 not Summary FRR capable. 393 3.2. B-SFRR-Active Extended ASSOCIATION Object 395 The Extended ASSOCIATION object for B-SFRR-Active association type is 396 populated by a PLR node to indicate to the MP node (bypass tunnel 397 destination) that one or more groups of protected LSPs that are being 398 protected by the specified bypass tunnel are being rerouted over the 399 bypass tunnel. 401 The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP 402 Path message of a bypass LSP and signaled downstream towards the MP 403 (bypass LSP destination). 405 The Association Type, Association ID, and Association Source MUST be 406 set as defined in [RFC4872] for the ASSOCIATION Object. More 407 specifically: 409 Association Source: 411 The Association Source is set to an address of the PLR node. 413 Association Type: 415 A new Association Type is defined for B-SFRR-Active as follows: 417 Value Type 418 ------- ------ 419 (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) 421 Extended ASSOCIATION ID for B-SFRR-Active: 423 The B-SFRR-Active Extended ASSOCIATION ID is 424 populated by the PLR for the Bypass Summary FRR Active association. 425 The rules to populate the Extended ASSOCIATION ID in this case are 426 described below. 428 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID 430 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Active association 431 type is carried inside the IPv4 Extended ASSOCIATION object and has 432 the following format: 434 0 1 2 3 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Num-BGIDs | Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Bypass_Group_Identifier | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | : | 442 // : // 443 | : | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Bypass_Group_Identifier | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 // RSVP_HOP_Object // 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 // TIME_VALUES // 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | IPv4 tunnel sender address | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 3: The IPv4 Extended ASSOCIATION ID for B-SFRR-Active 456 Num-BGIDs: 16 bits 458 Number of Bypass_Group_Identifier fields. 460 Reserved: 16 bits 462 Reserved for future use. 464 Bypass_Group_Identifier: 32 bits 466 The Bypass_Group_Identifier that is previously signaled by the PLR 467 using the Extended Association object. One or more 468 Bypass_Group_Identifiers may be included. 470 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 472 Replacement RSVP HOP object to be applied to all LSPs associated 473 with each of the following Bypass_Group_Identifiers. This 474 corresponds to C-Type = 1 for IPv4 RSVP HOP. 476 TIME_VALUES object: Class 5, as defined by [RFC2205] 478 Replacement TIME_VALUES object to be applied to all LSPs 479 associated with each of the following Bypass_Group_Identifiers 480 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 482 IPv4 tunnel sender address: 484 The IPv4 address that the PLR sets to identify backup path(s) as 485 described in Section 6.1.1 of [RFC4090]. 487 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID 489 The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association 490 type is carried inside the IPv6 Extended ASSOCIATION object and has 491 the following format: 493 0 1 2 3 494 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Num-BGIDs | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Bypass_Group_Identifier | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | : | 501 // : // 502 | : | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Bypass_Group_Identifier | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 // RSVP_HOP_Object // 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 // TIME_VALUES // 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | | 511 + + 512 | | 513 + IPv6 tunnel sender address + 514 | | 515 + + 516 | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 4: The IPv6 Extended ASSOCIATION ID for B-SFRR-Active 521 Num-BGIDs: 16 bits 522 Number of Bypass_Group_Identifier fields. 524 Reserved: 16 bits 526 Reserved for future use. 528 Bypass_Group_Identifier: 32 bits 530 The Bypass_Group_Identifier that is previously signaled by the PLR 531 using the Extended Association object. One or more 532 Bypass_Group_Identifiers may be included. 534 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 536 Replacement RSVP HOP object to be applied to all LSPs associated 537 with each of the following Bypass_Group_Identifiers. This 538 corresponds to C-Type = 2 for IPv6 RSVP HOP. 540 TIME_VALUES object: Class 5, as defined by [RFC2205] 542 Replacement TIME_VALUES object to be applied to all LSPs 543 associated with each of the following Bypass_Group_Identifiers 544 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 546 IPv6 tunnel sender address: 548 The IPv6 address that the PLR sets to identify backup path(s) as 549 described in Section 6.1.1 of [RFC4090]. 551 3.3. Signaling Procedures Prior to Failure 553 Before Summary FRR procedures can be used, a handshake MUST be 554 completed between the PLR and MP. This handshake is performed using 555 Extended ASSOCIATION object that carries the B-SFRR-Ready Extended 556 Association ID in both the RSVP Path and Resv messages of the 557 protected LSP. 559 When using procedures defined in this document, the PLR MUST ensure 560 bypass tunnel assignment can satisfy the protected LSP MTU 561 requirements post FRR. This avoids any packets from being dropped 562 due to exceeding the MTU size of the bypass tunnel after traffic is 563 rerouted on the bypass tunnel post failure. 565 3.3.1. PLR Signaling Procedure 567 The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in 568 the RSVP Path message of the protected LSP to record the bypass 569 tunnel assignment. This object is updated every time the PLR updates 570 the bypass tunnel assignment and that triggers an RSVP Path change 571 message. 573 Upon receiving an RSVP Resv message with B-SFRR-Ready Extended 574 ASSOCIATION object, the PLR node checks if the expected subobjects 575 from the B-SFRR-Ready ASSOCIATION ID are present. If present, the 576 PLR determines if the MP has acknowledged the current PLR assignment. 578 To be a valid acknowledgement, the received B-SFRR-Ready ASSOCIATION 579 ID contents within the RSVP Resv message of the protected LSP MUST 580 match the latest B-SFRR-Ready Extended ASSOCIATION object and 581 Association ID contents that the PLR node had sent within the RSVP 582 Path message (with exception of the MESSAGE_ID). 584 Note, when forwarding an RSVP Resv message upstream, the PLR node 585 SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose 586 Association Source matches the PLR node address. 588 3.3.2. MP Signaling Procedure 590 Upon receiving an RSVP Path message with a B-SFRR-Ready Extended 591 ASSOCIATION object, the MP node processes all (there may be multiple 592 PLRs for a single MP) B-SFRR-Ready Extended ASSOCIATION objects that 593 have the MP node address as Bypass Destination address in the 594 Association ID. 596 The MP node first ensures the existence of the bypass tunnel and that 597 the Bypass_Group_Identifier is not already FRR active. That is, an 598 LSP cannot join a group that is already FRR rerouted. 600 The MP node builds a mirrored Summary FRR Group database per PLR, 601 which is determined using the Bypass_Source_Address field. The 602 MESSAGE_ID is extracted and recorded for the protected LSP PATH 603 state. The MP node signals a B-SFRR-Ready Extended Association 604 object and Association ID in the RSVP Resv message of the protected 605 LSP. With exception of the MESSAGE_ID objects, all other fields of 606 the received B-SFRR-Ready Extended ASSOCIATION object in the RSVP 607 Path message are copied into the B-SFRR-Ready Extended ASSOCIATION 608 object to be added in the Resv message. The MESSAGE_ID object is set 609 according to [RFC2961] with the Flags being clear. 611 Note, an MP may receive more than one RSVP Path message with the B- 612 SFRR-Ready Extended ASSOCIATION object from different upstream PLR 613 node(s). In this case, the MP node is expected to save all the 614 received MESSAGE_IDs from the different upstream PLR node(s). After 615 a failure, the MP node determines and activates the associated 616 Summary Refresh ID to use once it receives and processes the RSVP 617 Path message containing B-SFRR-Active Extended ASSOCIATION object 618 that is signaled over the bypass LSP from the PLR, as described 619 Section 3.4 621 When forwarding an RSVP Path message downstream, the MP SHOULD remove 622 any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association 623 ID contains Bypass_Destination_Address matching the MP node address. 625 3.4. Signaling Procedures Post Failure 627 Upon detection of the fault (egress link or node failure) the PLR 628 first performs the object modification procedures described by 629 Section 6.4.3 of [RFC4090] for all affected protected LSPs. For 630 Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP 631 and SENDER_TEMPLATE MUST be used. 633 The PLR MUST signal non-Summary FRR enabled LSPs over the bypass 634 tunnel before signaling the Summary FRR enabled LSPs. This is needed 635 to allow for the case when the PLR node has recently changed a bypass 636 assignment and the MP has not processed the change yet. 638 The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP 639 Path message of the bypass LSP to reroute RSVP state of Summary FRR 640 enabled LSPs. 642 3.4.1. PLR Signaling Procedure 644 After a failure event, when using the Summary FRR path signaling 645 procedures, an individual RSVP Path message for each Summary FRR LSP 646 is not signaled. Instead, to reroute Summary FRR LSPs via the bypass 647 tunnel, the PLR adds the B-SFRR-Active Extended Association object in 648 the RSVP Path message of the RSVP session of the bypass tunnel. 650 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION 651 ID is set to the common RSVP_HOP that was used by the PLR in 652 Section 3.4 of this document. 654 The previously received MESSAGE_ID from the MP is activated. As a 655 result, the MP may refresh the protected rerouted RESV state using 656 Summary Refresh procedures. 658 For each affected Summary FRR group, its Bypass_Group_Identifier is 659 added to B-SFRR-Active Extended ASSOCIATION ID. 661 3.4.2. MP Signaling Procedure 663 Upon receiving an RSVP Path message with a B-SFRR-Active Extended 664 Association object, the MP performs normal merge point processing for 665 each protected LSP associated with each Bypass_Group_Identifier, as 666 if it received individual RSVP Path messages for the LSP. 668 For each Summary FRR LSP being merged, the MP first modifies the Path 669 state as follows: 671 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended 672 ASSOCIATION ID. 674 2. The TIME_VALUES object is copied from the TIMES_VALUE field in 675 the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES 676 object contains the refresh time of the PLR to generate refreshes 677 and that would have exchanged in a Path message sent to the MP 678 after the failure when no SFRR procedures are in effect. 680 3. The tunnel sender address field in the SENDER_TEMPLATE object is 681 copied from the tunnel sender address of the B-SFRR-Active 682 Extended ASSOCIATION ID. 684 4. The ERO object is modified as per Section 6.4.4 of [RFC4090]. 685 Once the above modifications are completed, the MP then performs 686 the merge processing as per [RFC4090]. 688 5. The previously received MESSAGE_ID from the PLR is activated, 689 meaning that the PLR may now refresh the protected rerouted PATH 690 state using Summary Refresh procedures. 692 A failure during merge processing of any individual rerouted LSP MUST 693 result in an RSVP Path Error message. 695 An individual RSVP Resv message for each successfully merged Summary 696 FRR LSP is not signaled. The MP node SHOULD immediately use Summary 697 Refresh procedures to refresh the protected LSP RESV state. 699 3.5. Refreshing Summary FRR Active LSPs 701 Refreshing of Summary FRR active LSPs is performed using Summary 702 Refresh as defined by [RFC2961]. 704 4. Compatibility 706 The (Extended) ASSOCIATION object is defined in [RFC4872] with a 707 class number in the form 11bbbbbb, which ensures compatibility with 708 non-supporting node(s). Such nodes will ignore the object and 709 forward it without modification. 711 5. Security Considerations 713 This document updates an existing RSVP object. Thus, in the event of 714 the interception of a signaling message, a slightly more information 715 could be deduced about the state of the network than was previously 716 the case. Existing mechanisms for maintaining the integrity and 717 authenticity of RSVP protocol messages [RFC2747] can be applied. 718 Other considerations mentioned in [RFC4090] and [RFC5920] also apply. 720 6. IANA Considerations 722 IANA maintains the "Generalized Multi-Protocol Label Switching 723 (GMPLS) Signaling Parameters" registry (see 724 http://www.iana.org/assignments/gmpls-sig-parameters [1]). The 725 "Association Type" subregistry is included in this registry. 727 This registry has been updated by new Association Type for Extended 728 ASSOCIATION Object defined in this document as follows: 730 Value Name Reference 731 ----- ---- --------- 732 TBD-1 B-SFRR-Ready Association Section 3.1 733 TBD-2 B-SFRR-Active Association Section 3.2 735 IANA also maintains and assigns the values for the RSVP-TE protocol 736 parameters "Resource Reservation Protocol (RSVP) Parameters" (see 737 http://www.iana.org/assignments/rsvp-parameters). 739 7. Acknowledgments 741 The authors would like to thank Alexander Okonnikov, Loa Andersson, 742 Lou Berger, Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and 743 providing valuable comments to this document. 745 8. Contributors 747 Nicholas Tan 748 Arista Networks 750 Email: ntan@arista.com 752 9. References 754 9.1. Normative References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, 758 DOI 10.17487/RFC2119, March 1997, 759 . 761 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 762 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 763 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 764 September 1997, . 766 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 767 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 768 2000, . 770 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 771 and S. Molendini, "RSVP Refresh Overhead Reduction 772 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 773 . 775 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 776 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 777 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 778 . 780 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 781 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 782 DOI 10.17487/RFC4090, May 2005, 783 . 785 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 786 Ed., "RSVP-TE Extensions in Support of End-to-End 787 Generalized Multi-Protocol Label Switching (GMPLS) 788 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 789 . 791 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 792 ASSOCIATION Object Extensions", RFC 6780, 793 DOI 10.17487/RFC6780, October 2012, 794 . 796 9.2. Informative References 798 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 799 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 800 . 802 9.3. URIs 804 [1] http://www.iana.org/assignments/gmpls-sig-parameters 806 Authors' Addresses 808 Mike Taillon 809 Cisco Systems, Inc. 811 Email: mtaillon@cisco.com 813 Tarek Saad (editor) 814 Juniper Networks 816 Email: tsaad@juniper.net 818 Rakesh Gandhi 819 Cisco Systems, Inc. 821 Email: rgandhi@cisco.com 823 Abhishek Deshmukh 824 Juniper Networks 826 Email: adeshmukh@juniper.net 828 Markus Jork 829 128 Technology 831 Email: mjork@128technology.com 833 Vishnu Pavan Beeram 834 Juniper Networks 836 Email: vbeeram@juniper.net