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