idnits 2.17.1 draft-ietf-mpls-summary-frr-rsvpte-03.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 02, 2019) is 1820 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 727 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 3, 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 02, 2019 16 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 17 draft-ietf-mpls-summary-frr-rsvpte-03 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 3, 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. B-SFRR-Active Extended ASSOCIATION ID . . . . . . . . 11 76 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 12 77 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 12 78 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 12 79 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 13 80 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 13 81 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 14 82 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 15 83 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 15 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 9.2. Informative References . . . . . . . . . . . . . . . . . 17 91 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 The Fast Reroute (FRR) procedures defined in [RFC4090] describe the 97 mechanisms for the Point of Local Repair (PLR) to reroute traffic and 98 signaling of a protected RSVP-TE LSP onto the bypass tunnel in the 99 event of a TE link or node failure. Such signaling procedures are 100 performed individually for each affected protected LSP. This may 101 eventually lead to control plane scalability and latency issues on 102 the PLR and/or the MP due to limited memory and CPU processing 103 resources. This condition is exacerbated when the failure affects 104 large number of protected LSPs that traverse the same PLR and Merge 105 Point (MP) nodes. 107 For example, in a large scale RSVP-TE LSPs deployment, a single LSR 108 acting as a PLR node may host tens of thousands of protected RSVP-TE 109 LSPs egressing the same link, and also act as a MP node for similar 110 number of LSPs ingressing the same link. In the event of the failure 111 of the link or neighbor node, the RSVP-TE control plane of the node 112 when acting as PLR becomes busy rerouting protected LSPs signaling 113 over the bypass tunnel(s) in one direction, and when acting as an MP 114 node becomes busy merging RSVP states from signaling received over 115 bypass tunnels for LSP(s) in the reverse direction. Subsequently, 116 the head-end LER(s) that are notified of the local repair at 117 downstream LSR will attempt to (re)converge affected RSVP- TE LSPs 118 onto newly computed paths - possibly traversing the same previously 119 affected LSR(s). As a result, the RSVP-TE control plane at the PLR 120 and MP becomes overwhelmed by the amount of FRR RSVP-TE processing 121 overhead following the link or node failure, and the competing other 122 control plane protocol(s) (e.g. the IGP) that undergo their 123 convergence at the same time. 125 The extensions defined in this document enable a MP node to become 126 aware of the PLR node's bypass tunnel assignment group and allow FRR 127 procedures between PLR node and MP node to be signaled and processed 128 on groups of LSPs. 130 As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to 131 refresh the RSVP Path and Resv states to help with the scale. The 132 MESSAGE_ID information for the rerouted PATH and RESV states are 133 exchanged between PLR and MP nodes between PLR and MP nodes a priori 134 to the fault such that Summary Refresh procedures defined in 135 [RFC2961] can continue to be used to refresh the rerouted state(s) 136 after FRR has occurred. 138 2. Conventions Used in This Document 140 2.1. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119]. 147 2.2. Acronyms and Abbreviations 149 The reader is assumed to be familiar with terms and abbreviations 150 used in [RFC3209] and [RFC4090]. 152 The following abbreviations are also used in this document: 154 LSR: Label Switching Router 156 LER: Label Edge Router 158 MPLS: Multiprotocol Label Switching 160 LSP: Label Switched Path 162 MP: Merge Point node as defined in [RFC4090] 164 PLR: Point of Local Repair node as defined in [RFC4090] 166 FRR: Fast Reroute as defined in [RFC4090] 168 B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION 169 object. Added by the PLR for each LSP protected by the bypass 170 tunnel. 172 B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION 173 object. Used to notify the MP node of one ore more groups of 174 protected LSP(s) that are being protected by the specified bypass 175 tunnel are being rerouted. 177 3. Extensions for Summary FRR Signaling 179 The RSVP ASSOCIATION object is defined in [RFC4872] as a means to 180 associate LSPs with each other. For example, in the context of 181 GMPLS-controlled LSP(s), the object is used to associate recovery 182 LSPs with the LSP they are protecting. The Extended ASSOCIATION 183 object is introduced in [RFC6780] to expand on the possible usage of 184 the ASSOCIATION object and generalize the definition of the Extended 185 Association ID field. 187 This document proposes the use of the Extended ASSOCIATION object to 188 carry the Summary FRR information and associate the protected LSP(s) 189 with the bypass tunnel that protects them. Two new Association Types 190 for the Extended ASSOCIATION object, and new Extended Association IDs 191 are proposed in this draft to describe the Bypass Summary FRR Ready 192 (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active) 193 associations. 195 The PLR creates and manages the Summary FRR LSP groups 196 (Bypass_Group_Identifiers) and shares them with the MP via signaling. 197 Protected LSPs sharing the same egress link and bypass assignment are 198 grouped together and are assigned the same group. The MP maintains 199 the PLR group assignments learned via signaling, and acknowledges the 200 group assignments via signaling. Once the PLR receives the 201 acknowledgment, FRR signaling can proceed as group based. 203 The PLR node that supports Summary FRR procedures adds the Extended 204 ASSOCIATION object with Type B-SFRR-Ready and respective Extended 205 Association ID in the RSVP Path message of the protected LSP to 206 inform the MP of the PLR's assigned bypass tunnel, Summary FRR 207 Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to 208 refresh the protected LSP PATH state after FRR occurs. 210 The MP node that supports Summary FRR procedures adds the B-SFRR- 211 Ready Extended ASSOCIATION object and respective Extended Association 212 ID in the RSVP Resv message of the protected LSP to acknowledge the 213 PLR's bypass tunnel assignment, and provide the MESSAGE_ID object 214 that the MP node will use to refresh the protected LSP RESV state 215 after FRR occurs. 217 This document also defines a new Association Type for the Extended 218 ASSOCIATION object and new Extended Association ID to describe the B- 219 SFRR-Active association. The B-SFRR-Active Extended ASSOCIATION 220 object and Extended Association ID are sent by PLR after activating 221 FRR procedures on the PLR. The B-SFRR-Active Extended ASSOCIATION 222 object and Extended Association ID are sent within the RSVP Path 223 message of the bypass LSP to inform the MP node that one or more 224 groups of protected LSPs protected by the bypass tunnel are now being 225 rerouted over the bypass tunnel. 227 3.1. B-SFRR-Ready Extended ASSOCIATION Object 229 The Extended ASSOCIATION object is populated using the rules defined 230 below to associate a protected LSP with the bypass LSP that is 231 protecting it when Summary FRR procedures are enabled. 233 The Association Type, Association ID, and Association Source MUST be 234 set as defined in [RFC4872] for the ASSOCIATION Object. More 235 specifically: 237 Association Source: 239 The Association Source is set to an address of the PLR node. 241 Association Type: 243 A new Association Type is defined for B-SFRR-Ready as follows: 245 Value Type 246 ------- ------ 247 (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) 249 Extended ASSOCIATION ID for B-SFRR-Ready: 251 The B-SFRR-Ready Extended ASSOCIATION ID is 252 populated by the PLR for the Bypass Summary FRR Ready association. 253 The rules to populate the Extended ASSOCIATION ID in this case are 254 described below. 256 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID 258 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association 259 type has the following format: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Bypass_Tunnel_ID | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Bypass_Source_IPv4_Address | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Bypass_Destination_IPv4_Address | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Bypass_Group_Identifier | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | MESSAGE_ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready 277 Bypass_Tunnel_ID: 16 bits 279 The bypass tunnel identifier. 281 Reserved: 16 bits 283 Reserved for future use. 285 Bypass_Source_IPv4_Address: 32 bits 287 The bypass tunnel source IPV4 address. 289 Bypass_Destination_IPv4_Address: 32 bits 291 The bypass tunnel destination IPV4 address. 293 Bypass_Group_Identifier: 32 bits 295 The bypass tunnel group identifier. 297 MESSAGE_ID 299 A MESSAGE_ID object as defined by [RFC2961]. 301 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID 303 The IPv6 Extended ASSOCIATION ID field for the B-SFRR-Ready 304 association type has the following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Bypass_Tunnel_ID | Reserved | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 + + 313 | | 314 + Bypass_Source_IPv6_Address + 315 | | 316 + + 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 + + 321 | | 322 + Bypass_Destination_IPv6_Address + 323 | | 324 + + 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Bypass_Group_Identifier | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | MESSAGE_ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready 334 Bypass_Tunnel_ID: 16 bits 336 The bypass tunnel identifier. 338 Reserved: 16 bits 340 Reserved for future use. 342 Bypass_Source_IPv6_Address: 128 bits 344 The bypass tunnel source IPV6 address. 346 Bypass_Destination_IPv6_Address: 128 bits 348 The bypass tunnel destination IPV6 address. 350 Bypass_Group_Identifier: 32 bits 352 The bypass tunnel group identifier. 354 MESSAGE_ID 356 A MESSAGE_ID object as defined by [RFC2961]. 358 The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each 359 protected LSP. The same Bypass_Group_Identifier is used for the set 360 of protected LSPs that share the same bypass tunnel and traverse the 361 same egress link and are not already rerouted. The PLR also 362 generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and 363 Message_Identifier MUST be set according to [RFC2961]). 365 The PLR MUST generate a new Message_Identifier each time the contents 366 of the B-SFRR-Ready Extended ASSOCIATION ID changes; for example, 367 when PLR node changes the bypass tunnel assignment. 369 The PLR node notifies the MP node of the bypass tunnel assignment via 370 adding a B-SFRR-Ready Extended ASSOCIATION object and Association ID 371 in the RSVP Path message for the protected LSP using procedures 372 described in Section 3.4. 374 The MP node acknowledges the PLR node assignment by signaling the B- 375 SFRR-Ready Extended ASSOCIATION object and Association ID within the 376 RSVP Resv message of the protected LSP. With exception of the 377 MESSAGE_ID objects, all other fields of the received in the B-SFRR- 378 Ready Extended ASSOCIATION ID in the RSVP Path message are copied 379 into the B-SFRR-Ready Extended ASSOCIATION ID to be added in the Resv 380 message. The MESSAGE_ID object is set according to [RFC2961] with 381 the Flags being clear. A new Message_Identifier MUST be used to 382 acknowledge an updated PLR assignment. 384 The PLR considers the protected LSP as Summary FRR capable only if 385 all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are 386 sent in the RSVP Path message and the ones received in the RSVP Resv 387 message (with exception of the MESSAGE_ID) match. If it does not 388 match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a 389 subsequent refresh, the PLR node MUST consider the protected LSP as 390 not Summary FRR capable. 392 3.2. B-SFRR-Active Extended ASSOCIATION Object 394 The Extended ASSOCIATION object for B-SFRR-Active association type is 395 populated by a PLR node to indicate to the MP node (bypass tunnel 396 destination) that one or more groups of protected LSPs that are being 397 protected by the specified bypass tunnel are being rerouted over the 398 bypass tunnel. 400 The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP 401 Path message of a bypass LSP and signaled downstream towards the MP 402 (bypass LSP destination). 404 The Association Type, Association ID, and Association Source MUST be 405 set as defined in [RFC4872] for the ASSOCIATION Object. More 406 specifically: 408 Association Source: 410 The Association Source is set to an address of the PLR node. 412 Association Type: 414 A new Association Type is defined for B-SFRR-Active as follows: 416 Value Type 417 ------- ------ 418 (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) 420 Extended ASSOCIATION ID for B-SFRR-Active: 422 The B-SFRR-Active Extended ASSOCIATION ID is 423 populated by the PLR for the Bypass Summary FRR Active association. 424 The rules to populate the Extended ASSOCIATION ID in this case are 425 described below. 427 3.2.1. B-SFRR-Active Extended ASSOCIATION ID 429 The Extended ASSOCIATION ID for the B-SFRR-Active association type 430 has the following format: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Num-BGIDs | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Bypass_Group_Identifier | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | : | 440 // : // 441 | : | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Bypass_Group_Identifier | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | RSVP_HOP_Object | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | TIME_VALUES | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 3: The Extended ASSOCIATION ID for B-SFRR-Active 452 Num-BGIDs: 16 bits 454 Number of Bypass_Group_Identifier fields. 456 Reserved: 16 bits 458 Reserved for future use. 460 Bypass_Group_Identifier: 32 bits 462 The Bypass_Group_Identifier that is previously signaled by the 463 PLR using the Extended Association object. One or 464 more Bypass_Group_Identifiers may be included. 466 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 468 Replacement RSVP HOP object to be applied to all LSPs associated 469 with each of the following Bypass_Group_Identifiers. This corresponds 470 to C-Type = 1 for IPv4 RSVP HOP, or C-Type = 2 for IPv6 RSVP HOP 471 depending on the IP address family carried within the object. 473 TIME_VALUES object: Class 5, as defined by [RFC2205] 474 Replacement TIME_VALUES object to be applied to all LSPs associated 475 with each of the following Bypass_Group_Identifiers after receiving 476 the B-SFRR-Active Extended ASSOCIATION Object. 478 3.3. Signaling Procedures Prior to Failure 480 Before Summary FRR procedures can be used, a handshake MUST be 481 completed between the PLR and MP. This handshake is performed using 482 Extended ASSOCIATION object that carries the B-SFRR-Ready Extended 483 Association ID in both the RSVP Path and Resv messages of the 484 protected LSP. 486 3.3.1. PLR Signaling Procedure 488 The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in 489 the RSVP Path message of the protected LSP to record the bypass 490 tunnel assignment. This object is updated every time the PLR updates 491 the bypass tunnel assignment and that triggers an RSVP Path change 492 message. 494 Upon receiving an RSVP Resv message with B-SFRR-Ready Extended 495 ASSOCIATION object, the PLR node checks if the expected subobjects 496 from the B-SFRR-Ready ASSOCIATION ID are present. If present, the 497 PLR determines if the MP has acknowledged the current PLR assignment. 499 To be a valid acknowledgement, the received B-SFRR-Ready ASSOCIATION 500 ID contents within the RSVP Resv message of the protected LSP MUST 501 match the latest B-SFRR-Ready Extended ASSOCIATION object and 502 Association ID contents that the PLR node had sent within the RSVP 503 Path message (with exception of the MESSAGE_ID). 505 Note, when forwarding an RSVP Resv message upstream, the PLR node 506 SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose 507 Association Source matches the PLR node address. 509 3.3.2. MP Signaling Procedure 511 Upon receiving an RSVP Path message with a B-SFRR-Ready Extended 512 ASSOCIATION object, the MP node processes all (there may be multiple 513 PLRs for a single MP) B-SFRR-Ready Extended ASSOCIATION objects that 514 have the MP node address as Bypass Destination address in the 515 Association ID. 517 The MP node first ensures the existence of the bypass tunnel and that 518 the Bypass_Group_Identifier is not already FRR active. That is, an 519 LSP cannot join a group that is already FRR rerouted. 521 The MP node builds a mirrored Summary FRR Group database per PLR, 522 which is determined using the Bypass_Source_Address field. The 523 MESSAGE_ID is extracted and recorded for the protected LSP PATH 524 state. The MP node signals a B-SFRR-Ready Extended Association 525 object and Association ID in the RSVP Resv message of the protected 526 LSP. With exception of the MESSAGE_ID objects, all other fields of 527 the received B-SFRR-Ready Extended ASSOCIATION object in the RSVP 528 Path message are copied into the B-SFRR-Ready Extended ASSOCIATION 529 object to be added in the Resv message. The MESSAGE_ID object is set 530 according to [RFC2961] with the Flags being clear. 532 Note, an MP may receive more than one RSVP Path message with the B- 533 SFRR-Ready Extended ASSOCIATION object from different upstream PLR 534 node(s). In this case, the MP node is expected to save all the 535 received MESSAGE_IDs from the different upstream PLR node(s). After 536 a failure, the MP node determines and activates the associated 537 Summary Refresh ID to use once it receives and processes the RSVP 538 Path message containing B-SFRR-Active Extended ASSOCIATION object 539 that is signaled over the bypass LSP from the PLR, as described 540 Section 3.4 542 When forwarding an RSVP Path message downstream, the MP SHOULD remove 543 any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association 544 ID contains Bypass_Destination_Address matching the MP node address. 546 3.4. Signaling Procedures Post Failure 548 Upon detection of the fault (egress link or node failure) the PLR 549 first performs the object modification procedures described by 550 Section 6.4.3 of [RFC4090] for all affected protected LSPs. For 551 Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP 552 and SENDER_TEMPLATE MUST be used. 554 The PLR MUST signal non-Summary FRR enabled LSPs over the bypass 555 tunnel before signaling the Summary FRR enabled LSPs. This is needed 556 to allow for the case when the PLR node has recently changed a bypass 557 assignment and the MP has not processed the change yet. 559 The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP 560 Path message of the bypass LSP to reroute RSVP state of Summary FRR 561 enabled LSPs. 563 3.4.1. PLR Signaling Procedure 565 After a failure event, when using the Summary FRR path signaling 566 procedures, an individual RSVP Path message for each Summary FRR LSP 567 is not signaled. Instead, to reroute Summary FRR LSPs via the bypass 568 tunnel, the PLR adds the B-SFRR-Active Extended Association object in 569 the RSVP Path message of the RSVP session of the bypass tunnel. 571 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION 572 ID is set to the common RSVP_HOP that was used by the PLR in 573 Section 3.4 of this document. 575 The previously received MESSAGE_ID from the MP is activated. As a 576 result, the MP may refresh the protected rerouted RESV state using 577 Summary Refresh procedures. 579 For each affected Summary FRR group, its Bypass_Group_Identifier is 580 added to B-SFRR-Active Extended ASSOCIATION ID. 582 3.4.2. MP Signaling Procedure 584 Upon receiving an RSVP Path message with a B-SFRR-Active Extended 585 Association object, the MP performs normal merge point processing for 586 each protected LSP associated with each Bypass_Group_Identifier, as 587 if it received individual RSVP Path messages for the LSP. 589 For each Summary FRR LSP being merged, the MP first modifies the Path 590 state as follows: 592 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended 593 ASSOCIATION ID. 595 2. The TIME_VALUES object is copied from the TIMES_VALUE field in 596 the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES 597 object contains the refresh time of the PLR to generate refreshes 598 and that would have exchanged in a Path message sent to the MP 599 after the failure when no SFRR procedures are in effect. 601 3. The SENDER_TEMPLATE object SrcAddress field is copied from the 602 bypass tunnel SENDER_TEMPLATE object. For the case where PLR is 603 also the head-end, and SENDER_TEMPLATE SrcAddress of the 604 protected LSP and bypass tunnel are the same, the MP MUST use the 605 modified HOP Address field instead. 607 4. The ERO object is modified as per Section 6.4.4. of [RFC4090]. 608 Once the above modifications are completed, the MP then performs 609 the merge processing as per [RFC4090]. 611 5. The previously received MESSAGE_ID from the PLR is activated, 612 meaning that the PLR may now refresh the protected rerouted PATH 613 state using Summary Refresh procedures. 615 A failure during merge processing of any individual rerouted LSP MUST 616 result in an RSVP Path Error message. 618 An individual RSVP Resv message for each successfully merged Summary 619 FRR LSP is not signaled. The MP node SHOULD immediately use Summary 620 Refresh procedures to refresh the protected LSP RESV state. 622 3.5. Refreshing Summary FRR Active LSPs 624 Refreshing of Summary FRR active LSPs is performed using Summary 625 Refresh as defined by [RFC2961]. 627 4. Compatibility 629 The (Extended) ASSOCIATION object is defined in [RFC4872] with a 630 class number in the form 11bbbbbb, which ensures compatibility with 631 non-supporting node(s). Such nodes will ignore the object and 632 forward it without modification. 634 5. Security Considerations 636 This document updates an existing RSVP object. Thus, in the event of 637 the interception of a signaling message, a slightly more information 638 could be deduced about the state of the network than was previously 639 the case. Existing mechanisms for maintaining the integrity and 640 authenticity of RSVP protocol messages [RFC2747] can be applied. 641 Other considerations mentioned in [RFC4090] and [RFC5920] also apply. 643 6. IANA Considerations 645 IANA maintains the "Generalized Multi-Protocol Label Switching 646 (GMPLS) Signaling Parameters" registry (see 647 http://www.iana.org/assignments/gmpls-sig-parameters [1]). The 648 "Association Type" subregistry is included in this registry. 650 This registry has been updated by new Association Type for Extended 651 ASSOCIATION Object defined in this document as follows: 653 Value Name Reference 654 ----- ---- --------- 655 TBD-1 B-SFRR-Ready Association Section 3.1 656 TBD-2 B-SFRR-Active Association Section 3.2 658 IANA also maintains and assigns the values for the RSVP-TE protocol 659 parameters "Resource Reservation Protocol (RSVP) Parameters" (see 660 http://www.iana.org/assignments/rsvp-parameters). 662 7. Acknowledgments 664 The authors would like to thank Loa Andersson, Lou Berger, Eric 665 Osborne, Gregory Mirsky, and Mach Chen for reviewing and providing 666 valuable comments to this document. 668 8. Contributors 670 Nicholas Tan 671 Arista Networks 673 Email: ntan@arista.com 675 9. References 677 9.1. Normative References 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, 681 DOI 10.17487/RFC2119, March 1997, 682 . 684 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 685 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 686 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 687 September 1997, . 689 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 690 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 691 2000, . 693 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 694 and S. Molendini, "RSVP Refresh Overhead Reduction 695 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 696 . 698 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 699 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 700 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 701 . 703 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 704 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 705 DOI 10.17487/RFC4090, May 2005, 706 . 708 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 709 Ed., "RSVP-TE Extensions in Support of End-to-End 710 Generalized Multi-Protocol Label Switching (GMPLS) 711 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 712 . 714 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 715 ASSOCIATION Object Extensions", RFC 6780, 716 DOI 10.17487/RFC6780, October 2012, 717 . 719 9.2. Informative References 721 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 722 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 723 . 725 9.3. URIs 727 [1] http://www.iana.org/assignments/gmpls-sig-parameters 729 Authors' Addresses 731 Mike Taillon 732 Cisco Systems, Inc. 734 Email: mtaillon@cisco.com 736 Tarek Saad (editor) 737 Juniper Networks 739 Email: tsaad@juniper.net 741 Rakesh Gandhi 742 Cisco Systems, Inc. 744 Email: rgandhi@cisco.com 746 Abhishek Deshmukh 747 Juniper Networks 749 Email: adeshmukh@juniper.net 750 Markus Jork 751 128 Technology 753 Email: mjork@128technology.com 755 Vishnu Pavan Beeram 756 Juniper Networks 758 Email: vbeeram@juniper.net