idnits 2.17.1 draft-ietf-teas-assoc-corouted-bidir-frr-05.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4090, but the abstract doesn't seem to directly say this. It does mention RFC4090 though, so this could be OK. -- The draft header indicates that this document updates RFC7551, but the abstract doesn't seem to directly say this. It does mention RFC7551 though, so this could be OK. 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 (August 8, 2018) is 2088 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 (==), 4 comments (--). 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 Updates: 4090, 7551 H. Shah 5 Intended Status: Standards Track Ciena 6 Expires: February 9, 2019 J. Whittaker 7 Verizon 8 August 8, 2018 10 Updates to the Fast Reroute Procedures for 11 Co-routed Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-teas-assoc-corouted-bidir-frr-05 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 updates 20 the Fast Reroute (FRR) procedures defined in RFC 4090 to support both 21 single-sided and double-sided provisioned associated bidirectional 22 LSPs. This document also updates the procedure for associating two 23 reverse LSPs defined in RFC 7551 to support co-routed bidirectional 24 LSPs. The FRR procedures can ensure that for the co-routed LSPs, 25 traffic flows on co-routed paths in the forward and reverse 26 directions after a failure event. 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 http://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 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 62 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4 65 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 66 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5 68 3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6 69 3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7 70 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8 72 4.1.1. Restoring Co-routing with Node Protection Bypass 73 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9 75 4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10 76 4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10 77 4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10 78 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 10 79 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 Appendix A. Extended ASSOCIATION ID . . . . . . . . . . . . . . . 11 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 8.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 Multiprotocol Label Switching (MPLS) and Generalized MPLS 94 (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). 95 [RFC7551] defines mechanisms for binding two point-to-point 96 unidirectional LSPs [RFC3209] into an associated bidirectional LSP. 97 There are two models described in [RFC7551] for provisioning an 98 associated bidirectional LSP, single-sided and double-sided. In both 99 models, the reverse LSP of the bidirectional LSP may or may not be 100 co-routed and follow the same path as its forward LSP. 102 In packet transport networks, there are requirements where the 103 reverse LSP of a bidirectional LSP needs to follow the same path as 104 its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] 105 architecture facilitates the co-routed bidirectional LSP by using the 106 GMPLS extensions [RFC3473] to achieve congruent paths. However, the 107 RSVP association signaling allows to enable co-routed bidirectional 108 LSPs without having to deploy GMPLS extensions in the existing 109 networks. The association signaling also allows to take advantage of 110 the existing TE and Fast Reroute (FRR) mechanisms in the network. 112 [RFC4090] defines FRR extensions for MPLS TE LSPs and those are also 113 applicable to the associated bidirectional LSPs. [RFC8271] defines 114 FRR procedure for GMPLS signaled bidirectional LSPs, such as, 115 coordinate bypass tunnel assignments in the forward and reverse 116 directions of the LSP. The mechanisms defined in [RFC8271] are also 117 useful for the FRR of associated bidirectional LSPs. 119 This document updates the FRR procedures defined in [RFC4090] to 120 support both single-sided and double-sided provisioned associated 121 bidirectional LSPs. This document also updates the procedure for 122 associating two reverse LSPs defined in [RFC7551] to support 123 co-routed bidirectional LSPs. The FRR procedures can ensure that for 124 the co-routed LSPs, traffic flows on co-routed paths in the forward 125 and reverse directions after a failure event. 127 1.1. Assumptions and Considerations 129 The following assumptions and considerations apply to this document: 131 o The FRR procedure for the unidirectional LSPs is defined in 132 [RFC4090] and is not modified by this document. 134 o The FRR procedure when using the unidirectional bypass tunnels is 135 defined in [RFC4090] and is not modified by this document. 137 o This document assumes that the FRR bypass tunnels used for 138 protected associated bidirectional LSPs are also associated 139 bidirectional. 141 o The FRR bypass tunnels used for protected co-routed associated 142 bidirectional LSPs are assumed to be co-routed associated 143 bidirectional. 145 o The FRR procedure to coordinate the bypass tunnel assignment 146 defined in this document may be used for protected non-corouted 147 associated bidirectional LSPs but requires that the downstream 148 Point of Local Repair (PLR) and Merge Point (MP) pair of the 149 forward LSP matches the upstream MP and PLR pair of the reverse 150 LSP. 152 o Unless otherwise specified in this document, the fast reroute 153 procedures defined in [RFC4090] are used for associated 154 bidirectional LSPs. 156 2. Conventions Used in This Document 158 2.1. Key Word Definitions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 2.2. Terminology 166 The reader is assumed to be familiar with the terminology defined in 167 [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271]. 169 2.2.1. Forward Unidirectional LSPs 171 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 172 opposite directions between a pair of source and destination nodes to 173 form an associated bidirectional LSP. In the case of single-sided 174 provisioned LSP, the originating LSP with REVERSE_LSP Object is 175 identified as a forward unidirectional LSP. In the case of double- 176 sided provisioned LSP, the LSP originating from the higher node 177 address (as source) and terminating on the lower node address (as 178 destination) is identified as a forward unidirectional LSP. 180 2.2.2. Reverse Co-routed Unidirectional LSPs 182 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 183 opposite directions between a pair of source and destination nodes to 184 form an associated bidirectional LSP. A reverse unidirectional LSP 185 originates on the same node where the forward unidirectional LSP 186 terminates, and it terminates on the same node where the forward 187 unidirectional LSP originates. A reverse co-routed unidirectional 188 LSP traverses along the same path as the forward direction 189 unidirectional LSP in the opposite direction. 191 3. Problem Statement 193 As specified in [RFC7551], in the single-sided provisioning case, the 194 RSVP TE tunnel is configured only on one endpoint node of the 195 bidirectional LSP. An LSP for this tunnel is initiated by the 196 originating endpoint with (Extended) ASSOCIATION Object containing 197 Association Type set to "single-sided associated bidirectional LSP" 198 and REVERSE_LSP Object inserted in the RSVP Path message. The remote 199 endpoint then creates the corresponding reverse TE tunnel and signals 200 the reverse LSP in response using the information from the 201 REVERSE_LSP Object and other objects present in the received RSVP 202 Path message. As specified in [RFC7551], in the double-sided 203 provisioning case, the RSVP TE tunnel is configured on both endpoint 204 nodes of the bidirectional LSP. Both forward and reverse LSPs are 205 initiated independently by the two endpoints with (Extended) 206 ASSOCIATION Object containing Association Type set to "double-sided 207 associated bidirectional LSP". With both single-sided and double- 208 sided provisioned bidirectional LSPs, the reverse LSP may or may not 209 be congruent (i.e. co-routed) and follow the same path as its forward 210 LSP. 212 Both single-sided and double-sided associated bidirectional LSPs 213 require solutions to the following issues for fast reroute to ensure 214 co-routing after a failure event. 216 3.1. Fast Reroute Bypass Tunnel Assignment 218 In order to ensure that the traffic flows on a co-routed path after a 219 link or node failure on the protected co-routed LSP path, the mid- 220 point Point of Local Repair (PLR) nodes need to assign matching 221 bidirectional bypass tunnels for fast reroute. Such bypass 222 assignment requires coordination between the forward and reverse 223 direction PLR nodes when more than one bypass tunnels are present on 224 a PLR node. 226 <-- Bypass N --> 227 +-----+ +-----+ 228 | H +---------+ I | 229 +--+--+ +--+--+ 230 | | 231 | | 232 LSP1 --> | LSP1 --> | LSP1 --> LSP1 --> 233 +-----+ +--+--+ +--+--+ +-----+ +-----+ 234 | A +--------+ B +----X----+ C +--------+ D +--------+ E | 235 +-----+ +--+--+ +--+--+ +-----+ +-----+ 236 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 237 | | 238 | | 239 +--+--+ +--+--+ 240 | F +---------+ G | 241 +-----+ +-----+ 242 <-- Bypass S --> 244 Figure 1: Multiple Bidirectional Bypass Tunnels 246 As shown in Figure 1, there are two bypass tunnels available, Bypass 247 tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C). 248 The mid-point PLR nodes B and C need to coordinate bypass tunnel 249 assignment to ensure that traffic in both directions flow through 250 either on the Bypass tunnel N or the Bypass tunnel S, after the link 251 B-C failure. 253 3.2. Node Protection Bypass Tunnels 255 When using a node protection bypass tunnel with a protected 256 associated bidirectional LSP, after a link failure, the forward and 257 reverse LSP traffic can flow on different node protection bypass 258 tunnels in the upstream and downstream directions. 260 <-- Bypass N --> 261 +-----+ +-----+ 262 | H +------------------------+ I | 263 +--+--+ +--+--+ 264 | <-- Rerouted-LSP2 | 265 | | 266 | | 267 | LSP1 --> LSP1 --> | LSP1 --> LSP1 --> 268 +--+--+ +-----+ +--+--+ +-----+ +-----+ 269 | A +--------+ B +----X----+ C +--------+ D +--------+ E | 270 +-----+ +--+--+ +-----+ +--+--+ +-----+ 271 <-- LSP2 | <-- LSP2 <-- LSP2 | <-- LSP2 272 | | 273 | | 274 | Rerouted-LSP1 --> | 275 +--+--+ +--+--+ 276 | F +------------------------+ G | 277 +-----+ +-----+ 278 <-- Bypass S --> 280 Figure 2: Node Protection Bypass Tunnels 282 As shown in Figure 2, after the link B-C failure, the downstream PLR 283 node B reroutes the protected forward LSP1 traffic over the bypass 284 tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the 285 upstream PLR node C reroute the protected reverse LSP2 traffic over 286 the bypass tunnel N (on path C-I-H-A) to reach the upstream MP node 287 A. As a result, the traffic in the forward and revere directions 288 flows on different bypass tunnels and this can cause the co-routed 289 associated bidirectional LSP to become non-corouted. However, unlike 290 GMPLS LSPs, the asymmetry of paths in the forward and reverse 291 directions does not result in RSVP soft-state timeout with the 292 associated bidirectional LSPs. 294 3.3. Bidirectional LSP Association At Mid-Points 296 In packet transport networks, a restoration LSP is signaled after a 297 link failure on the protected LSP path and the protected LSP may or 298 may not be torn down [RFC8131]. In this case, multiple forward and 299 reverse LSPs of a co-routed associated bidirectional LSP may be 300 present at mid-point nodes with identical (Extended) ASSOCIATION 301 Objects. This creates an ambiguity at mid-point nodes to identify 302 the correct associated LSP pair for fast reroute bypass assignment 303 (e.g. during the recovery phase of RSVP graceful restart procedure). 305 LSP3 --> LSP3 --> LSP3 --> 306 LSP1 --> LSP1 --> LSP1 --> LSP1 --> 307 +-----+ +-----+ +-----+ +-----+ +-----+ 308 | A +--------+ B +----X----+ C +--------+ D +--------+ E | 309 +-----+ +--+--+ +--+--+ +-----+ +-----+ 310 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 311 <-- LSP4 | | <-- LSP4 <-- LSP4 312 | | 313 | LSP3 --> | 314 +--+--+ +--+--+ 315 | F +---------+ G | 316 +-----+ +-----+ 317 <-- Bypass S --> 318 <-- LSP4 320 Figure 3: Restoration LSP Set-up after Link Failure 322 As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an 323 associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are 324 an associated LSP pair, both pairs belong to the same associated 325 bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. 326 In this example, the mid-point node D may mistakenly associate LSP1 327 with the reverse LSP4 instead of the reverse LSP3 due to the matching 328 (Extended) ASSOCIATION Objects. This may cause the co-routed 329 associated bidirectional LSP to become non-corouted after fast 330 reroute. Since the bypass assignment needs to be coordinated between 331 the forward and reverse LSPs, this can also lead to undesired bypass 332 tunnel assignments. 334 4. Signaling Procedure 336 4.1. Associated Bidirectional LSP Fast Reroute 338 For both single-sided and double-sided associated bidirectional LSPs, 339 the fast reroute procedure specified in [RFC4090] is used. In 340 addition, the mechanisms defined in [RFC8271] are used as following. 342 o The BYPASS_ASSIGNMENT IPv4 subobject (value: 38) and IPv6 343 subobject (value: 39) defined in [RFC8271] are used to coordinate 344 bypass tunnel assignment between the forward and reverse direction 345 PLR nodes (see Figure 1). The BYPASS_ASSIGNMENT and Node-ID 346 address [RFC4561] subobjects MUST be added by the downstream PLR 347 node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of 348 the forward LSP to indicate the local bypass tunnel assignment 349 using the procedure defined in [RFC8271]. The upstream node uses 350 the bypass assignment information (namely, bypass tunnel source 351 address, destination address and Tunnel ID) in the received RSVP 352 Path message of the protected forward LSP to find the associated 353 bypass tunnel in the reverse direction. The upstream PLR node 354 MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the 355 RSVP Path message of the reverse LSP. 357 o The downstream PLR node initiates the bypass tunnel assignment for 358 the forward LSP. The upstream PLR (forward direction LSP MP) node 359 reflects the associated bypass tunnel assignment for the reverse 360 direction LSP. The upstream PLR node MUST NOT initiate the bypass 361 tunnel assignment. 363 o If the indicated forward bypass tunnel or the associated reverse 364 bypass tunnel is not found, the upstream PLR SHOULD send a Notify 365 message [RFC3473] with Error-code "FRR Bypass Assignment Error" 366 (value: 44) and Sub-code "Bypass Tunnel Not Found" (value: 1) 367 [RFC8271] to the downstream PLR. 369 o If the bypass tunnel can not be used as described in Section 4.5.3 370 in [RFC8271], the upstream PLR SHOULD send a Notify message 371 [RFC3473] with Error-code "FRR Bypass Assignment Error" (value: 373 44) and Sub-code "Bypass Assignment Cannot Be Used" (value: 0) 374 [RFC8271] to the downstream PLR. 376 o After a link or node failure, the PLR nodes in both forward and 377 reverse directions trigger fast reroute independently using the 378 procedures defined in [RFC4090] and send the forward and protected 379 reverse LSP modified RSVP Path messages and traffic over the 380 bypass tunnel. The RSVP Resv signaling of the protected forward 381 and reverse LSPs follows the same procedure as defined in 382 [RFC4090] and is not modified by this document. 384 4.1.1. Restoring Co-routing with Node Protection Bypass Tunnels 386 After fast reroute, the downstream MP node assumes the role of 387 upstream PLR and reroutes the reverse LSP RSVP Path messages and 388 traffic over the bypass tunnel on which the forward LSP RSVP Path 389 messages and traffic are received. This procedure is defined as 390 restoring co-routing in [RFC8271]. This procedure is used to ensure 391 that both forward and reverse LSP signaling and traffic flow on the 392 same bidirectional bypass tunnel after fast reroute. 394 As shown in Figure 2, when using a node protection bypass tunnel with 395 protected co-routed LSPs, asymmetry of paths can occur in the forward 396 and reverse directions after a link failure [RFC8271]. In order to 397 restore co-routing, the downstream MP node D (acting as an upstream 398 PLR) SHOULD trigger the procedure to restore co-routing and reroute 399 the protected reverse LSP2 RSVP Path messages and traffic over the 400 bypass tunnel S (on path D-G-F-B) to the upstream MP node B upon 401 receiving the protected forward LSP modified RSVP Path messages and 402 traffic over the bypass tunnel S (on path D-G-F-B) from node B. The 403 upstream PLR node C stops receiving the RSVP Path messages and 404 traffic for the reverse LSP2 from node D (resulting in RSVP 405 soft-state timeout) and it stops sending the RSVP Path messages for 406 the reverse LSP2 over the bypass tunnel N (on path C-I-H-A) to node 407 A. 409 4.1.2. Unidirectional Link Failures 411 The unidirectional link failures can cause co-routed associated 412 bidirectional LSPs to become non-corouted after fast reroute with 413 both link protection and node protection bypass tunnels. However, 414 the unidirectional link failures in the upstream and/or downstream 415 directions do not result in RSVP soft-state timeout with the 416 associated bidirectional LSPs as upstream and downstream PLRs trigger 417 fast reroute independently. The asymmetry of forward and reverse LSP 418 paths due to the unidirectional link failure in the downstream 419 direction can be corrected by using the procedure to restore co- 420 routing specified in Section 4.1.1. 422 4.1.3. Revertive Behavior after Fast Reroute 424 When the revertive behavior is desired for a protected LSP after the 425 link is restored, the procedure defined in [RFC4090], Section 6.5.2, 426 is followed. 428 o The downstream PLR node starts sending the RSVP Path messages and 429 traffic flow of the protected forward LSP over the restored link 430 and stops sending them over the bypass tunnel [RFC4090]. 432 o The upstream PLR node (when the protected LSP is present) also 433 starts sending the RSVP Path messages and traffic flow of the 434 protected reverse LSPs over the restored link and stops sending 435 them over the bypass tunnel [RFC4090]. 437 o In case of node protection bypass tunnels (see Figure 2), after 438 restoring co-routing, the upstream PLR node D SHOULD start sending 439 RSVP Path messages and traffic for the reverse LSP over the 440 original link (C-D) when it receives the un-modified RSVP Path 441 messages and traffic for the protected forward LSP over it and 442 stops sending them over the bypass tunnel S (on path D-G-F-B). 444 4.1.4. Bypass Tunnel Provisioning 446 Fast reroute bidirectional bypass tunnels can be single-sided or 447 double-sided associated tunnels. For both single-sided and double- 448 sided associated bypass tunnels, the fast reroute assignment policies 449 need to be configured on the downstream PLR nodes of the protected 450 LSPs that initiate the bypass tunnel assignments. For single-sided 451 associated bypass tunnels, these nodes are the originating endpoints 452 of their signaling. 454 4.1.5. One-to-One Bypass Tunnel 456 The fast reroute signaling procedure defined in this document can be 457 used for both facility backup described in Section 3.2 of [RFC4090] 458 and one-to-one backup described in Section 3.1 of [RFC4090]. As 459 described in Section 5.4.2 of [RFC8271], in one-to-one backup method, 460 if the associated bidirectional bypass tunnel is already in-use at 461 the upstream PLR, it SHOULD send a Notify message [RFC3473] with 462 Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code 463 "One-to-One Bypass Already in Use" (value: 2) to the downstream PLR. 465 4.2. Bidirectional LSP Association At Mid-points 467 In order to associate the LSPs unambiguously at a mid-point node (see 468 Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object 469 and add unique Extended Association ID for each associated forward 470 and reverse LSP pair forming the bidirectional LSP. An endpoint node 471 MAY set the Extended Association ID to the value shown in Appendix A. 473 o For single-sided provisioned bidirectional LSPs [RFC7551], the 474 originating endpoint signals the Extended ASSOCIATION Object with 475 a unique Extended Association ID. The remote endpoint copies the 476 contents of the received Extended ASSOCIATION Object including the 477 Extended Association ID in the RSVP Path message of the reverse 478 LSP's Extended ASSOCIATION Object. 480 o For double-sided provisioned bidirectional LSPs [RFC7551], both 481 endpoints need to ensure that the bidirectional LSP has a unique 482 Extended ASSOCIATION Object for each forward and reverse LSP pair 483 by selecting appropriate unique Extended Association IDs signaled 484 by them. 486 5. Compatibility 488 This document updates the procedures for fast reroute for associated 489 bidirectional LSPs defined in [RFC4090] and for associating 490 bidirectional LSPs defined in [RFC7551]. Operators wishing to use 491 this function SHOULD ensure that it is supported on all the nodes on 492 the LSP path. No new signaling messages are defined in this 493 document. 495 6. Security Considerations 497 This document updates the signaling mechanisms defined in [RFC4090] 498 and [RFC7551]; and does not introduce any additional security 499 considerations other than those already covered in [RFC4090], 500 [RFC7551], [RFC8271], and the MPLS/GMPLS security framework 501 [RFC5920]. 503 7. IANA Considerations 505 This document does not require any IANA actions. 507 Appendix A. Extended ASSOCIATION ID 509 Extended Association ID in the Extended ASSOCIATION Object [RFC6780] 510 can be set to the value shown in the following example to uniquely 511 identify associated forward and reverse LSP pair of an associated 512 bidirectional LSP. 514 An example of IPv4 Extended Association ID format is shown below: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | IPv4 LSP Source Address | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Reserved | LSP-ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 : : 524 : Variable Length ID : 525 : : 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Figure 4: IPv4 Extended Association ID Format Example 530 LSP Source Address 532 IPv4 source address of the forward LSP [RFC3209]. 534 LSP-ID 536 16-bits LSP-ID of the forward LSP [RFC3209]. 538 Variable Length ID 540 Variable length ID inserted by the endpoint node of the associated 541 bidirectional LSP [RFC6780]. 543 An example of IPv6 Extended Association ID format is shown below: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 + + 550 | IPv6 LSP Source Address | 551 + + 552 | (16 bytes) | 553 + + 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Reserved | LSP-ID | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 : : 559 : Variable Length ID : 561 : : 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 5: IPv6 Extended Association ID Format Example 566 LSP Source Address 568 IPv6 source address of the forward LSP [RFC3209]. 570 LSP-ID 572 16-bits LSP-ID of the forward LSP [RFC3209]. 574 Variable Length ID 576 Variable length ID inserted by the endpoint node of the associated 577 bidirectional LSP [RFC6780]. 579 8. References 581 8.1. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 587 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 588 Functional Specification", RFC 2205, September 1997. 590 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 591 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 592 May 2005. 594 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 595 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 596 4561, June 2006. 598 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 599 Association Object Extensions", RFC 6780, October 2012. 601 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 602 Extensions for Associated Bidirectional Label Switched 603 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 604 . 606 [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and 607 M. Bhatia, "Updates to Resource Reservation Protocol for 608 Fast Reroute of Traffic Engineering GMPLS Label Switched 609 Paths (LSPs)", RFC 8271, October 2017. 611 8.2. Informative References 613 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 614 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 615 Tunnels", RFC 3209, December 2001. 617 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 618 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 619 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 621 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 622 Networks", RFC 5920, July 2010. 624 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 625 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 627 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 628 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 629 Framework", RFC 6373, September 2011. 631 [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and 632 P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End 633 GMPLS Restoration and Resource Sharing", RFC 8131, March 634 2017. 636 Acknowledgments 638 A special thanks to the authors of [RFC8271], this document uses the 639 signaling mechanisms defined in that document. The authors would 640 also like to thank Vishnu Pavan Beeram and Daniele Ceccarelli for 641 reviewing this document and providing valuable comments. 643 Authors' Addresses 645 Rakesh Gandhi (editor) 646 Cisco Systems, Inc. 647 Canada 649 Email: rgandhi@cisco.com 651 Himanshu Shah 652 Ciena 654 Email: hshah@ciena.com 656 Jeremy Whittaker 657 Verizon 659 Email: jeremy.whittaker@verizon.com