idnits 2.17.1 draft-ietf-teas-assoc-corouted-bidir-frr-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 12, 2017) is 2356 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group R. Gandhi, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended Status: Standards Track H. Shah 5 Expires: May 16, 2018 Ciena 6 J. Whittaker 7 Verizon 8 November 12, 2017 10 Fast Reroute Procedures for 11 Co-routed Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-teas-assoc-corouted-bidir-frr-02 14 Abstract 16 Resource Reservation Protocol (RSVP) association signaling can be 17 used to bind two unidirectional LSPs into an associated bidirectional 18 LSP. When an associated bidirectional LSP is co-routed, the reverse 19 LSP follows the same path as its forward LSP. This document 20 describes Fast Reroute (FRR) procedures for both single-sided and 21 double-sided provisioned associated bidirectional LSPs. The FRR 22 procedures can ensure that for the co-routed LSPs, traffic flows on 23 co-routed paths in the forward and reverse directions after a failure 24 event. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4 64 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 5 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5 67 3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6 68 3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7 69 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8 71 4.1.1. Restoring Co-routing with Node Protection Bypass 72 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9 74 4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10 75 4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10 76 4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10 77 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11 78 5. Message and Object Definitions . . . . . . . . . . . . . . . . 11 79 5.1. Extended ASSOCIATION ID . . . . . . . . . . . . . . . . . 11 80 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION 92 Object is specified in [RFC6780] which can be used generically to 93 associate (G)Multiprotocol Label Switching (MPLS) Traffic Engineering 94 (TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for 95 binding two point-to-point unidirectional LSPs [RFC3209] into an 96 associated bidirectional LSP. There are two models described in 97 [RFC7551] for provisioning an associated bidirectional LSP, single- 98 sided and double-sided. In both models, the reverse LSP of the 99 bidirectional LSP may or may not be co-routed and follow the same 100 path as its forward LSP. 102 The Path Computation Element Communication Protocol (PCEP) provides 103 mechanisms for Path Computation Elements (PCEs) to perform path 104 computations in response to Path Computation Clients (PCCs) requests. 105 The Stateful PCE allows stateful control of the MPLS TE LSPs which 106 may be initiated by the PCE or a PCC. As defined in [PCE-ASSOC- 107 BIDIR], a Stateful PCE can be employed to initiate single-sided and 108 double-sided associated bidirectional LSPs on PCC(s). 110 In packet transport networks, there are requirements where the 111 reverse LSP of a bidirectional LSP needs to follow the same path as 112 its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] 113 architecture facilitates the co-routed bidirectional LSP by using the 114 GMPLS extensions [RFC3473] to achieve congruent paths. However, the 115 RSVP association signaling allows to enable co-routed bidirectional 116 LSPs without having to deploy GMPLS extensions in the existing 117 networks. The association signaling also allows to take advantage of 118 the existing TE and Fast Reroute (FRR) mechanisms in the network. 120 [RFC4090] defines FRR extensions for MPLS TE LSPs and those are also 121 applicable to the associated bidirectional LSPs. [RFC8271] defines 122 FRR procedure for GMPLS signaled bidirectional LSPs, such as, 123 coordinate bypass tunnel assignments in the forward and reverse 124 directions of the LSP. The mechanisms defined in [RFC8271] are also 125 useful for the FRR of associated bidirectional LSPs. 127 This document describes FRR procedures for both single-sided and 128 double-sided provisioned associated bidirectional LSPs. The FRR 129 procedures can ensure that for the co-routed LSPs, traffic flows on 130 co-routed paths in the forward and reverse directions after a failure 131 event. 133 1.1. Assumptions and Considerations 135 The following assumptions and considerations apply to this document: 137 o The FRR procedure for the unidirectional LSPs is defined in 138 [RFC4090] and is not modified by this document. 140 o The FRR procedure when using the unidirectional bypass tunnels is 141 defined in [RFC4090] and is not modified by this document. 143 o This document assumes that the FRR bypass tunnels used for 144 protected associated bidirectional LSPs are also associated 145 bidirectional. 147 o The FRR bypass tunnels used for protected co-routed associated 148 bidirectional LSPs are assumed to be co-routed associated 149 bidirectional. 151 o The FRR procedure to coordinate the bypass tunnel assignment 152 defined in this document may be used for protected non-corouted 153 associated bidirectional LSPs but requires that the downstream 154 Point of Local Repair (PLR) and Merge Point (MP) pair of the 155 forward LSP matches the upstream MP and PLR pair of the reverse 156 LSP. 158 o Unless otherwise specified in this document, the fast reroute 159 procedures defined in [RFC4090] are used for associated 160 bidirectional LSPs. 162 2. Conventions Used in This Document 164 2.1. Key Word Definitions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 2.2. Terminology 172 The reader is assumed to be familiar with the terminology defined in 173 [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271]. 175 2.2.1. Forward Unidirectional LSPs 177 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 178 opposite directions between a pair of source and destination nodes to 179 form an associated bidirectional LSP. In the case of single-sided 180 provisioned LSP, the originating LSP with REVERSE_LSP Object is 181 identified as a forward unidirectional LSP. In the case of double- 182 sided provisioned LSP, the LSP originating from the higher node 183 address (as source) and terminating on the lower node address (as 184 destination) is identified as a forward unidirectional LSP. 186 2.2.2. Reverse Co-routed Unidirectional LSPs 188 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 189 opposite directions between a pair of source and destination nodes to 190 form an associated bidirectional LSP. A reverse unidirectional LSP 191 originates on the same node where the forward unidirectional LSP 192 terminates, and it terminates on the same node where the forward 193 unidirectional LSP originates. A reverse co-routed unidirectional 194 LSP traverses along the same path as the forward direction 195 unidirectional LSP in the opposite direction. 197 3. Overview 199 As specified in [RFC7551], in the single-sided provisioning case, the 200 RSVP TE tunnel is configured only on one endpoint node of the 201 bidirectional LSP. An LSP for this tunnel is initiated by the 202 originating endpoint with (Extended) ASSOCIATION Object containing 203 Association Type set to "single-sided associated bidirectional LSP" 204 and REVERSE_LSP Object inserted in the RSVP Path message. The remote 205 endpoint then creates the corresponding reverse TE tunnel and signals 206 the reverse LSP in response using the information from the 207 REVERSE_LSP Object and other objects present in the received RSVP 208 Path message. As specified in [RFC7551], in the double-sided 209 provisioning case, the RSVP TE tunnel is configured on both endpoint 210 nodes of the bidirectional LSP. Both forward and reverse LSPs are 211 initiated independently by the two endpoints with (Extended) 212 ASSOCIATION Object containing Association Type set to "double-sided 213 associated bidirectional LSP". With both single-sided and double- 214 sided provisioned bidirectional LSPs, the reverse LSP may or may not 215 be congruent (i.e. co-routed) and follow the same path as its forward 216 LSP. 218 Both single-sided and double-sided associated bidirectional LSPs 219 require solutions to the following issues for fast reroute to ensure 220 co-routing after a failure event. 222 3.1. Fast Reroute Bypass Tunnel Assignment 224 In order to ensure that the traffic flows on a co-routed path after a 225 link or node failure on the protected co-routed LSP path, the mid- 226 point Point of Local Repair (PLR) nodes need to assign matching 227 bidirectional bypass tunnels for fast reroute. Such bypass 228 assignment requires coordination between the forward and reverse 229 direction PLR nodes when more than one bypass tunnels are present on 230 a PLR node. 232 <-- Bypass N --> 233 +-----+ +-----+ 234 | H +---------+ I | 235 +--+--+ +--+--+ 236 | | 237 | | 238 LSP1 --> | LSP1 --> | LSP1 --> LSP1 --> 239 +-----+ +--+--+ +--+--+ +-----+ +-----+ 240 | A +--------+ B +----X----+ C +--------+ D +--------+ E | 241 +-----+ +--+--+ +--+--+ +-----+ +-----+ 242 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 243 | | 244 | | 245 +--+--+ +--+--+ 246 | F +---------+ G | 247 +-----+ +-----+ 248 <-- Bypass S --> 250 Figure 1: Multiple Bidirectional Bypass Tunnels 252 As shown in Figure 1, there are two bypass tunnels available, Bypass 253 tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C). 254 The mid-point PLR nodes B and C need to coordinate bypass tunnel 255 assignment to ensure that traffic in both directions flow through 256 either on the Bypass tunnel N (on path B-H-I-C) or the Bypass tunnel 257 S (on path B-F-G-C), after the link B-C failure. 259 3.2. Node Protection Bypass Tunnels 261 When using a node protection bypass tunnel with a protected 262 associated bidirectional LSP, after a link failure, the forward and 263 reverse LSP traffic can flow on different node protection bypass 264 tunnels in the upstream and downstream directions. 266 <-- Bypass N --> 267 +-----+ +-----+ 268 | H +------------------------+ I | 269 +--+--+ +--+--+ 270 | <-- Rerouted-LSP2 | 271 | | 272 | | 273 | LSP1 --> LSP1 --> | LSP1 --> LSP1 --> 274 +--+--+ +-----+ +--+--+ +-----+ +-----+ 275 | A +--------+ B +----X----+ C +--------+ D +--------+ E | 276 +-----+ +--+--+ +-----+ +--+--+ +-----+ 277 <-- LSP2 | <-- LSP2 <-- LSP2 | <-- LSP2 278 | | 279 | | 280 | Rerouted-LSP1 --> | 281 +--+--+ +--+--+ 282 | F +------------------------+ G | 283 +-----+ +-----+ 284 <-- Bypass S --> 286 Figure 2: Node Protection Bypass Tunnels 288 As shown in Figure 2, after the link B-C failure, the downstream PLR 289 node B reroutes the protected forward LSP1 traffic over the bypass 290 tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the 291 upstream PLR node C reroute the protected reverse LSP2 traffic over 292 the bypass tunnel N (on path C-I-H-A) to reach the upstream MP node 293 A. As a result, the traffic in the forward and revere directions 294 flows on different bypass tunnels and this can cause the co-routed 295 associated bidirectional LSP to become non-corouted. However, unlike 296 GMPLS LSPs, the asymmetry of paths in the forward and reverse 297 directions does not result in RSVP soft-state timeout with the 298 associated bidirectional LSPs. 300 3.3. Bidirectional LSP Association At Mid-Points 302 In packet transport networks, a restoration LSP is signaled after a 303 link failure on the protected LSP path and the protected LSP may or 304 may not be torn down [RFC8131]. In this case, multiple forward and 305 reverse LSPs of a co-routed associated bidirectional LSP may be 306 present at mid-point nodes with identical (Extended) ASSOCIATION 307 Objects. This creates an ambiguity at mid-point nodes to identify 308 the correct associated LSP pair for fast reroute bypass assignment 309 (e.g. during the recovery phase of RSVP graceful restart procedure). 311 LSP3 --> LSP3 --> LSP3 --> 312 LSP1 --> LSP1 --> LSP1 --> LSP1 --> 313 +-----+ +-----+ +-----+ +-----+ +-----+ 314 | A +--------+ B +----X----+ C +--------+ D +--------+ E | 315 +-----+ +--+--+ +--+--+ +-----+ +-----+ 316 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 317 <-- LSP4 | | <-- LSP4 <-- LSP4 318 | | 319 | LSP3 --> | 320 +--+--+ +--+--+ 321 | F +---------+ G | 322 +-----+ +-----+ 323 <-- Bypass S --> 324 <-- LSP4 326 Figure 3: Restoration LSP Set-up after Link Failure 328 As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an 329 associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are 330 an associated LSP pair, both pairs belong to the same associated 331 bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. 332 In this example, the mid-point node D may mistakenly associate LSP1 333 with the reverse LSP4 instead of the reverse LSP3 due to the matching 334 (Extended) ASSOCIATION Objects. This may cause the co-routed 335 associated bidirectional LSP to become non-corouted after fast 336 reroute. Since the bypass assignment needs to be coordinated between 337 the forward and reverse LSPs, this can also lead to undesired bypass 338 tunnel assignments. 340 4. Signaling Procedure 342 4.1. Associated Bidirectional LSP Fast Reroute 344 For both single-sided and double-sided associated bidirectional LSPs, 345 the fast reroute procedure specified in [RFC4090] is used. In 346 addition, the mechanisms defined in [RFC8271] are used as following. 348 o The BYPASS_ASSIGNMENT IPv4 subobject (value: 38) and IPv6 349 subobject (value: 39) defined in [RFC8271] are used to coordinate 350 bypass tunnel assignment between the forward and reverse direction 351 PLR nodes (see Figure 1). The BYPASS_ASSIGNMENT and Node-ID 352 address [RFC4561] subobjects MUST be added by the downstream PLR 353 node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of 354 the forward LSP to indicate the local bypass tunnel assignment 355 using the procedure defined in [RFC8271]. The upstream node uses 356 the bypass assignment information (namely, bypass tunnel source 357 address, destination address and Tunnel ID) in the received RSVP 358 Path message of the protected forward LSP to find the associated 359 bypass tunnel in the reverse direction. The upstream PLR node 360 MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the 361 RSVP Path message of the reverse LSP. 363 o The downstream PLR node always initiates the bypass tunnel 364 assignment for the forward LSP. The upstream PLR (forward 365 direction LSP MP) node simply reflects the associated bypass 366 tunnel assignment for the reverse direction LSP. The upstream PLR 367 node MUST NOT initiate the bypass tunnel assignment. 369 o If the indicated forward bypass tunnel or the associated reverse 370 bypass tunnel is not found, the upstream PLR SHOULD send a Notify 371 message [RFC3473] with Error-code "FRR Bypass Assignment Error" 372 (value: 44) and Sub-code "Bypass Tunnel Not Found" (value: 1) 374 [RFC8271] to the downstream PLR. 376 o If the bypass tunnel can not be used as described in Section 4.5.3 377 in [RFC8271], the upstream PLR SHOULD send a Notify message 378 [RFC3473] with Error-code "FRR Bypass Assignment Error" (value: 379 44) and Sub-code "Bypass Assignment Cannot Be Used" (value: 0) 380 [RFC8271] to the downstream PLR. 382 o After a link or node failure, the PLR nodes in both forward and 383 reverse directions trigger fast reroute independently using the 384 procedures defined in [RFC4090] and send the forward and protected 385 reverse LSP modified RSVP Path messages and traffic over the 386 bypass tunnel. The RSVP Resv signaling of the protected forward 387 and reverse LSPs follows the same procedure as defined in 388 [RFC4090] and is not modified by this document. 390 4.1.1. Restoring Co-routing with Node Protection Bypass Tunnels 392 After fast reroute, the downstream MP node assumes the role of 393 upstream PLR and reroutes the reverse LSP RSVP Path messages and 394 traffic over the bypass tunnel on which the forward LSP RSVP Path 395 messages and traffic are received. This procedure is defined as 396 restoring co-routing in [RFC8271]. This procedure is used to ensure 397 that both forward and reverse LSP signaling and traffic flow on the 398 same bidirectional bypass tunnel after fast reroute. 400 As shown in Figure 2, when using a node protection bypass tunnel with 401 protected co-routed LSPs, asymmetry of paths can occur in the forward 402 and reverse directions after a link failure [RFC8271]. In order to 403 restore co-routing, the downstream MP node D (acting as an upstream 404 PLR) SHOULD trigger procedure to restore co-routing and reroute the 405 protected reverse LSP2 RSVP Path messages and traffic over the bypass 406 tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving 407 the protected forward LSP modified RSVP Path messages and traffic 408 over the bypass tunnel S (on path D-G-F-B) from node B. The upstream 409 PLR node C stops receiving the RSVP Path messages and traffic for the 410 reverse LSP2 from node D (resulting in RSVP soft-state timeout) and 411 it stops sending the RSVP Path messages for the reverse LSP2 over the 412 bypass tunnel N (on path C-I-H-A) to node A. 414 4.1.2. Unidirectional Link Failures 416 The unidirectional link failures can cause co-routed associated 417 bidirectional LSPs to become non-corouted after fast reroute with 418 both link protection and node protection bypass tunnels. However, 419 the unidirectional link failures in the upstream and/or downstream 420 directions do not result in RSVP soft-state timeout with the 421 associated bidirectional LSPs as upstream and downstream PLRs trigger 422 fast reroute independently. The asymmetry of forward and reverse LSP 423 paths due to the unidirectional link failure in the downstream 424 direction can be corrected by using the procedure to restore co- 425 routing specified in Section 4.1.1. 427 4.1.3. Revertive Behavior after Fast Reroute 429 When the revertive behavior is desired for a protected LSP after the 430 link is restored, the procedure defined in [RFC4090], Section 6.5.2, 431 is followed. 433 o The downstream PLR node starts sending the RSVP Path messages and 434 traffic flow of the protected forward LSP over the restored link 435 and stops sending them over the bypass tunnel [RFC4090]. 437 o The upstream PLR node (when the protected LSP is present) also 438 starts sending the RSVP Path messages and traffic flow of the 439 protected reverse LSPs over the restored link and stops sending 440 them over the bypass tunnel [RFC4090]. 442 o In case of node protection bypass tunnels (see Figure 2), after 443 restoring co-routing, the upstream PLR node D SHOULD start sending 444 RSVP Path messages and traffic for the reverse LSP over the 445 original link (C-D) when it receives the un-modified RSVP Path 446 messages and traffic for the protected forward LSP over it and 447 stops sending them over the bypass tunnel S (on path D-G-F-B). 449 4.1.4. Bypass Tunnel Provisioning 451 Fast reroute bidirectional bypass tunnels can be single-sided or 452 double-sided associated tunnels. For both single-sided and double- 453 sided associated bypass tunnels, the fast reroute assignment policies 454 need to be configured on the downstream PLR nodes of the protected 455 LSPs that initiate the bypass tunnel assignments. For single-sided 456 associated bypass tunnels, these nodes are the originating endpoints 457 of their signaling. 459 4.1.5. One-to-One Bypass Tunnel 461 The fast reroute signaling procedure defined in this document can be 462 used for both facility backup described in Section 3.2 of [RFC4090] 463 and one-to-one backup described in Section 3.1 of [RFC4090]. As 464 described in Section 5.4.2 of [RFC8271], in one-to-one backup method, 465 if the associated bidirectional bypass tunnel is already in-use at 466 the upstream PLR, it SHOULD send a Notify message [RFC3473] with 467 Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code 468 "One-to-One Bypass Already in Use" (value: 2) to the downstream PLR. 470 4.2. Bidirectional LSP Association At Mid-points 472 In order to associate the LSPs unambiguously at a mid-point node (see 473 Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object 474 and add unique Extended Association ID for each associated forward 475 and reverse LSP pair forming the bidirectional LSP. As an example, 476 an endpoint node MAY set the Extended Association ID to the value 477 specified in Section 5.1. 479 o For single-sided provisioned bidirectional LSPs [RFC7551], the 480 originating endpoint signals the Extended ASSOCIATION Object with 481 a unique Extended Association ID. The remote endpoint copies the 482 contents of the received Extended ASSOCIATION Object including the 483 Extended Association ID in the RSVP Path message of the reverse 484 LSP's Extended ASSOCIATION Object. 486 o For double-sided provisioned bidirectional LSPs [RFC7551], both 487 endpoints need to ensure that the bidirectional LSP has a unique 488 Extended ASSOCIATION Object for each forward and reverse LSP pair 489 by selecting appropriate unique Extended Association IDs signaled 490 by them. 492 5. Message and Object Definitions 494 5.1. Extended ASSOCIATION ID 496 The Extended Association ID in the Extended ASSOCIATION Object 497 [RFC6780] can be set to the value specified as following to uniquely 498 identify associated forward and reverse LSP pair of an associated 499 bidirectional LSP. 501 IPv4 Extended Association ID format is shown below: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | IPv4 LSP Source Address | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Reserved | LSP-ID | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 : : 511 : Variable Length ID : 512 : : 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 4: IPv4 Extended Association ID Format 517 LSP Source Address 519 IPv4 source address of the forward LSP [RFC3209]. 521 LSP-ID 523 16-bits LSP-ID of the forward LSP [RFC3209]. 525 Variable Length ID 527 Variable length ID inserted by the endpoint node of the associated 528 bidirectional LSP [RFC6780]. 530 IPv6 Extended Association ID format is shown below: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 + + 537 | IPv6 LSP Source Address | 538 + + 539 | (16 bytes) | 540 + + 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Reserved | LSP-ID | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 : : 546 : Variable Length ID : 547 : : 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 5: IPv6 Extended Association ID Format 552 LSP Source Address 554 IPv6 source address of the forward LSP [RFC3209]. 556 LSP-ID 558 16-bits LSP-ID of the forward LSP [RFC3209]. 560 Variable Length ID 562 Variable length ID inserted by the endpoint node of the associated 563 bidirectional LSP [RFC6780]. 565 6. Compatibility 567 This document describes the procedures for fast reroute for 568 associated bidirectional LSPs. Operators wishing to use this 569 function SHOULD ensure that it is supported on the nodes on the LSP 570 path. No new signaling messages are defines in this document. 572 7. Security Considerations 574 This document uses the signaling mechanisms defined in [RFC7551] and 575 [RFC8271] and does not introduce any additional security 576 considerations other than those already covered in [RFC7551], 577 [RFC8271], and the MPLS/GMPLS security framework [RFC5920]. 579 8. IANA Considerations 581 This document does not require any IANA actions. 583 9. References 585 9.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 591 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 592 Functional Specification", RFC 2205, September 1997. 594 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 595 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 596 May 2005. 598 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 599 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 600 4561, June 2006. 602 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 603 Association Object Extensions", RFC 6780, October 2012. 605 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 606 Extensions for Associated Bidirectional Label Switched 607 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 608 . 610 [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and 611 M. Bhatia, "Updates to Resource Reservation Protocol for 612 Fast Reroute of Traffic Engineering GMPLS Label Switched 613 Paths (LSPs)", RFC 8271, October 2017. 615 9.2. Informative References 617 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 618 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 619 Tunnels", RFC 3209, December 2001. 621 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 622 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 623 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 625 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 626 Networks", RFC 5920, July 2010. 628 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 629 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 631 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 632 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 633 Framework", RFC 6373, September 2011. 635 [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and 636 P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End 637 GMPLS Restoration and Resource Sharing", RFC 8131, March 638 2017. 640 [PCE-ASSOC-BIDIR] Barth, C., Gandhi, R., and B. Wen, "PCEP 641 Extensions for Associated Bidirectional Label Switched 642 Paths (LSPs)", draft-barth-pce-association-bidir (work in 643 progress). 645 Acknowledgments 647 A special thanks to the authors of [RFC8271], this document uses the 648 signaling mechanisms defined in that document. 650 Authors' Addresses 652 Rakesh Gandhi (editor) 653 Cisco Systems, Inc. 654 Canada 656 Email: rgandhi@cisco.com 658 Himanshu Shah 659 Ciena 661 Email: hshah@ciena.com 663 Jeremy Whittaker 664 Verizon 666 Email: jeremy.whittaker@verizon.com