idnits 2.17.1 draft-ietf-teas-assoc-corouted-bidir-frr-04.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 (July 15, 2018) is 2102 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: January 16, 2019 J. Whittaker 7 Verizon 8 July 15, 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-04 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Example of 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 (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 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. Overview 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 (on path B-H-I-C) or the Bypass tunnel 251 S (on path B-F-G-C), after the link 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 always initiates the bypass tunnel 358 assignment for the forward LSP. The upstream PLR (forward 359 direction LSP MP) node simply reflects the associated bypass 360 tunnel assignment for the reverse direction LSP. The upstream PLR 361 node MUST NOT initiate the bypass 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 procedure to restore co-routing and reroute the 399 protected reverse LSP2 RSVP Path messages and traffic over the bypass 400 tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving 401 the protected forward LSP modified RSVP Path messages and traffic 402 over the bypass tunnel S (on path D-G-F-B) from node B. The upstream 403 PLR node C stops receiving the RSVP Path messages and traffic for the 404 reverse LSP2 from node D (resulting in RSVP soft-state timeout) and 405 it stops sending the RSVP Path messages for the reverse LSP2 over the 406 bypass tunnel N (on path C-I-H-A) to node A. 408 4.1.2. Unidirectional Link Failures 410 The unidirectional link failures can cause co-routed associated 411 bidirectional LSPs to become non-corouted after fast reroute with 412 both link protection and node protection bypass tunnels. However, 413 the unidirectional link failures in the upstream and/or downstream 414 directions do not result in RSVP soft-state timeout with the 415 associated bidirectional LSPs as upstream and downstream PLRs trigger 416 fast reroute independently. The asymmetry of forward and reverse LSP 417 paths due to the unidirectional link failure in the downstream 418 direction can be corrected by using the procedure to restore co- 419 routing specified in Section 4.1.1. 421 4.1.3. Revertive Behavior after Fast Reroute 423 When the revertive behavior is desired for a protected LSP after the 424 link is restored, the procedure defined in [RFC4090], Section 6.5.2, 425 is followed. 427 o The downstream PLR node starts sending the RSVP Path messages and 428 traffic flow of the protected forward LSP over the restored link 429 and stops sending them over the bypass tunnel [RFC4090]. 431 o The upstream PLR node (when the protected LSP is present) also 432 starts sending the RSVP Path messages and traffic flow of the 433 protected reverse LSPs over the restored link and stops sending 434 them over the bypass tunnel [RFC4090]. 436 o In case of node protection bypass tunnels (see Figure 2), after 437 restoring co-routing, the upstream PLR node D SHOULD start sending 438 RSVP Path messages and traffic for the reverse LSP over the 439 original link (C-D) when it receives the un-modified RSVP Path 440 messages and traffic for the protected forward LSP over it and 441 stops sending them over the bypass tunnel S (on path D-G-F-B). 443 4.1.4. Bypass Tunnel Provisioning 445 Fast reroute bidirectional bypass tunnels can be single-sided or 446 double-sided associated tunnels. For both single-sided and double- 447 sided associated bypass tunnels, the fast reroute assignment policies 448 need to be configured on the downstream PLR nodes of the protected 449 LSPs that initiate the bypass tunnel assignments. For single-sided 450 associated bypass tunnels, these nodes are the originating endpoints 451 of their signaling. 453 4.1.5. One-to-One Bypass Tunnel 455 The fast reroute signaling procedure defined in this document can be 456 used for both facility backup described in Section 3.2 of [RFC4090] 457 and one-to-one backup described in Section 3.1 of [RFC4090]. As 458 described in Section 5.4.2 of [RFC8271], in one-to-one backup method, 459 if the associated bidirectional bypass tunnel is already in-use at 460 the upstream PLR, it SHOULD send a Notify message [RFC3473] with 461 Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code 462 "One-to-One Bypass Already in Use" (value: 2) to the downstream PLR. 464 4.2. Bidirectional LSP Association At Mid-points 466 In order to associate the LSPs unambiguously at a mid-point node (see 467 Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object 468 and add unique Extended Association ID for each associated forward 469 and reverse LSP pair forming the bidirectional LSP. As an example, 470 an endpoint node MAY set the Extended Association ID to the value 471 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. Example of 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 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 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 : 560 : : 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Figure 5: IPv6 Extended Association ID Format Example 565 LSP Source Address 567 IPv6 source address of the forward LSP [RFC3209]. 569 LSP-ID 571 16-bits LSP-ID of the forward LSP [RFC3209]. 573 Variable Length ID 575 Variable length ID inserted by the endpoint node of the associated 576 bidirectional LSP [RFC6780]. 578 8. References 580 8.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 586 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 587 Functional Specification", RFC 2205, September 1997. 589 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 590 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 591 May 2005. 593 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 594 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 595 4561, June 2006. 597 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 598 Association Object Extensions", RFC 6780, October 2012. 600 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 601 Extensions for Associated Bidirectional Label Switched 602 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 603 . 605 [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and 606 M. Bhatia, "Updates to Resource Reservation Protocol for 607 Fast Reroute of Traffic Engineering GMPLS Label Switched 608 Paths (LSPs)", RFC 8271, October 2017. 610 8.2. Informative References 612 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 613 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 614 Tunnels", RFC 3209, December 2001. 616 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 617 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 618 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 620 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 621 Networks", RFC 5920, July 2010. 623 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 624 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 626 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 627 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 628 Framework", RFC 6373, September 2011. 630 [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and 631 P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End 632 GMPLS Restoration and Resource Sharing", RFC 8131, March 633 2017. 635 Acknowledgments 637 A special thanks to the authors of [RFC8271], this document uses the 638 signaling mechanisms defined in that document. 640 Authors' Addresses 642 Rakesh Gandhi (editor) 643 Cisco Systems, Inc. 644 Canada 646 Email: rgandhi@cisco.com 648 Himanshu Shah 649 Ciena 651 Email: hshah@ciena.com 653 Jeremy Whittaker 654 Verizon 656 Email: jeremy.whittaker@verizon.com