idnits 2.17.1 draft-ietf-mpls-summary-frr-rsvpte-02.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 (November 03, 2018) is 1972 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 688 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 T. Saad, Ed. 4 Intended status: Standards Track R. Gandhi 5 Expires: May 7, 2019 Cisco Systems, Inc. 6 A. Deshmukh 7 M. Jork 8 V. Beeram 9 Juniper Networks 10 November 03, 2018 12 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 13 draft-ietf-mpls-summary-frr-rsvpte-02 15 Abstract 17 This document defines Resource Reservation Protocol (RSVP) Traffic- 18 Engineering (TE) signaling extensions that reduce the amount of RSVP 19 signaling required for Fast Reroute (FRR) procedures and subsequently 20 improve the scalability of the RSVP-TE signaling when undergoing FRR 21 convergence after a link or node failure. Such extensions allow the 22 RSVP message exchange between the Point of Local Repair (PLR) and the 23 Merge Point (MP) to be independent of the number of protected Label 24 Switched Paths (LSPs) traversing between them when facility bypass 25 FRR protection is used. The signaling extensions are fully backwards 26 compatible with nodes that do not support them. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 7, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 4 67 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 5 68 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 5 69 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 6 70 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 9 71 3.2.1. B-SFRR-Active Extended ASSOCIATION ID . . . . . . . . 10 72 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 11 73 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 11 74 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 11 75 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 12 76 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 12 77 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 13 78 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 14 79 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The Fast Reroute (FRR) procedures defined in [RFC4090] describe the 92 mechanisms for the Point of Local Repair (PLR) to reroute traffic and 93 signaling of a protected RSVP-TE LSP onto the bypass tunnel in the 94 event of a TE link or node failure. Such signaling procedures are 95 performed individually for each affected protected LSP. This may 96 eventually lead to control plane scalability and latency issues on 97 the PLR and/or the MP due to limited memory and CPU processing 98 resources. This condition is exacerbated when the failure affects 99 large number of protected LSPs that traverse the same PLR and Merge 100 Point (MP) nodes. 102 For example, in a large scale RSVP-TE LSPs deployment, a single LSR 103 acting as a PLR node may host tens of thousands of protected RSVP-TE 104 LSPs egressing the same link, and also act as a MP node for similar 105 number of LSPs ingressing the same link. In the event of the failure 106 of the link or neighbor node, the RSVP-TE control plane of the node 107 when acting as PLR becomes busy rerouting protected LSPs signaling 108 over the bypass tunnel(s) in one direction, and when acting as an MP 109 node becomes busy merging RSVP states from signaling received over 110 bypass tunnels for LSP(s) in the reverse direction. Subsequently, 111 the head-end LER(s) that are notified of the local repair at 112 downstream LSR will attempt to (re)converge affected RSVP- TE LSPs 113 onto newly computed paths - possibly traversing the same previously 114 affected LSR(s). As a result, the RSVP-TE control plane at the PLR 115 and MP becomes overwhelmed by the amount of FRR RSVP-TE processing 116 overhead following the link or node failure, and the competing other 117 control plane protocol(s) (e.g. the IGP) that undergo their 118 convergence at the same time. 120 The extensions defined in this document enable a MP node to become 121 aware of the PLR node's bypass tunnel assignment group and allow FRR 122 procedures between PLR node and MP node to be signaled and processed 123 on groups of LSPs. 124 As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to 125 refresh the RSVP Path and Resv states to help with the scale. The 126 MESSAGE_ID information for the rerouted PATH and RESV states are 127 exchanged between PLR and MP nodes between PLR and MP nodes a priori 128 to the fault such that Summary Refresh procedures defined in 129 [RFC2961] can continue to be used to refresh the rerouted state(s) 130 after FRR has occurred. 132 2. Conventions Used in This Document 133 2.1. Key Word Definitions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in BCP 14, RFC 2119 138 [RFC2119]. 140 2.2. Terminology 142 The reader is assumed to be familiar with the terminology in 143 [RFC3209] and [RFC4090]. 145 3. Extensions for Summary FRR Signaling 147 The RSVP ASSOCIATION object is defined in [RFC4872] as a means to 148 associate LSPs with each other. For example, in the context of 149 GMPLS-controlled LSP(s), the object is used to associate recovery 150 LSPs with the LSP they are protecting. The Extended ASSOCIATION 151 object is introduced in [RFC6780] to expand on the possible usage of 152 the ASSOCIATION object and generalize the definition of the Extended 153 Association ID field. 155 This document proposes the use of the Extended ASSOCIATION object to 156 carry the Summary FRR information and associate the protected LSP(s) 157 with the bypass tunnel that protects them. Two new Association Types 158 for the Extended ASSOCIATION object, and new Extended Association IDs 159 are proposed in this draft to describe the Bypass Summary FRR Ready 160 (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active) 161 associations. 163 The PLR creates and manages the Summary FRR LSP groups 164 (Bypass_Group_Identifiers) and shares them with the MP via signaling. 165 Protected LSPs sharing the same egress link and bypass assignment are 166 grouped together and are assigned the same group. The MP maintains 167 the PLR group assignments learned via signaling, and acknowledges the 168 group assignments via signaling. Once the PLR receives the 169 acknowledgment, FRR signaling can proceed as group based. 171 The PLR node that supports Summary FRR procedures adds the Extended 172 ASSOCIATION object with Type B-SFRR-Ready and respective Extended 173 Association ID in the RSVP Path message of the protected LSP to 174 inform the MP of the PLR's assigned bypass tunnel, Summary FRR 175 Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to 176 refresh the protected LSP PATH state after FRR occurs. 178 The MP node that supports Summary FRR procedures adds the B-SFRR- 179 Ready Extended ASSOCIATION object and respective Extended Association 180 ID in the RSVP Resv message of the protected LSP to acknowledge the 181 PLR's bypass tunnel assignment, and provide the MESSAGE_ID object 182 that the MP node will use to refresh the protected LSP RESV state 183 after FRR occurs. 185 This document also defines a new Association Type for the Extended 186 ASSOCIATION object and new Extended Association ID to describe the B- 187 SFRR-Active association. The B-SFRR-Active Extended ASSOCIATION 188 object and Extended Association ID are sent by PLR after activating 189 FRR procedures on the PLR. The B-SFRR-Active Extended ASSOCIATION 190 object and Extended Association ID are sent within the RSVP Path 191 message of the bypass LSP to inform the MP node that one or more 192 groups of protected LSPs protected by the bypass tunnel are now being 193 rerouted over the bypass tunnel. 195 3.1. B-SFRR-Ready Extended ASSOCIATION Object 197 The Extended ASSOCIATION object is populated using the rules defined 198 below to associate a protected LSP with the bypass LSP that is 199 protecting it when Summary FRR procedures are enabled. 201 The Association Type, Association ID, and Association Source MUST be 202 set as defined in [RFC4872] for the ASSOCIATION Object. More 203 specifically: 205 Association Source: 207 The Association Source is set to an address of the PLR node. 209 Association Type: 211 A new Association Type is defined for B-SFRR-Ready as follows: 213 Value Type 214 ------- ------ 215 (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) 217 Extended ASSOCIATION ID for B-SFRR-Ready: 219 The B-SFRR-Ready Extended ASSOCIATION ID is 220 populated by the PLR for the Bypass Summary FRR Ready association. 221 The rules to populate the Extended ASSOCIATION ID in this case are 222 described below. 224 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID 226 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association 227 type has the following format: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Bypass_Tunnel_ID | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Bypass_Source_IPv4_Address | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Bypass_Destination_IPv4_Address | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Bypass_Group_Identifier | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | MESSAGE_ID | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready 245 Bypass_Tunnel_ID: 16 bits 247 The bypass tunnel identifier. 249 Reserved: 16 bits 251 Reserved for future use. 253 Bypass_Source_IPv4_Address: 32 bits 255 The bypass tunnel source IPV4 address. 257 Bypass_Destination_IPv4_Address: 32 bits 259 The bypass tunnel destination IPV4 address. 261 Bypass_Group_Identifier: 32 bits 263 The bypass tunnel group identifier. 265 MESSAGE_ID 267 A MESSAGE_ID object as defined by [RFC2961]. 269 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID 271 The IPv6 Extended ASSOCIATION ID field for the B-SFRR-Ready 272 association type has the following format: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Bypass_Tunnel_ID | Reserved | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | 280 + + 281 | | 282 + Bypass_Source_IPv6_Address + 283 | | 284 + + 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 + + 289 | | 290 + Bypass_Destination_IPv6_Address + 291 | | 292 + + 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Bypass_Group_Identifier | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | MESSAGE_ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready 302 Bypass_Tunnel_ID: 16 bits 304 The bypass tunnel identifier. 306 Reserved: 16 bits 308 Reserved for future use. 310 Bypass_Source_IPv6_Address: 128 bits 312 The bypass tunnel source IPV6 address. 314 Bypass_Destination_IPv6_Address: 128 bits 316 The bypass tunnel destination IPV6 address. 318 Bypass_Group_Identifier: 32 bits 320 The bypass tunnel group identifier. 322 MESSAGE_ID 324 A MESSAGE_ID object as defined by [RFC2961]. 326 The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each 327 protected LSP. The same Bypass_Group_Identifier is used for the set 328 of protected LSPs that share the same bypass tunnel and traverse the 329 same egress link and are not already rerouted. The PLR also 330 generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and 331 Message_Identifier MUST be set according to [RFC2961]). 333 The PLR MUST generate a new Message_Identifier each time the contents 334 of the B-SFRR-Ready Extended ASSOCIATION ID changes; for example, 335 when PLR node changes the bypass tunnel assignment. 337 The PLR node notifies the MP node of the bypass tunnel assignment via 338 adding a B-SFRR-Ready Extended ASSOCIATION object and Association ID 339 in the RSVP Path message for the protected LSP using procedures 340 described in Section 3.4. 342 The MP node acknowledges the PLR node assignment by signaling the B- 343 SFRR-Ready Extended ASSOCIATION object and Association ID within the 344 RSVP Resv message of the protected LSP. With exception of the 345 MESSAGE_ID objects, all other fields of the received in the B-SFRR- 346 Ready Extended ASSOCIATION ID in the RSVP Path message are copied 347 into the B-SFRR-Ready Extended ASSOCIATION ID to be added in the Resv 348 message. The MESSAGE_ID object is set according to [RFC2961] with 349 the Flags being clear. A new Message_Identifier MUST be used to 350 acknowledge an updated PLR assignment. 352 The PLR considers the protected LSP as Summary FRR capable only if 353 all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are 354 sent in the RSVP Path message and the ones received in the RSVP Resv 355 message (with exception of the MESSAGE_ID) match. If it does not 356 match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a 357 subsequent refresh, the PLR node MUST consider the protected LSP as 358 not Summary FRR capable. 360 3.2. B-SFRR-Active Extended ASSOCIATION Object 362 The Extended ASSOCIATION object for B-SFRR-Active association type is 363 populated by a PLR node to indicate to the MP node (bypass tunnel 364 destination) that one or more groups of protected LSPs that are being 365 protected by the specified bypass tunnel are being rerouted over the 366 bypass tunnel. 368 The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP 369 Path message of a bypass LSP and signaled downstream towards the MP 370 (bypass LSP destination). 372 The Association Type, Association ID, and Association Source MUST be 373 set as defined in [RFC4872] for the ASSOCIATION Object. More 374 specifically: 376 Association Source: 378 The Association Source is set to an address of the PLR node. 380 Association Type: 382 A new Association Type is defined for B-SFRR-Active as follows: 384 Value Type 385 ------- ------ 386 (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) 388 Extended ASSOCIATION ID for B-SFRR-Active: 390 The B-SFRR-Active Extended ASSOCIATION ID is 391 populated by the PLR for the Bypass Summary FRR Active association. 392 The rules to populate the Extended ASSOCIATION ID in this case are 393 described below. 395 3.2.1. B-SFRR-Active Extended ASSOCIATION ID 397 The Extended ASSOCIATION ID for the B-SFRR-Active association type 398 has the following format: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Num-BGIDs | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Bypass_Group_Identifier | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | : | 408 // : // 409 | : | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Bypass_Group_Identifier | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | RSVP_HOP_Object | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | TIME_VALUES | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 3: The Extended ASSOCIATION ID for B-SFRR-Active 420 Num-BGIDs: 16 bits 422 Number of Bypass_Group_Identifier fields. 424 Reserved: 16 bits 426 Reserved for future use. 428 Bypass_Group_Identifier: 32 bits 430 The Bypass_Group_Identifier that is previously signaled by the 431 PLR using the Extended Association object. One or 432 more Bypass_Group_Identifiers may be included. 434 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 436 Replacement RSVP HOP object to be applied to all LSPs associated 437 with each of the following Bypass_Group_Identifiers. This corresponds 438 to C-Type = 1 for IPv4 RSVP HOP, or C-Type = 2 for IPv6 RSVP HOP 439 depending on the IP address family carried within the object. 441 TIME_VALUES object: Class 5, as defined by [RFC2205] 442 Replacement TIME_VALUES object to be applied to all LSPs associated 443 with each of the following Bypass_Group_Identifiers after receiving 444 the B-SFRR-Active Extended ASSOCIATION Object. 446 3.3. Signaling Procedures Prior to Failure 448 Before Summary FRR procedures can be used, a handshake MUST be 449 completed between the PLR and MP. This handshake is performed using 450 Extended ASSOCIATION object that carries the B-SFRR-Ready Extended 451 Association ID in both the RSVP Path and Resv messages of the 452 protected LSP. 454 3.3.1. PLR Signaling Procedure 456 The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in 457 the RSVP Path message of the protected LSP to record the bypass 458 tunnel assignment. This object is updated every time the PLR updates 459 the bypass tunnel assignment and that triggers an RSVP Path change 460 message. 462 Upon receiving an RSVP Resv message with B-SFRR-Ready Extended 463 ASSOCIATION object, the PLR node checks if the expected subobjects 464 from the B-SFRR-Ready ASSOCIATION ID are present. If present, the 465 PLR determines if the MP has acknowledged the current PLR assignment. 467 To be a valid acknowledgement, the received B-SFRR-Ready ASSOCIATION 468 ID contents within the RSVP Resv message of the protected LSP MUST 469 match the latest B-SFRR-Ready Extended ASSOCIATION object and 470 Association ID contents that the PLR node had sent within the RSVP 471 Path message (with exception of the MESSAGE_ID). 473 Note, when forwarding an RSVP Resv message upstream, the PLR node 474 SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose 475 Association Source matches the PLR node address. 477 3.3.2. MP Signaling Procedure 479 Upon receiving an RSVP Path message with a B-SFRR-Ready Extended 480 ASSOCIATION object, the MP node processes all (there may be multiple 481 PLRs for a single MP) B-SFRR-Ready Extended ASSOCIATION objects that 482 have the MP node address as Bypass Destination address in the 483 Association ID. 485 The MP node first ensures the existence of the bypass tunnel and that 486 the Bypass_Group_Identifier is not already FRR active. That is, an 487 LSP cannot join a group that is already FRR rerouted. 489 The MP node builds a mirrored Summary FRR Group database per PLR, 490 which is determined using the Bypass_Source_Address field. The 491 MESSAGE_ID is extracted and recorded for the protected LSP PATH 492 state. The MP node signals a B-SFRR-Ready Extended Association 493 object and Association ID in the RSVP Resv message of the protected 494 LSP. With exception of the MESSAGE_ID objects, all other fields of 495 the received B-SFRR-Ready Extended ASSOCIATION object in the RSVP 496 Path message are copied into the B-SFRR-Ready Extended ASSOCIATION 497 object to be added in the Resv message. The MESSAGE_ID object is set 498 according to [RFC2961] with the Flags being clear. 500 Note, an MP may receive more than one RSVP Path message with the B- 501 SFRR-Ready Extended ASSOCIATION object from different upstream PLR 502 node(s). In this case, the MP node is expected to save all the 503 received MESSAGE_IDs from the different upstream PLR node(s). After 504 a failure, the MP node determines and activates the associated 505 Summary Refresh ID to use once it receives and processes the RSVP 506 Path message containing B-SFRR-Active Extended ASSOCIATION object 507 that is signaled over the bypass LSP from the PLR, as described 508 Section 3.4 510 When forwarding an RSVP Path message downstream, the MP SHOULD remove 511 any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association 512 ID contains Bypass_Destination_Address matching the MP node address. 514 3.4. Signaling Procedures Post Failure 516 Upon detection of the fault (egress link or node failure) the PLR 517 first performs the object modification procedures described by 518 Section 6.4.3 of [RFC4090] for all affected protected LSPs. For 519 Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP 520 and SENDER_TEMPLATE MUST be used. 522 The PLR MUST signal non-Summary FRR enabled LSPs over the bypass 523 tunnel before signaling the Summary FRR enabled LSPs. This is needed 524 to allow for the case when the PLR node has recently changed a bypass 525 assignment and the MP has not processed the change yet. 527 The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP 528 Path message of the bypass LSP to reroute RSVP state of Summary FRR 529 enabled LSPs. 531 3.4.1. PLR Signaling Procedure 533 After a failure event, when using the Summary FRR path signaling 534 procedures, an individual RSVP Path message for each Summary FRR LSP 535 is not signaled. Instead, to reroute Summary FRR LSPs via the bypass 536 tunnel, the PLR adds the B-SFRR-Active Extended Association object in 537 the RSVP Path message of the RSVP session of the bypass tunnel. 539 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION 540 ID is set to the common RSVP_HOP that was used by the PLR in 541 Section 3.4 of this document. 543 The previously received MESSAGE_ID from the MP is activated. As a 544 result, the MP may refresh the protected rerouted RESV state using 545 Summary Refresh procedures. 547 For each affected Summary FRR group, its Bypass_Group_Identifier is 548 added to B-SFRR-Active Extended ASSOCIATION ID. 550 3.4.2. MP Signaling Procedure 552 Upon receiving an RSVP Path message with a B-SFRR-Active Extended 553 Association object, the MP performs normal merge point processing for 554 each protected LSP associated with each Bypass_Group_Identifier, as 555 if it received individual RSVP Path messages for the LSP. 557 For each Summary FRR LSP being merged, the MP first modifies the Path 558 state as follows: 560 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended 561 ASSOCIATION ID. 563 2. The TIME_VALUES object is copied from the TIMES_VALUE field in 564 the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES 565 object contains the refresh time of the PLR to generate refreshes 566 and that would have exchanged in a Path message sent to the MP 567 after the failure when no SFRR procedures are in effect. 569 3. The SENDER_TEMPLATE object SrcAddress field is copied from the 570 bypass tunnel SENDER_TEMPLATE object. For the case where PLR is 571 also the head-end, and SENDER_TEMPLATE SrcAddress of the 572 protected LSP and bypass tunnel are the same, the MP MUST use the 573 modified HOP Address field instead. 575 4. The ERO object is modified as per Section 6.4.4. of [RFC4090]. 576 Once the above modifications are completed, the MP then performs 577 the merge processing as per [RFC4090]. 579 5. The previously received MESSAGE_ID from the PLR is activated, 580 meaning that the PLR may now refresh the protected rerouted PATH 581 state using Summary Refresh procedures. 583 A failure during merge processing of any individual rerouted LSP MUST 584 result in an RSVP Path Error message. 586 An individual RSVP Resv message for each successfully merged Summary 587 FRR LSP is not signaled. The MP node SHOULD immediately use Summary 588 Refresh procedures to refresh the protected LSP RESV state. 590 3.5. Refreshing Summary FRR Active LSPs 592 Refreshing of Summary FRR active LSPs is performed using Summary 593 Refresh as defined by [RFC2961]. 595 4. Compatibility 597 The (Extended) ASSOCIATION object is defined in [RFC4872] with a 598 class number in the form 11bbbbbb, which ensures compatibility with 599 non-supporting node(s). Such nodes will ignore the object and 600 forward it without modification. 602 5. Security Considerations 604 This document updates an existing RSVP object. Thus, in the event of 605 the interception of a signaling message, a slightly more information 606 could be deduced about the state of the network than was previously 607 the case. Existing mechanisms for maintaining the integrity and 608 authenticity of RSVP protocol messages [RFC2747] can be applied. 610 6. IANA Considerations 612 IANA maintains the "Generalized Multi-Protocol Label Switching 613 (GMPLS) Signaling Parameters" registry (see 614 http://www.iana.org/assignments/gmpls-sig-parameters [1]). The 615 "Association Type" subregistry is included in this registry. 617 This registry has been updated by new Association Type for Extended 618 ASSOCIATION Object defined in this document as follows: 620 Value Name Reference 621 ----- ---- --------- 622 TBD-1 B-SFRR-Ready Association Section 3.1 623 TBD-2 B-SFRR-Active Association Section 3.2 625 IANA also maintains and assigns the values for the RSVP-TE protocol 626 parameters "Resource Reservation Protocol (RSVP) Parameters" (see 627 http://www.iana.org/assignments/rsvp-parameters). 629 7. Acknowledgments 631 The authors would like to thank Loa Andersson, Lou Berger, Eric 632 Osborne, Gregory Mirsky, and Mach Chen for reviewing and providing 633 valuable comments to this document. 635 8. Contributors 637 Nicholas Tan 638 Arista Networks 640 Email: ntan@arista.com 642 9. References 644 9.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, 648 DOI 10.17487/RFC2119, March 1997, 649 . 651 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 652 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 653 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 654 September 1997, . 656 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 657 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 658 2000, . 660 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 661 and S. Molendini, "RSVP Refresh Overhead Reduction 662 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 663 . 665 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 666 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 667 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 668 . 670 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 671 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 672 DOI 10.17487/RFC4090, May 2005, 673 . 675 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 676 Ed., "RSVP-TE Extensions in Support of End-to-End 677 Generalized Multi-Protocol Label Switching (GMPLS) 678 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 679 . 681 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 682 ASSOCIATION Object Extensions", RFC 6780, 683 DOI 10.17487/RFC6780, October 2012, 684 . 686 9.2. URIs 688 [1] http://www.iana.org/assignments/gmpls-sig-parameters 690 Authors' Addresses 692 Mike Taillon 693 Cisco Systems, Inc. 695 Email: mtaillon@cisco.com 697 Tarek Saad (editor) 698 Cisco Systems, Inc. 700 Email: tsaad@cisco.com 702 Rakesh Gandhi 703 Cisco Systems, Inc. 705 Email: rgandhi@cisco.com 707 Abhishek Deshmukh 708 Juniper Networks 710 Email: adeshmukh@juniper.net 712 Markus Jork 713 Juniper Networks 715 Email: mjork@juniper.net 716 Vishnu Pavan Beeram 717 Juniper Networks 719 Email: vbeeram@juniper.net