idnits 2.17.1 draft-ietf-mpls-summary-frr-rsvpte-08.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 (Using the creation date from RFC4090, updated by this document, for RFC5378 checks: 2002-02-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2020) is 1566 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) No issues found here. 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 Updates: 4090 (if approved) T. Saad, Ed. 5 Intended status: Standards Track Juniper Networks 6 Expires: July 15, 2020 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 January 12, 2020 16 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 17 draft-ietf-mpls-summary-frr-rsvpte-08 19 Abstract 21 This document updates RFC 4090 for the Resource Reservation Protocol 22 (RSVP) Traffic-Engineering (TE) procedures defined for facility 23 backup protection. The updates include extensions that reduce the 24 amount of signaling and processing that occurs during Fast Reroute 25 (FRR), and subsequently, improves scalability when undergoing FRR 26 convergence after a link or node failure. These extensions allow the 27 RSVP message exchange between the Point of Local Repair (PLR) and the 28 Merge Point (MP) to be independent of the number of protected Label 29 Switched Paths (LSPs) traversing between them when facility bypass 30 FRR protection is used. The signaling extensions are fully backwards 31 compatible with nodes that do not support them. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 15, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 69 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 71 3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 5 72 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 6 73 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 7 74 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 8 75 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 11 76 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID . . . . . 12 77 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID . . . . . 13 78 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 14 79 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 15 80 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 15 81 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 16 82 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 16 83 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 17 84 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 18 85 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 92 9.2. Informative References . . . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 Merge Point (MP) due to limited memory and CPU 104 processing resources. This condition is exacerbated when the failure 105 affects a large number of protected LSPs that traverse the same PLR 106 and 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 an MP node for a 111 similar number of LSPs that ingress on the same link. In the event 112 of the failure of the link or neighbor node, the RSVP-TE control 113 plane of the node when acting as a PLR becomes busy rerouting 114 protected LSPs signaling over the bypass tunnel(s) in one direction, 115 and when acting as an MP node becomes busy merging RSVP states from 116 signaling received over bypass tunnels for LSP(s) in the reverse 117 direction. Subsequently, the head-end LER(s) that are notified of 118 the local repair at downstream LSR will attempt to (re)converge the 119 affected RSVP-TE LSPs onto newly computed paths - possibly traversing 120 the same previously affected LSR(s). As a result, the RSVP-TE 121 control plane at the PLR and MP becomes overwhelmed by the amount of 122 FRR RSVP-TE processing overhead following the link or node failure, 123 and due to other control plane protocol(s) (e.g. the IGP) that 124 undergo convergence on the same node at the same time too. 126 Today, each protected RSVP-TE LSP is signaled individually over the 127 bypass tunnel after FRR. The changes introduced in this document 128 allow the PLR to assign multiple protected LSPs to a bypass tunnel 129 group and to communicate this assignment to the MP, such that upon 130 failure, the signaling over the bypass tunnel happens on bypass 131 tunnel group(s). New extensions are defined in this document to 132 update the procedures defined in [RFC4090] for facility backup 133 protection to enable the MP node to become aware of the PLR node's 134 bypass tunnel assignment group(s) and to allow FRR procedures between 135 the PLR and the MP nodes to be signaled and processed on per bypass 136 tunnel group(s). 138 As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to 139 refresh the RSVP Path and Resv states to help with scaling. The 140 Summary FRR procedures introduced in this document build on those 141 concepts to allow the MESSAGE_ID(s) to be exchanged on per bypass 142 tunnel assignment group, and continue use Summary Refresh procedures 143 while reducing the amount of messaging that occurs after rerouting 144 signaling over the bypass tunnel post FRR. 146 2. Conventions Used in This Document 148 2.1. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2.2. Acronyms and Abbreviations 158 The reader is assumed to be familiar with terms and abbreviations 159 used in [RFC3209] and [RFC4090]. 161 The following abbreviations are also used in this document: 163 LSR: Label Switching Router 165 LER: Label Edge Router 167 MPLS: Multiprotocol Label Switching 169 LSP: Label Switched Path 171 MP: Merge Point node as defined in [RFC4090] 173 PLR: Point of Local Repair node as defined in [RFC4090] 175 FRR: Fast Reroute as defined in [RFC4090] 177 B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION 178 object. Added by the PLR for each LSP protected by the bypass 179 tunnel. 181 B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION 182 object. Used to notify the MP node that one or more groups of 183 protected LSP(s) have been rerouted over the associated bypass 184 tunnel. 186 MTU: Maximum transmission unit. 188 3. Extensions for Summary FRR Signaling 190 The RSVP ASSOCIATION object is defined in [RFC4872] as a means to 191 associate LSPs with each other. For example, in the context of 192 GMPLS-controlled LSP(s), the object is used to associate recovery 193 LSPs with the LSP they are protecting. The Extended ASSOCIATION 194 object is introduced in [RFC6780] to expand on the possible usage of 195 the ASSOCIATION object and generalize the definition of the Extended 196 Association ID field. 198 This document defines the use of the Extended ASSOCIATION object to 199 carry the Summary FRR information and associate the protected LSP(s) 200 with the bypass tunnel that protects them. Two new Association Types 201 for the Extended ASSOCIATION object, and new Extended Association IDs 202 are proposed in this document to describe the Bypass Summary FRR 203 Ready (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR- 204 Active) associations. 206 The PLR creates and manages the Summary FRR LSP groups (identified by 207 Bypass_Group_Identifiers) and shares the group identifier(s) with the 208 MP via signaling. 210 The PLR SHOULD assign the same Bypass_Group_Identifier to all 211 protected LSPs that egress the same protected interface and are 212 protected by the same bypass tunnel. This minimizes the number of 213 bypass tunnel SFRR groups, and optimizes the amount of signaling 214 needed between the PLR and the MP after FRR. 216 The PLR MUST ensure all protected LSP(s) that are assigned the same 217 Bypass_Group_Identifier use the same modified tunnel sender address 218 for the backup path identification after FRR as described in 219 [RFC4090]. 221 The PLR SHOULD assign the same Bypass_Group_Identifier to all 222 protected LSPs that share the egress link, and bypass tunnel as long 223 as the protected LSP(s) have the common group attributes, including 224 the modified tunnel sender address used for backup path 225 identification as described in [RFC4090]. 227 The MP maintains the PLR group assignments learned via signaling, and 228 acknowledges the group assignments via signaling. Once the PLR 229 receives the acknowledgment, FRR signaling can proceed as group 230 based. 232 The PLR node that supports Summary FRR procedures adds an Extended 233 ASSOCIATION object with B-SFRR-Ready Extended Association ID in the 234 RSVP Path message of the protected LSP. The PLR adds the protected 235 LSP Bypass_Group_Identifier, information from the assigned bypass 236 tunnel, and MESSAGE_ID object into the B-SFRR-Ready Extended 237 Association ID. The MP uses the information contained in the 238 received B-SFRR-Ready Extended Association ID to refresh and merge 239 the protected LSP Path state after FRR occurs. 241 The MP node that supports Summary FRR procedures adds the B-SFRR- 242 Ready Extended ASSOCIATION object and respective Extended Association 243 ID in the RSVP Resv message of the protected LSP to acknowledge the 244 PLR's bypass tunnel assignment, and provide the MESSAGE_ID object 245 that the MP node will use to refresh the protected LSP Resv state 246 after FRR occurs. 248 This document also defines a new Association Type for the Extended 249 ASSOCIATION object and new Extended Association ID to describe the B- 250 SFRR-Active association. The B-SFRR-Active Extended ASSOCIATION 251 object and Extended Association ID are sent by the PLR after 252 activating FRR procedures on the PLR. The B-SFRR-Active Extended 253 ASSOCIATION object and Extended Association ID are sent within the 254 RSVP Path message of the bypass tunnel to inform the MP node that one 255 or more groups of protected LSPs protected by the bypass tunnel are 256 now being rerouted over the bypass tunnel. 258 3.1. B-SFRR-Ready Extended ASSOCIATION Object 260 The Extended ASSOCIATION object is populated using the rules defined 261 below to associate a protected LSP with the bypass tunnel that is 262 protecting it when Summary FRR procedures are enabled. 264 The Association Type, Association ID, and Association Source MUST be 265 set as defined in [RFC4872] for the ASSOCIATION Object. More 266 specifically: 268 Association Source: 270 The Association Source is set to an address of the PLR node. 272 Association Type: 274 A new Association Type is defined for B-SFRR-Ready as follows: 276 Value Type 277 ------- ------ 278 (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) 280 Extended ASSOCIATION ID for B-SFRR-Ready: 282 The B-SFRR-Ready Extended ASSOCIATION ID is 283 populated by the PLR for the Bypass Summary FRR Ready association. 284 The rules to populate the Extended ASSOCIATION ID in this case are 285 described below. 287 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID 289 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association 290 type has the following format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Bypass_Tunnel_ID | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Bypass_Source_IPv4_Address | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Bypass_Destination_IPv4_Address | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Bypass_Group_Identifier | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | MESSAGE_ID | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready 308 Bypass_Tunnel_ID: 16 bits 310 The bypass tunnel identifier. 312 Reserved: 16 bits 314 Reserved for future use. 316 Bypass_Source_IPv4_Address: 32 bits 318 The bypass tunnel source IPV4 address. 320 Bypass_Destination_IPv4_Address: 32 bits 322 The bypass tunnel destination IPV4 address. 324 Bypass_Group_Identifier: 32 bits 326 The bypass tunnel group identifier. 328 MESSAGE_ID 330 A MESSAGE_ID object as defined by [RFC2961]. 332 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID 334 The IPv6 Extended ASSOCIATION ID field for the B-SFRR-Ready 335 association type has the following format: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Bypass_Tunnel_ID | Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 + + 344 | | 345 + Bypass_Source_IPv6_Address + 346 | | 347 + + 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 + + 352 | | 353 + Bypass_Destination_IPv6_Address + 354 | | 355 + + 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Bypass_Group_Identifier | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | MESSAGE_ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready 365 Bypass_Tunnel_ID: 16 bits 367 The bypass tunnel identifier. 369 Reserved: 16 bits 371 Reserved for future use. 373 Bypass_Source_IPv6_Address: 128 bits 375 The bypass tunnel source IPV6 address. 377 Bypass_Destination_IPv6_Address: 128 bits 379 The bypass tunnel destination IPV6 address. 381 Bypass_Group_Identifier: 32 bits 383 The bypass tunnel group identifier. 385 MESSAGE_ID 387 A MESSAGE_ID object as defined by [RFC2961]. 389 The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each 390 protected LSP. The same Bypass_Group_Identifier is used for the set 391 of protected LSPs that share the same bypass tunnel, traverse the 392 same egress link and are not already rerouted. The PLR MUST generate 393 a MESSAGE_ID object with Epoch and Message_Identifier set according 394 to [RFC2961]. The MESSAGE_ID object flags SHOULD be cleared when 395 transmitted by the PLR and ignored when received at the MP. 397 The PLR MUST generate a new Message_Identifier each time the contents 398 of the B-SFRR-Ready Extended ASSOCIATION ID changes (e.g. when PLR 399 node changes the bypass tunnel assignment). 401 The PLR node notifies the MP node of the bypass tunnel assignment via 402 adding a B-SFRR-Ready Extended ASSOCIATION object and Extended 403 Association ID in the RSVP Path message for the protected LSP using 404 procedures described in Section 3.3. 406 The MP node acknowledges the assignment to the PLR node by signaling 407 the B-SFRR-Ready Extended ASSOCIATION object and Extended Association 408 ID within the RSVP Resv message of the protected LSP. With the 409 exception of the MESSAGE_ID objects, all other fields of the received 410 in the B-SFRR-Ready Extended ASSOCIATION ID in the RSVP Path message 411 are copied into the B-SFRR-Ready Extended ASSOCIATION ID to be added 412 in the Resv message. The MESSAGE_ID object is set according to 414 [RFC2961] with the Flags being clear. A new Message_Identifier MUST 415 be used to acknowledge an updated PLR assignment. 417 The PLR considers the protected LSP as Summary FRR capable only if 418 all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are 419 sent in the RSVP Path message match the fields received in the RSVP 420 Resv message (with exception of the MESSAGE_ID). If the fields do 421 not match, or if B-SFRR-Ready Extended ASSOCIATION object is absent 422 in a subsequent refresh, the PLR node MUST consider the protected LSP 423 as not Summary FRR capable. 425 3.2. B-SFRR-Active Extended ASSOCIATION Object 427 The Extended ASSOCIATION object for B-SFRR-Active association type is 428 populated by a PLR node to indicate to the MP node (bypass tunnel 429 destination) that one or more groups of Summary FRR protected LSPs 430 that are being protected by the bypass tunnel are being rerouted over 431 the bypass tunnel. 433 The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP 434 Path message of the bypass tunnel and signaled downstream towards the 435 MP (bypass tunnel destination). 437 The Association Type, Association ID, and Association Source MUST be 438 set as defined in [RFC4872] for the ASSOCIATION Object. More 439 specifically: 441 Association Source: 443 The Association Source is set to an address of the PLR node. 445 Association Type: 447 A new Association Type is defined for B-SFRR-Active as follows: 449 Value Type 450 ------- ------ 451 (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) 453 Extended ASSOCIATION ID for B-SFRR-Active: 455 The B-SFRR-Active Extended ASSOCIATION ID is 456 populated by the PLR for the Bypass Summary FRR Active association. 457 The rules to populate the Extended ASSOCIATION ID in this case are 458 described below. 460 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID 462 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Active association 463 type is carried inside the IPv4 Extended ASSOCIATION object and has 464 the following format: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Num-BGIDs | Reserved | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Bypass_Group_Identifier | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | : | 474 // : // 475 | : | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Bypass_Group_Identifier | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 // RSVP_HOP_Object // 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 // TIME_VALUES // 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | IPv4 tunnel sender address | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 3: The IPv4 Extended ASSOCIATION ID for B-SFRR-Active 488 Num-BGIDs: 16 bits 490 Number of Bypass_Group_Identifier fields. 492 Reserved: 16 bits 494 Reserved for future use. 496 Bypass_Group_Identifier: 32 bits 498 The Bypass_Group_Identifier that is previously signaled by the PLR 499 using the Extended Association object. One or more 500 Bypass_Group_Identifiers MAY be included. 502 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 504 Replacement RSVP HOP object to be applied to all LSPs associated 505 with each of the following Bypass_Group_Identifiers. This 506 corresponds to C-Type = 1 for IPv4 RSVP HOP. 508 TIME_VALUES object: Class 5, as defined by [RFC2205] 510 Replacement TIME_VALUES object to be applied to all LSPs 511 associated with each of the following Bypass_Group_Identifiers 512 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 514 IPv4 tunnel sender address: 516 The IPv4 address that the PLR sets to identify backup path(s) as 517 described in Section 6.1.1 of [RFC4090]. This address is 518 applicable to all groups identified by Bypass_Group_Identifier(s) 519 carried in the B-SFRR-Active Extended ASSOCIATION ID. 521 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID 523 The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association 524 type is carried inside the IPv6 Extended ASSOCIATION object and has 525 the following format: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Num-BGIDs | Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Bypass_Group_Identifier | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | : | 535 // : // 536 | : | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Bypass_Group_Identifier | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 // RSVP_HOP_Object // 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 // TIME_VALUES // 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 + + 546 | | 547 + IPv6 tunnel sender address + 548 | | 549 + + 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Figure 4: The IPv6 Extended ASSOCIATION ID for B-SFRR-Active 555 Num-BGIDs: 16 bits 557 Number of Bypass_Group_Identifier fields. 559 Reserved: 16 bits 561 Reserved for future use. 563 Bypass_Group_Identifier: 32 bits 565 The Bypass_Group_Identifier that is previously signaled by the PLR 566 using the Extended Association object. One or more 567 Bypass_Group_Identifiers may be included. 569 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 571 Replacement RSVP HOP object to be applied to all LSPs associated 572 with each of the following Bypass_Group_Identifiers. This 573 corresponds to C-Type = 2 for IPv6 RSVP HOP. 575 TIME_VALUES object: Class 5, as defined by [RFC2205] 577 Replacement TIME_VALUES object to be applied to all LSPs 578 associated with each of the following Bypass_Group_Identifiers 579 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 581 IPv6 tunnel sender address: 583 The IPv6 address that the PLR sets to identify backup path(s) as 584 described in Section 6.1.1 of [RFC4090]. This address is 585 applicable to all groups identified by Bypass_Group_Identifier(s) 586 carried in the B-SFRR-Active Extended ASSOCIATION ID. 588 3.3. Signaling Procedures Prior to Failure 590 Before Summary FRR procedures can be used, a handshake MUST be 591 completed between the PLR and MP. This handshake is performed using 592 the Extended ASSOCIATION object that carries the B-SFRR-Ready 593 Extended Association ID in both the RSVP Path and Resv messages of 594 the protected LSP. 596 The facility backup method introduced in [RFC4090] takes advantage of 597 MPLS label stacking (PLR imposing additional MPLS label post FRR) to 598 allow rerouting of protected traffic over backup path. The backup 599 path may have stricter MTU requirement and due to label stacking at 600 PLR, the protected traffic may exceed the backup path MTU. The 601 operator is assumed to engineer their network to allow rerouting of 602 protected traffic and the additional label stacking at PLR to not 603 exceed the backup path MTU. 605 When using procedures defined in this document, the PLR MUST ensure 606 the bypass tunnel assignment can satisfy the protected LSP MTU 607 requirements post FRR. This avoids any packets from being dropped 608 due to exceeding the MTU size of the backup path after traffic is 609 rerouted on to the bypass tunnel post the failure. 611 3.3.1. PLR Signaling Procedure 613 The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in 614 the RSVP Path message of the protected LSP to record the bypass 615 tunnel assignment. This object is updated every time the PLR updates 616 the bypass tunnel assignment and that triggers an RSVP Path change 617 message. 619 Upon receiving an RSVP Resv message with B-SFRR-Ready Extended 620 ASSOCIATION object, the PLR node checks if the expected sub-objects 621 from the B-SFRR-Ready Extended ASSOCIATION ID are present. If 622 present, the PLR determines if the MP has acknowledged the current 623 PLR assignment. 625 To be a valid acknowledgement, the received B-SFRR-Ready Extended 626 ASSOCIATION ID contents within the RSVP Resv message of the protected 627 LSP MUST match the latest B-SFRR-Ready Extended ASSOCIATION object 628 and Association ID contents that the PLR node had sent within the 629 RSVP Path message (with exception of the MESSAGE_ID). 631 Note, when forwarding an RSVP Resv message upstream, the PLR node 632 SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose 633 Association Source matches the PLR node address. 635 3.3.2. MP Signaling Procedure 637 Upon receiving an RSVP Path message with a B-SFRR-Ready Extended 638 ASSOCIATION object, the MP node processes all (there may be multiple 639 PLRs for a single MP) B-SFRR-Ready Extended ASSOCIATION objects that 640 have the MP node address as Bypass Destination address in the 641 Extended Association ID. 643 The MP node first ensures the existence of the bypass tunnel and that 644 the Bypass_Group_Identifier is not already FRR active. That is, an 645 LSP cannot join a group that is already FRR rerouted. 647 The MP node builds a mirrored Summary FRR Group database per PLR, 648 which is determined using the Bypass_Source_Address field. The 649 MESSAGE_ID is extracted and recorded for the protected LSP Path 650 state. The MP node signals a B-SFRR-Ready Extended Association 651 object and Extended Association ID in the RSVP Resv message of the 652 protected LSP. With the exception of the MESSAGE_ID objects, all 653 other fields of the received B-SFRR-Ready Extended ASSOCIATION object 654 in the RSVP Path message are copied into the B-SFRR-Ready Extended 655 ASSOCIATION object to be added in the Resv message. The MESSAGE_ID 656 object is set according to [RFC2961] with the Flags being clear. 658 Note, an MP may receive more than one RSVP Path message with the B- 659 SFRR-Ready Extended ASSOCIATION object from different upstream PLR 660 node(s). In this case, the MP node is expected to save all the 661 received MESSAGE_IDs from the different upstream PLR node(s). After 662 a failure, the MP node determines and activates the associated 663 Summary Refresh ID to use once it receives and processes the RSVP 664 Path message containing B-SFRR-Active Extended ASSOCIATION object 665 that is signaled over the bypass tunnel from the PLR, as described 666 Section 3.4 668 When forwarding an RSVP Path message downstream, the MP SHOULD remove 669 any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association 670 ID contains Bypass_Destination_Address matching the MP node address. 672 3.4. Signaling Procedures Post Failure 674 Upon detection of the fault (egress link or node failure) the PLR 675 first performs the object modification procedures described by 676 Section 6.4.3 of [RFC4090] for all affected protected LSPs. For the 677 Summary FRR capable LSPs that are assigned to the same bypass tunnel 678 a common RSVP_HOP and SENDER_TEMPLATE MUST be used. 680 The PLR MUST signal non-Summary FRR capable LSPs over the bypass 681 tunnel before signaling the Summary FRR capable LSPs. This is needed 682 to allow for the case where the PLR node recently changed a bypass 683 assignment and the MP has not processed the change yet. 685 The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP 686 Path message of the bypass tunnel to reroute RSVP state of Summary 687 FRR capable LSPs. 689 3.4.1. PLR Signaling Procedure 691 After a failure event, when using the Summary FRR path signaling 692 procedures, an individual RSVP Path message is not signaled for each 693 Summary FRR LSP. Instead, to reroute Summary FRR LSPs via the bypass 694 tunnel, the PLR adds the B-SFRR-Active Extended Association object in 695 the RSVP Path message of the RSVP session of the bypass tunnel. 697 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION 698 ID is set to the common RSVP_HOP that was used by the PLR in 699 Section 3.3 of this document. 701 The previously received MESSAGE_ID from the MP is activated. As a 702 result, the MP may refresh the protected rerouted Resv state using 703 Summary Refresh procedures. 705 The PLR adds the Bypass_Group_Identifier(s) of group(s) that have 706 common group attributes, including the tunnel sender address, to the 707 same B-SFRR-Active Extended ASSOCIATION ID. Note that multiple 708 ASSOCIATION objects, each carrying a B-SFRR-Active Extended 709 ASSOCIATION ID, can be carried within a single RSVP Path message of 710 the bypass tunnel and sent towards the MP as described in [RFC6780]. 712 3.4.2. MP Signaling Procedure 714 Upon receiving an RSVP Path message with a B-SFRR-Active Extended 715 Association object, the MP performs normal merge point processing for 716 each protected LSP associated with each Bypass_Group_Identifier, as 717 if it received an individual RSVP Path messages for that LSP. 719 For each Summary FRR capable LSP that is being merged, the MP first 720 modifies the Path state as follows: 722 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended 723 ASSOCIATION ID. 725 2. The TIME_VALUES object is copied from the TIMES_VALUE field in 726 the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES 727 object contains the refresh time of the PLR to generate refreshes 728 and that would have exchanged in a Path message sent to the MP 729 after the failure when no Summary FRR procedures are in effect. 731 3. The tunnel sender address field in the SENDER_TEMPLATE object is 732 copied from the tunnel sender address of the B-SFRR-Active 733 Extended ASSOCIATION ID. 735 4. The ERO object is modified as per Section 6.4.4 of [RFC4090]. 736 Once the above modifications are completed, the MP node performs 737 the merge processing as per [RFC4090]. 739 5. The previously received MESSAGE_ID from the PLR is activated, 740 meaning that the PLR may now refresh the protected rerouted Path 741 state using Summary Refresh procedures. 743 A failure during merge processing of any individual rerouted LSP MUST 744 result in an RSVP Path Error message. 746 An individual RSVP Resv message for each successfully merged Summary 747 FRR LSP is not signaled. The MP node SHOULD immediately use Summary 748 Refresh procedures to refresh the protected LSP Resv state. 750 3.5. Refreshing Summary FRR Active LSPs 752 Refreshing of Summary FRR active LSPs is performed using Summary 753 Refresh as defined by [RFC2961]. 755 4. Backwards Compatibility 757 The (Extended) ASSOCIATION object is defined in [RFC4872] with a 758 class number in the form 11bbbbbb, which ensures compatibility with 759 non-supporting node(s). Such nodes will ignore the object and 760 forward it without modification. 762 5. Security Considerations 764 This document updates an existing RSVP object. Thus, in the event of 765 the interception of a signaling message, slightly more information 766 could be deduced about the state of the network than was previously 767 the case. 769 When using procedures defined in this document, FRR (or the reroute 770 of protected LSP(s) on to the bypass tunnel) can be activated on per 771 group of protected LSP(s). This allows an intruder to potentially 772 impact and manipulate a set of protected LSP that are assigned to the 773 same bypass tunnel group. 775 Existing mechanisms for maintaining the integrity and authenticity of 776 RSVP protocol messages [RFC2747] can be applied. Other 777 considerations mentioned in [RFC4090] and [RFC5920] also apply. 779 6. IANA Considerations 781 IANA maintains the "Generalized Multi-Protocol Label Switching 782 (GMPLS) Signaling Parameters" registry. The "Association Type" sub- 783 registry is included in this registry. 785 This registry has been updated by new Association Type for Extended 786 ASSOCIATION Object defined in this document as follows: 788 Value Name Reference 789 ----- ---- --------- 790 TBD-1 B-SFRR-Ready Association Section 3.1 791 TBD-2 B-SFRR-Active Association Section 3.2 793 7. Acknowledgments 795 The authors would like to thank Alexander Okonnikov, Loa Andersson, 796 Lou Berger, Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and 797 providing valuable comments to this document. 799 8. Contributors 801 Nicholas Tan 802 Arista Networks 804 Email: ntan@arista.com 806 9. References 808 9.1. Normative References 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, 812 DOI 10.17487/RFC2119, March 1997, 813 . 815 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 816 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 817 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 818 September 1997, . 820 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 821 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 822 2000, . 824 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 825 and S. Molendini, "RSVP Refresh Overhead Reduction 826 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 827 . 829 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 830 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 831 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 832 . 834 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 835 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 836 DOI 10.17487/RFC4090, May 2005, 837 . 839 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 840 Ed., "RSVP-TE Extensions in Support of End-to-End 841 Generalized Multi-Protocol Label Switching (GMPLS) 842 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 843 . 845 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 846 ASSOCIATION Object Extensions", RFC 6780, 847 DOI 10.17487/RFC6780, October 2012, 848 . 850 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 851 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 852 May 2017, . 854 9.2. Informative References 856 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 857 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 858 . 860 Authors' Addresses 862 Mike Taillon 863 Cisco Systems, Inc. 865 Email: mtaillon@cisco.com 867 Tarek Saad (editor) 868 Juniper Networks 870 Email: tsaad@juniper.net 872 Rakesh Gandhi 873 Cisco Systems, Inc. 875 Email: rgandhi@cisco.com 877 Abhishek Deshmukh 878 Juniper Networks 880 Email: adeshmukh@juniper.net 881 Markus Jork 882 128 Technology 884 Email: mjork@128technology.com 886 Vishnu Pavan Beeram 887 Juniper Networks 889 Email: vbeeram@juniper.net