idnits 2.17.00 (12 Aug 2021) /tmp/idnits46693/draft-ietf-teas-gmpls-lsp-fastreroute-12.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. 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 28, 2017) is 1720 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group M. Taillon 3 Internet-Draft T. Saad, Ed. 4 Updates: 4090 R. Gandhi, Ed. 5 Intended Status: Standards Track Z. Ali 6 Expires: March 1, 2018 Cisco Systems, Inc. 7 M. Bhatia 8 Nokia 9 August 28, 2017 11 Updates to Resource Reservation Protocol For Fast Reroute of 12 Traffic Engineering GMPLS LSPs 13 draft-ietf-teas-gmpls-lsp-fastreroute-12 15 Abstract 17 This document updates the Resource Reservation Protocol - Traffic 18 Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 19 4090 to support Packet Switched Capable (PSC) Generalized Multi- 20 Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These 21 updates allow the coordination of a bidirectional bypass tunnel 22 assignment protecting a common facility in both forward and reverse 23 directions of a co-routed bidirectional LSP. In addition, these 24 updates enable the re-direction of bidirectional traffic onto bypass 25 tunnels that ensure co-routedness of data paths in the forward and 26 reverse directions after FRR and avoid RSVP soft-state timeout in 27 control-plane. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 Copyright Notice 45 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 62 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 5 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 6 66 4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs . . . . 6 67 4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7 68 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7 70 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8 71 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 8 72 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling 73 Procedure . . . . . . . . . . . . . . . . . . . . . . 8 74 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment . . 10 75 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . . 10 76 5. Fast Reroute For Bidirectional GMPLS LSPs with In-band 77 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . . 12 79 5.1.1. Behavior After Link Failure . . . . . . . . . . . . . 12 80 5.1.2. Revertive Behavior After Fast Reroute . . . . . . . . 12 81 5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . . 13 82 5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 14 83 5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 14 84 5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 15 85 5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15 86 5.2.4. Behaviour After Node Failure . . . . . . . . . . . . . 16 87 5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 16 88 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band 89 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 7. Message and Object Definitions . . . . . . . . . . . . . . . . 17 92 7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17 93 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 19 94 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 20 98 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 20 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 101 11.2. Informative References . . . . . . . . . . . . . . . . . 22 102 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 Packet Switched Capable (PSC) Traffic Engineering (TE) Label Switched 109 Paths (LSPs) can be setup using Generalized Multi-Protocol Label 110 Switching (GMPLS) signaling procedures specified in [RFC3473] for 111 both unidirectional and bidirectional tunnels. The GMPLS signaling 112 allows sending and receiving the RSVP messages in-band with the data 113 traffic or out-of-band over a separate control-channel. Fast Reroute 114 (FRR) [RFC4090] has been widely deployed in the packet TE networks 115 today and is desirable for TE GMPLS LSPs. Using FRR methods also 116 allows the leveraging of the existing mechanisms for failure 117 detection and restoration in deployed networks. 119 The FRR procedures defined in [RFC4090] describe the behavior of the 120 Point of Local Repair (PLR) to reroute traffic and signaling onto the 121 bypass tunnel in the event of a failure for protected LSPs. Those 122 procedures are applicable to the unidirectional protected LSPs 123 signaled using either RSVP-TE [RFC3209] or GMPLS procedures 124 [RFC3473]. When using the FRR procedures defined in [RFC4090] with 125 co-routed bidirectional GMPLS LSPs, it is desired that same PLR and 126 Merge Point (MP) pairs are selected in each direction and both PLR 127 and MP assign the same bidirectional bypass tunnel. This document 128 updates the FRR procedures defined in [RFC4090] to coordinate the 129 bidirectional bypass tunnel assignment and to exchange MP labels 130 between upstream and downstream PLRs of the protected co-routed 131 bidirectional LSP. 133 When using FRR procedures with co-routed bidirectional GMPLS LSPs, it 134 is possible in some cases for the RSVP signaling refreshes to stop 135 reaching certain nodes along the protected LSP path after the PLRs 136 finish rerouting of the signaling messages. This can occur after a 137 failure event when using node protection bypass tunnels. As shown in 138 Figure 2, this is possible even with selecting the same bidirectional 139 bypass tunnels in both directions and the same PLR and MP pairs. 140 This is caused by the asymmetry of paths that may be taken by the 141 bidirectional LSP's signaling in the forward and reverse directions 142 due to upstream and downstream PLRs independently triggering FRR. In 143 such cases, after FRR, the RSVP soft-state timeout causes the 144 protected bidirectional LSP to be torn down, with subsequent traffic 145 loss. 147 Protection State Coordination Protocol [RFC6378] is applicable to FRR 148 [RFC4090] for local protection of co-routed bidirectional LSPs in 149 order to minimize traffic disruptions in both directions. However, 150 this does not address the above mentioned problem of RSVP soft-state 151 timeout that can occur in the control-plane. 153 This document defines a solution to the RSVP soft-state timeout issue 154 by providing mechanisms in the control-plane to complement the FRR 155 procedures of [RFC4090]. The solution allows to maintain the RSVP 156 soft-state for co-routed bidirectional protected GMPLS LSPs in the 157 control-plane and achieve co-routedness of the paths followed by the 158 traffic in the forward and reverse directions after FRR. 160 The procedures defined in this document apply to GMPLS signaled PSC 161 TE co-routed bidirectional protected LSPs and co-routed bidirectional 162 FRR bypass tunnels. Unless otherwise specified in this document, the 163 FRR procedures defined in [RFC4090] are not modified by this 164 document. The FRR mechanism for associated bidirectional GMPLS LSPs 165 where two unidirectional GMPLS LSPs are bound together by using the 166 association signaling [RFC7551] is outside the scope of this 167 document. 169 2. Conventions Used in This Document 171 2.1. Key Word Definitions 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 2.2. Terminology 179 The reader is assumed to be familiar with the terminology in 180 [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090]. 182 Downstream PLR: Downstream Point of Local Repair. The PLR that 183 locally detects a failure in the downstream direction of the 184 traffic flow and reroutes traffic in the same direction of the 185 protected bidirectional LSP RSVP Path signaling. A downstream PLR 186 has a corresponding downstream MP. 188 Downstream MP: Downstream Merge Point. The LSR where one or more 189 backup tunnels rejoin the path of the protected LSP in the 190 downstream direction of the traffic flow. The same LSR can be 191 both a downstream MP and an upstream PLR simultaneously. 193 Upstream PLR: Upstream Point of Local Repair. The PLR that locally 194 detects a failure in the upstream direction of the traffic flow 195 and reroutes traffic in the opposite direction of the protected 196 bidirectional LSP RSVP Path signaling. An upstream PLR has a 197 corresponding upstream MP. 199 Upstream MP: Upstream Merge Point. The LSR where one or more backup 200 tunnels rejoin the path of the protected LSP in the upstream 201 direction of the traffic flow. The same LSR can be both an 202 upstream MP and a downstream PLR simultaneously. 204 Point of Remote Repair (PRR): A downstream MP that assumes the role 205 of upstream PLR upon receiving protected LSP's rerouted Path 206 message and triggers reroute of traffic and signaling in the 207 upstream direction of the traffic flow using the procedures 208 described in this document. 210 2.3. Abbreviations 212 GMPLS: Generalized Multi-Protocol Label Switching 214 LSP: Label Switched Path 216 LSR: Label Switching Router 218 MP: Merge Point 220 MPLS: Multi-Protocol Label Switching 222 PLR: Point of Local Repair 224 PSC: Packet Switched Capable 226 RSVP: Resource ReSerVation Protocol 228 TE: Traffic Engineering 230 3. Fast Reroute For Unidirectional GMPLS LSPs 232 The FRR procedures defined in [RFC4090] for RSVP-TE signaling 233 [RFC3209] are equally applicable to the unidirectional protected LSPs 234 signaled using GMPLS [RFC3473] and are not modified by the updates 235 defined in this document except the following. 237 When using the GMPLS out-of-band signaling [RFC3473], after a link 238 failure event, the RSVP messages are not rerouted over the bypass 239 tunnel by the downstream PLR but instead rerouted over a 240 control-channel to the downstream MP. 242 4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs 244 This section describes signaling procedures for FRR bidirectional 245 bypass tunnel assignment for GMPLS signaled PSC co-routed 246 bidirectional TE LSPs for both in-band and out-of-band signaling. 248 4.1. Bidirectional GMPLS Bypass Tunnel Direction 250 This document defines procedures where bidirectional GMPLS bypass 251 tunnels are signaled in the same direction as the protected GMPLS 252 LSPs. In other words, the bidirectional GMPLS bypass tunnels 253 originate on the downstream PLRs and terminate on the corresponding 254 downstream MPs. As the originating downstream PLR has the policy 255 information about the locally provisioned bypass tunnels, it always 256 initiates the bypass tunnel assignment. The bidirectional GMPLS 257 bypass tunnels originating from the upstream PLRs and terminating on 258 the corresponding upstream MPs are outside the scope of this 259 document. 261 4.2. Merge Point Labels 263 To correctly reroute data traffic over a node protection bypass 264 tunnel, the downstream and upstream PLRs have to know, in advance, 265 the downstream and upstream MP labels of the protected LSP so that 266 data in the forward and reverse directions can be redirected through 267 the bypass tunnel after FRR respectively. 269 [RFC4090] defines procedures for the downstream PLR to obtain the 270 protected LSP's downstream MP label from recorded labels in the 271 RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the 272 downstream PLR. 274 To obtain the upstream MP label, the procedures specified in 275 [RFC4090] are used to record the upstream MP label in the RRO of the 276 RSVP Path message of the protected LSP. The upstream PLR obtains the 277 upstream MP label from the recorded labels in the RRO of the received 278 RSVP Path message. 280 4.3. Merge Point Addresses 282 To correctly assign a bidirectional bypass tunnel, the downstream and 283 upstream PLRs have to know, in advance, the downstream and upstream 284 MP addresses. 286 [RFC4561] defines procedures for the downstream PLR to obtain the 287 protected LSP's downstream MP address from the recorded Node-IDs in 288 the RRO of the RSVP Resv message received at the downstream PLR. 290 To obtain the upstream MP address, the procedures specified in 291 [RFC4561] are used to record upstream MP Node-ID in the RRO of the 292 RSVP Path message of the protected LSP. The upstream PLR obtains the 293 upstream MP address from the recorded Node-IDs in the RRO of the 294 received RSVP Path message. 296 4.4. RRO IPv4/IPv6 Subobject Flags 298 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 299 and are equally applicable to the FRR procedure for the protected 300 bidirectional GMPLS LSPs. 302 The procedures defined in [RFC4090] are used by the downstream PLR to 303 signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP 304 Resv message of the protected LSP. Similarly, those procedures are 305 used by the downstream PLR to signal the IPv4/IPv6 subobject flags 306 downstream in the RRO of the RSVP Path message of the protected LSP. 308 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination 310 This document defines signaling procedures and a new 311 BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) 312 used to co-ordinate the bidirectional bypass tunnel assignment 313 between the downstream and upstream PLRs. 315 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure 317 It is desirable to coordinate the bidirectional bypass tunnel 318 selected at the downstream and upstream PLRs so that the rerouted 319 traffic flows on co-routed paths after FRR. To achieve this, a new 320 RSVP subobject is defined for RRO that identifies a bidirectional 321 bypass tunnel that is assigned at a downstream PLR to protect a 322 bidirectional LSP. 324 When the procedures defined in this document are in use, the 325 BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in 326 the RSVP Path RRO message of the GMPLS signaled bidirectional 327 protected LSP to record the downstream bidirectional bypass tunnel 328 assignment. This subobject is sent in the RSVP Path RRO message 329 every time the downstream PLR assigns or updates the bypass tunnel 330 assignment. The downstream PLR can assign a bypass tunnel when 331 processing the first Path message of the protected LSP as long as it 332 has a topological view of the downstream MP and the traversed path 333 information in ERO. For the protected LSP where the downstream MP 334 cannot be determined from the first Path message (e.g. when using 335 loose hops in ERO), the downstream PLR needs to wait for Resv message 336 with RRO in order to assign a bypass tunnel. However, in both cases, 337 the downstream PLR cannot update the data-plane until it receives 338 Resv messages containing the MP labels. 340 The upstream PLR (downstream MP) simply reflects the bypass tunnel 341 assignment in the reverse direction. The absence of 342 BYPASS_ASSIGNMENT subobject in Path RRO means that the relevant node 343 or interface is not protected by a bidirectional bypass tunnel. 345 Hence, the upstream PLR need not assign a bypass tunnel in the 346 reverse direction. 348 When the BYPASS_ASSIGNMENT subobject is added in the Path RRO: 350 o The IPv4 or IPv6 subobject containing Node-ID address MUST also be 351 added [RFC4561]. The Node-ID address MUST match the source 352 address of the bypass tunnel selected for this protected LSP. 354 o The BYPASS_ASSIGNMENT subobject MUST be added immediately after 355 the Node-ID address. 357 o The Label subobject MUST also be added [RFC3209]. 359 The rules for adding an IPv4 or IPv6 Interface address subobject and 360 Unnumbered Interface ID subobject as specified in [RFC3209] and 361 [RFC4090] are not modified by the above procedure. The options 362 specified in Section 6.1.3 in [RFC4990] are also applicable as long 363 as above mentioned rules are followed when using the FRR procedures 364 defined in this document. 366 An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT 367 subobjects in the Path RRO to see if the destination address in the 368 BYPASS_ASSIGNMENT matches the address of the upstream PLR. For each 369 BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for 370 a tunnel that has a source address matching the downstream PLR that 371 inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address, 372 and the same tunnel-ID as indicated in the BYPASS_ASSIGNMENT. The 373 RRO can contain multiple addresses to identify a node, however, the 374 upstream PLR relies on the Node-ID address preceding the 375 BYPASS_ASSIGNMENT subobject for identifying the bypass tunnel. If 376 the bypass tunnel is not found, the upstream PLR SHOULD send a Notify 377 message [RFC3473] with Error-code - FRR Bypass Assignment Error 378 (value: TBA1) and Sub-code - Bypass Tunnel Not Found (value: TBA3) to 379 the downstream PLR. Upon receiving this error, the downstream PLR 380 SHOULD remove the bypass tunnel assignment and select an alternate 381 bypass tunnel if one available. The RRO containing BYPASS_ASSIGNMENT 382 subobject(s) is then simply forwarded downstream in the RSVP Path 383 message. 385 A downstream PLR may add, remove or change bypass tunnel assignment 386 for a protected LSP resulting in addition, removal or modification of 387 BYPASS_ASSIGNMENT subobject in the Path RRO, respectively. In this 388 case, the downstream PLR SHOULD generate modified Path message and 389 forward it downstream. The downstream MP SHOULD check the RRO in the 390 received Path message and update the bypass tunnel assignment in the 391 reverse direction accordingly. 393 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment 395 The bidirectional bypass tunnel assignment co-ordination procedure 396 defined in this document can be used for both facility backup 397 described in Section 3.2 of [RFC4090] and one-to-one backup described 398 in Section 3.1 of [RFC4090]. As specified in [RFC4090], Section 4.2, 399 the DETOUR_OBJECT can be used in one-to-one backup method to identify 400 the detour LSPs. In one-to-one backup method, if the bypass tunnel 401 is already in-use at the upstream PLR, it SHOULD send a Notify 402 message [RFC3473] with Error-code - FRR Bypass Assignment Error 403 (value: TBA1) and Sub-code - One-to-one Bypass Already In-use (value: 404 TBA4) to the downstream PLR. Upon receiving this error, the 405 downstream PLR SHOULD remove the bypass tunnel assignment and select 406 an alternate bypass tunnel if one available. 408 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments 410 The upstream PLR may receive multiple bypass tunnel assignments for a 411 protected LSP from different downstream PLRs leading to an asymmetric 412 bypass tunnel assignment as shown in the following two examples. 414 As shown in Example 1 and Example 2, for the protected bidirectional 415 GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass 416 tunnel assignments, one from downstream PLR R4 for node protection 417 and one from downstream PLR R5 for link protection. In Example 1, R6 418 prefers the link protection bypass tunnel from downstream PLR R5 419 whereas in Example 2, R6 prefers the node protection bypass tunnel 420 from downstream PLR R4. 422 +------->>-------+ 423 / +->>--+ \ 424 / / \ \ 425 / / \ \ 426 [R4]--->>---[R5]--->>---[R6] 427 PATH -> \ / 428 \ / 429 +-<<--+ 431 Example 1: Link protection is preferred on downstream MP 433 +------->>--------+ 434 / +->>--+ \ 435 / / \ \ 436 / / \ \ 437 [R4]--->>---[R5]--->>---[R6] 438 \ PATH -> / 439 \ / 440 \ / 441 +-------<<--------+ 443 Example 2: Node protection is preferred on downstream MP 445 The asymmetry of bypass tunnel assignments can be avoided by using 446 the flags in the SESSION_ATTRIBUTES Object defined in Section 4.3 of 447 [RFC4090]. In particular, the "node protection desired" flag is 448 signaled by the head-end node to request node protection bypass 449 tunnels. When this flag is set, both downstream PLR and upstream PLR 450 nodes assign node protection bypass tunnels as shown in Example 2. 451 In the absence of "node protection desired" flag set, the downstream 452 PLR nodes may only signal the link protection bypass tunnels avoiding 453 the asymmetry of bypass tunnel assignments shown in Example 1. 455 When multiple bypass tunnel assignments are received, the upstream 456 PLR SHOULD send a Notify message [RFC3473] with Error-code - FRR 457 Bypass Assignment Error (value: TBA1) and Sub-code - Bypass 458 Assignment Cannot Be Used (value: TBA2) to the downstream PLR to 459 indicate that it cannot use the bypass tunnel assignment in the 460 reverse direction. Upon receiving this error, the downstream PLR MAY 461 remove the bypass tunnel assignment and select an alternate bypass 462 tunnel if one available. 464 If multiple bypass tunnel assignments are present on the upstream PLR 465 R6 at the time of a failure, any resulted asymmetry gets corrected 466 using the re-coroute procedure after FRR as specified in Section 467 5.2.2 of this document. 469 5. Fast Reroute For Bidirectional GMPLS LSPs with In-band Signaling 471 When a bidirectional bypass tunnel is used, after a link failure, 472 following procedure is followed when using the in-band signaling: 474 o The downstream PLR reroutes protected LSP traffic and RSVP Path 475 signaling over the bidirectional bypass tunnel using the 476 procedures defined in [RFC4090]. The RSVP Path messages are 477 modified as described in Section 6.4.3 of [RFC4090]. 479 o The upstream PLR reroutes protected LSP traffic upon detecting the 480 link failure or upon receiving RSVP Path message over the 481 bidirectional bypass tunnel. 483 o The upstream PLR also reroutes protected LSP RSVP Resv signaling 484 after receiving the modified RSVP Path message over the 485 bidirectional bypass tunnel. The upstream PLR uses the procedure 486 defined in Section 7 of [RFC4090] to detect that RSVP Path 487 messages have been rerouted over the bypass tunnel by the 488 downstream PLR. The upstream PLR does not modify the RSVP Resv 489 message before sending it over the bypass tunnel. 491 The above procedure allows both traffic and RSVP signaling to flow on 492 symmetric paths in the forward and reverse directions of a protected 493 bidirectional GMPLS LSP. The following sections describe the 494 handling for link protection and node protection bypass tunnels. 496 5.1. Link Protection for Bidirectional GMPLS LSPs 498 <- RESV 499 [R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6] 500 PATH -> \ / 501 \ / 502 +<<----->>+ 503 T3 504 PATH -> 505 <- RESV 507 Protected LSP: {R1-R2-R3-R4-R5-R6} 508 R3's Bypass T3: {R3-R4} 510 Figure 1: Flow of RSVP signaling after link failure and FRR 512 Consider the TE network shown in Figure 1. Assume every link in the 513 network is protected with a link protection bypass tunnel (e.g., 514 bypass tunnel T3). For the protected co-routed bidirectional LSP 515 whose head-end is on node R1 and tail-end is on node R6, each 516 traversed node (a potential PLR) assigns a link protection co-routed 517 bidirectional bypass tunnel. 519 5.1.1. Behavior After Link Failure 521 Consider the link R3-R4 on the protected LSP path fails. The 522 downstream PLR R3 and upstream PLR R4 independently trigger fast 523 reroute to redirect traffic onto bypass tunnel T3 in the forward and 524 reverse directions. The downstream PLR R3 also reroutes RSVP Path 525 messages onto the bypass tunnel T3 using the procedures described in 526 [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the 527 reverse bypass tunnel T3 upon receiving RSVP Path message over bypass 528 tunnel T3. 530 5.1.2. Revertive Behavior After Fast Reroute 532 The revertive behavior defined in [RFC4090], Section 6.5.2, is 533 applicable to the link protection of bidirectional GMPLS LSPs. When 534 using the local revertive mode, after the link R3-R4 (in Figure 1) is 535 restored, following node behaviors apply: 537 o The downstream PLR R3 starts sending the Path messages and traffic 538 flow of the protected LSP over the restored link and stops sending 539 them over the bypass tunnel. 541 o The upstream PLR R4 starts sending the traffic flow of the 542 protected LSP over the restored link and stops sending it over the 543 bypass tunnel. 545 o When upstream PLR R4 receives the protected LSP Path messages over 546 the restored link, if not already done, it starts sending Resv 547 messages and traffic flow of the protected LSP over the restored 548 link and stops sending them over the bypass tunnel. 550 5.2. Node Protection for Bidirectional GMPLS LSPs 552 T1 553 +<<------->>+ 554 / \ 555 / \ <- RESV 556 [R1]----[R2]----[R3]--x--[R4]----[R5]----[R6] 557 PATH -> \ / 558 \ / 559 +<<------->>+ 560 T2 562 Protected LSP: {R1-R2-R3-R4-R5-R6} 563 R3's Bypass T2: {R3-R5} 564 R4's Bypass T1: {R4-R2} 566 Figure 2: Flow of RSVP signaling after link failure and FRR 568 Consider the TE network shown in Figure 2. Assume every link in the 569 network is protected with a node protection bypass tunnel. For the 570 protected co-routed bidirectional LSP whose head-end is on node R1 571 and tail-end is on node R6, each traversed node (a potential PLR) 572 assigns a node protection co-routed bidirectional bypass tunnel. 574 The solution introduces two phases to invoking FRR procedures by the 575 PLR after the link failure. The first phase comprises of FRR 576 procedures to fast reroute data traffic onto bypass tunnels in the 577 forward and reverse directions. The second phase re-coroutes the 578 data and signaling in the forward and reverse directions after the 579 first phase. 581 5.2.1. Behavior After Link Failure 583 Consider a link R3-R4 (in Figure 2) on the protected LSP path fails. 584 The downstream PLR R3 and upstream PLR R4 independently trigger fast 585 reroute procedures to redirect the protected LSP traffic onto 586 respective bypass tunnels T2 and T1 in the forward and reverse 587 directions. The downstream PLR R3 also reroutes RSVP Path messages 588 over the bypass tunnel T2 using the procedures described in 589 [RFC4090]. Note, at this point, node R4 stops receiving RSVP Path 590 refreshes for the protected bidirectional LSP while protected traffic 591 continues to flow over bypass tunnels. As node R4 does not receive 592 Path messages over bypass tunnel T1, it does not reroute RSVP Resv 593 messages over the reverse bypass tunnel T1. 595 5.2.2. Behavior After Link Failure To Re-coroute 597 The downstream MP R5 that receives rerouted protected LSP RSVP Path 598 message through the bypass tunnel, in addition to the regular MP 599 processing defined in [RFC4090], gets promoted to a Point of Remote 600 Repair (PRR) role and performs the following actions to re-coroute 601 signaling and data traffic over the same path in the reverse 602 direction: 604 o Finds the bypass tunnel in the reverse direction that terminates 605 on the downstream PLR R3. Note: the downstream PLR R3's address 606 can be extracted from the "IPV4 tunnel sender address" in the 607 SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], 608 Section 6.1.1). 610 o If reverse bypass tunnel is found and the protected LSP traffic is 611 not already rerouted over the found bypass tunnel T2, the PRR R5 612 activates FRR reroute procedures to direct traffic over the found 613 bypass tunnel T2 in the reverse direction. In addition, the PRR 614 R5 also reroutes RSVP Resv over the bypass tunnel T2 in the 615 reverse direction. This can happen when the downstream PLR has 616 changed the bypass tunnel assignment but the upstream PLR has not 617 yet processed the updated Path RRO and programmed the data-plane 618 when link failure occurs. 620 o If reverse bypass tunnel is not found, the PRR R5 immediately 621 tears down the protected LSP. 623 <- RESV 624 [R1]----[R2]----[R3]--X--[R4]----[R5]----[R6] 625 PATH -> \ / 626 \ / 627 +<<------->>+ 629 Bypass Tunnel T2 630 traffic + signaling 632 Protected LSP: {R1-R2-R3-R4-R5-R6} 633 R3's Bypass T2: {R3-R5} 635 Figure 3: Flow of RSVP signaling after FRR and re-coroute 637 Figure 3 describes the path taken by the traffic and signaling after 638 completing re-coroute of data and signaling in the forward and 639 reverse paths described above. Node R4 will stop receiving the Path 640 and Resv messages and it will timeout the RSVP soft-state, however, 641 this will not cause the LSP to be torn down. RSVP signaling at node 642 R2 is not affected by the FRR and re-corouting. 644 If downstream MP R5 receives multiple RSVP Path messages through 645 multiple bypass tunnels (e.g., as a result of multiple failures), the 646 PRR SHOULD identify a bypass tunnel that terminates on the farthest 647 downstream PLR along the protected LSP path (closest to the protected 648 bidirectional LSP head-end) and activate the reroute procedures 649 mentioned above. 651 5.2.2.1. Re-coroute in Data-plane After Link Failure 653 The downstream MP (upstream PLR) MAY optionally support re-corouting 654 in data-plane as follows. If the downstream MP has assigned a 655 bidirectional bypass tunnel, as soon as the downstream MP receives 656 the protected LSP packets on the bypass tunnel, it MAY switch the 657 upstream traffic on to the bypass tunnel. In order to identify the 658 protected LSP packets through the bypass tunnel, Penultimate Hop 659 Popping (PHP) of the bypass tunnel MUST be disabled. The downstream 660 MP checks whether the protected LSP signaling is rerouted over the 661 found bypass tunnel, and if not, it performs the signaling procedure 662 described in Section 5.2.2 of this document. 664 5.2.3. Revertive Behavior After Fast Reroute 666 The revertive behavior defined in [RFC4090], Section 6.5.2, is 667 applicable to the node protection of bidirectional GMPLS LSPs. When 668 using the local revertive mode, after the link R3-R4 (in Figures 2 669 and 3) is restored, following node behaviors apply: 671 o The downstream PLR R3 starts sending the Path messages and traffic 672 flow of the protected LSP over the restored link and stops sending 673 them over the bypass tunnel. 675 o The upstream PLR R4 (when the protected LSP is present) starts 676 sending the traffic flow of the protected LSP over the restored 677 link towards downstream PLR R3 and forwarding the Path messages 678 towards PRR R5 and stops sending the traffic over the bypass 679 tunnel. 681 o When upstream PLR R4 receives the protected LSP Path messages over 682 the restored link, if not already done, the node R4 (when the 683 protected LSP is present) starts sending Resv messages and traffic 684 flow over the restored link towards downstream PLR R3 and 685 forwarding the Path messages towards PRR R5 and stops sending them 686 over the bypass tunnel. 688 o When PRR R5 receives the protected LSP Path messages over the 689 restored path, it starts sending Resv messages and traffic flow 690 over the restored path and stops sending them over the bypass 691 tunnel. 693 5.2.4. Behaviour After Node Failure 695 Consider the node R4 (in Figure 3) on the protected LSP path fails. 696 The downstream PLR R3 and upstream PLR R5 independently trigger fast 697 reroute procedures to redirect the protected LSP traffic onto bypass 698 tunnel T2 in forward and reverse directions. The downstream PLR R3 699 also reroutes RSVP Path messages over the bypass tunnel T2 using the 700 procedures described in [RFC4090]. The upstream PLR R5 reroutes RSVP 701 Resv signaling after receiving the modified RSVP Path message over 702 the bypass tunnel T2. 704 5.3. Unidirectional Link Failures 706 Unidirectional link failures can result in the traffic flowing on 707 asymmetric paths in the forward and reverse directions. In addition, 708 unidirectional link failures can cause RSVP soft-state timeout in the 709 control-plane in some cases. As an example, if the unidirectional 710 link failure is in the upstream direction (from R4 to R3 in Figures 1 711 and 2), the downstream PLR (node R3) can stop receiving the Resv 712 messages of the protected LSP from the upstream PLR (node R4 in 713 Figures 1 and 2) and this can cause RSVP soft-state timeout to occur 714 on the downstream PLR (node R3). 716 A unidirectional link failure in the downstream direction (from R3 to 717 R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when 718 using the FRR procedures defined in this document, since the upstream 719 PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the 720 re-coroute procedure (defined in Section 5.2.2 of this document) 721 after receiving RSVP Path messages of the protected LSP over the 722 bypass tunnel from the downstream PLR (node R3 in Figures 1 and 2). 724 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling 726 When using the GMPLS out-of-band signaling [RFC3473], after a link 727 failure event, the RSVP messages are not rerouted over the 728 bidirectional bypass tunnel by the downstream and upstream PLRs but 729 instead rerouted over the control-channels to the downstream and 730 upstream MPs, respectively. 732 The RSVP soft-state timeout after FRR as described in Section 5.2 of 733 this document is equally applicable to the GMPLS out-of-band 734 signaling as the RSVP signaling refreshes can stop reaching certain 735 nodes along the protected LSP path after the downstream and upstream 736 PLRs finish rerouting of the signaling messages. However, unlike 737 with the in-band signaling, unidirectional link failures as described 738 in Section 5.3 of this document do not result in soft-state timeout 739 with GMPLS out-of-band signaling. Apart from this, the FRR procedure 740 described in Section 5 of this document is equally applicable to the 741 GMPLS out-of-band signaling. 743 7. Message and Object Definitions 745 7.1. BYPASS_ASSIGNMENT Subobject 747 The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP 748 of the bypass tunnel being assigned by the PLR. This can be used to 749 coordinate the bypass tunnel assignment for the protected LSP by the 750 downstream and upstream PLRs in the forward and reverse directions 751 respectively prior or after the failure occurrence. 753 This subobject SHOULD be inserted into the Path RRO by the downstream 754 PLR. It SHOULD NOT be inserted into an RRO by a node which is not a 755 downstream PLR. It MUST NOT be changed by downstream LSRs and MUST 756 NOT be added to a Resv RRO. 758 The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type:TBA5 | Length | Bypass Tunnel ID | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | IPv4 Bypass Destination Address | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject 770 Type 771 Downstream Bypass Assignment. Value is TBA5 by IANA. 773 Length 775 The Length contains the total length of the subobject in bytes, 776 including the Type and Length fields. The length is 8 bytes. 778 Bypass Tunnel ID 780 The bypass tunnel identifier (16 bits). 782 Bypass Destination Address 784 The bypass tunnel IPv4 destination address. 786 The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format: 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type:TBA6 | Length | Bypass Tunnel ID | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | | 794 + + 795 | IPv6 Bypass Destination Address | 796 + (16 bytes) + 797 | | 798 + + 799 | | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject 804 Type 806 Downstream Bypass Assignment. Value is TBA6 by IANA. 808 Length 810 The Length contains the total length of the subobject in bytes, 811 including the Type and Length fields. The length is 20 bytes. 813 Bypass Tunnel ID 815 The bypass tunnel identifier (16 bits). 817 Bypass Destination Address 818 The bypass tunnel IPv6 destination address. 820 7.2. FRR Bypass Assignment Error Notify Message 822 New Error-code - FRR Bypass Assignment Error (value: TBA1) and its 823 sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] 824 in this document, that is carried by the Notify message (Type 21) 825 defined in [RFC3473] Section 4.3. This Error message is sent by the 826 upstream PLR to the downstream PLR to notify a bypass assignment 827 error. In the Notify message, the IP destination address is set to 828 the node address of the downstream PLR that had initiated the bypass 829 assignment. In the ERROR_SPEC Object, IP address is set to the node 830 address of the upstream PLR that detected the bypass assignment 831 error. This Error MUST NOT be sent in a Path Error message. This 832 Error does not cause the protected LSP to be torn down. 834 8. Compatibility 836 New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE 837 Object in this document that is carried in the RSVP Path message. 838 Per [RFC3209], nodes not supporting this subobject will ignore the 839 subobject but forward it without modification. As described in 840 Section 7 of this document, this subobject is not carried in the RSVP 841 Resv message and is ignored by sending the Notify message for FRR 842 Bypass Assignment Error (with Subcode: Bypass Assignment Cannot Be 843 Used) defined in this document. Nodes not supporting the Notify 844 message defined in this document will ignore it but forward it 845 without modification. 847 9. Security Considerations 849 This document introduces a new BYPASS_ASSIGNMENT subobject for the 850 RECORD_ROUTE Object that is carried in an RSVP signaling message. 851 Thus in the event of the interception of a signaling message, more 852 information about LSP's fast reroute protection can be deduced than 853 was previously the case. This is judged to be a very minor security 854 risk as this information is already available by other means. If a 855 MP does not find a matching bypass tunnel with given source and 856 destination addresses locally, it ignores the BYPASS_ASSIGNMENT 857 subobject. Due to this, security risk introduced by inserting a 858 random address in this subobject is minimal. The Notify message for 859 FRR Bypass Assignment Error defined in this document does not result 860 in tear-down of the protected LSP and is not service affecting. 862 Security considerations for RSVP-TE and GMPLS signaling extensions 863 are covered in [RFC3209] and [RFC3473]. Further, general 864 considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can 865 be found in [RFC5920]. This document updates the mechanisms defined 866 in [RFC4090], which also discusses related security measures and are 867 also applicable to this document. As specified in [RFC4090], a PLR 868 and its selected merge point trust RSVP messages received from each 869 other. The security considerations pertaining to the original RSVP 870 protocol [RFC2205] also remain relevant to the updates in this 871 document. 873 10. IANA Considerations 875 10.1. BYPASS_ASSIGNMENT Subobject 877 IANA manages the "RSVP PARAMETERS" registry located at 878 . IANA is requested 879 to assign a value for the new BYPASS_ASSIGNMENT subobject in the 880 "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. 882 This document introduces a new subobject for RECORD_ROUTE Object: 884 +--------+-------------------+---------+---------+---------------+ 885 | Type | Description | Carried | Carried | Reference | 886 | | | in Path | in Resv | | 887 +--------+-------------------+---------+---------+---------------+ 888 | TBA5 By| BYPASS_ASSIGNMENT | Yes | No | This document | 889 | IANA | IPv4 subobject | | | | 890 +--------+-------------------+---------+---------+---------------+ 891 | TBA6 By| BYPASS_ASSIGNMENT | Yes | No | This document | 892 | IANA | IPv6 subobject | | | | 893 +--------+-------------------+---------+---------+---------------+ 895 10.2. FRR Bypass Assignment Error Notify Message 897 IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 898 registry (see ). 899 The "Error Codes and Globally-Defined Error Value Sub-Codes" 900 subregistry is included in this registry. 902 This registry has been extended for the new Error-code and Sub-codes 903 defined in this document as follows: 905 o Error-code TBA1: FRR Bypass Assignment Error 907 o Sub-code TBA2: Bypass Assignment Cannot Be Used 908 o Sub-code TBA3: Bypass Tunnel Not Found 910 o Sub-code TBA4: One-to-one Bypass Already In-use 912 11. References 914 11.1. Normative References 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, March 1997. 919 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 920 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 921 Functional Specification", RFC 2205, September 1997. 923 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 924 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 925 Tunnels", RFC 3209, December 2001. 927 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 928 Switching (GMPLS) Signaling Resource ReserVation Protocol- 929 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 930 January 2003. 932 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 933 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 934 May 2005. 936 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 937 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 938 4561, June 2006. 940 11.2. Informative References 942 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 943 Switching (GMPLS) Signaling Functional Description", RFC 944 3471, January 2003. 946 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 947 Addresses in Generalized Multiprotocol Label Switching 948 (GMPLS) Networks", RFC 4990, September 2007. 950 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 951 Networks", RFC 5920, July 2010. 953 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 954 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 955 Protection", RFC 6378, October 2011. 957 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 958 Extensions for Associated Bidirectional LSPs", RFC 7551, 959 May 2015. 961 Acknowledgements 963 Authors would like to thank George Swallow for many useful comments 964 and suggestions. Authors would like to thank Lou Berger for the 965 guidance on this work and for providing review comments. Authors 966 would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley, 967 Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan Beeram and 968 Alia Atlas for reviewing this document and providing valuable 969 comments. A special thanks to Adrian Farrel for his thorough review 970 of this document. 972 Contributors 974 Frederic Jounay 975 Orange 976 CH 978 EMail: frederic.jounay@salt.ch 980 Lizhong Jin 981 Shanghai 982 CN 984 EMail: lizho.jin@gmail.com 986 Authors' Addresses 988 Mike Taillon 989 Cisco Systems, Inc. 991 EMail: mtaillon@cisco.com 993 Tarek Saad (editor) 994 Cisco Systems, Inc. 996 EMail: tsaad@cisco.com 998 Rakesh Gandhi (editor) 999 Cisco Systems, Inc. 1001 EMail: rgandhi@cisco.com 1003 Zafar Ali 1004 Cisco Systems, Inc. 1006 EMail: zali@cisco.com 1008 Manav Bhatia 1009 Nokia 1010 Banglore, India 1012 EMail: manav.bhatia@nokia.com