idnits 2.17.1 draft-ietf-teas-gmpls-lsp-fastreroute-11.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 3, 2017) is 2450 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: February 4, 2018 Cisco Systems, Inc. 7 M. Bhatia 8 Nokia 9 August 3, 2017 11 Updates to Resource Reservation Protocol For Fast Reroute of 12 Traffic Engineering GMPLS LSPs 13 draft-ietf-teas-gmpls-lsp-fastreroute-11 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 . . 9 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 . . . . . . . 11 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 . . . . . . . 12 82 5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 13 83 5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 13 84 5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 14 85 5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15 86 5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 15 87 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band 88 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 7. Message and Object Definitions . . . . . . . . . . . . . . . . 16 90 7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 16 91 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 18 92 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 19 96 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 11.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 Packet Switched Capable (PSC) Traffic Engineering (TE) Label Switched 107 Paths (LSPs) can be setup using Generalized Multi-Protocol Label 108 Switching (GMPLS) signaling procedures specified in [RFC3473] for 109 both unidirectional and bidirectional tunnels. The GMPLS signaling 110 allows sending and receiving the RSVP messages in-band with the data 111 traffic or out-of-band over a separate control-channel. Fast Reroute 112 (FRR) [RFC4090] has been widely deployed in the packet TE networks 113 today and is desirable for TE GMPLS LSPs. Using FRR methods also 114 allows the leveraging of the existing mechanisms for failure 115 detection and restoration in deployed networks. 117 The FRR procedures defined in [RFC4090] describe the behavior of the 118 Point of Local Repair (PLR) to reroute traffic and signaling onto the 119 bypass tunnel in the event of a failure for protected LSPs. Those 120 procedures are applicable to the unidirectional protected LSPs 121 signaled using either RSVP-TE [RFC3209] or GMPLS procedures 122 [RFC3473]. When using the FRR procedures defined in [RFC4090] with 123 co-routed bidirectional GMPLS LSPs, it is desired that same PLR and 124 Merge Point (MP) pairs are selected in each direction and both PLR 125 and MP assign the same bidirectional bypass tunnel. This document 126 updates the FRR procedures defined in [RFC4090] to coordinate the 127 bidirectional bypass tunnel assignment and to exchange MP labels 128 between upstream and downstream PLRs of the protected co-routed 129 bidirectional LSP. 131 When using FRR procedures with co-routed bidirectional GMPLS LSPs, it 132 is possible in some cases for the RSVP signaling refreshes to stop 133 reaching certain nodes along the protected LSP path after the PLRs 134 finish rerouting of the signaling messages. This can occur after a 135 failure event when using node protection bypass tunnels. As shown in 136 Figure 2, this is possible even with selecting the same bidirectional 137 bypass tunnels in both directions and the same PLR and MP pairs. 138 This is caused by the asymmetry of paths that may be taken by the 139 bidirectional LSP's signaling in the forward and reverse directions 140 due to upstream and downstream PLRs independently triggering FRR. In 141 such cases, after FRR, the RSVP soft-state timeout causes the 142 protected bidirectional LSP to be torn down, with subsequent traffic 143 loss. 145 Protection State Coordination Protocol [RFC6378] is applicable to FRR 146 [RFC4090] for local protection of co-routed bidirectional LSPs in 147 order to minimize traffic disruptions in both directions. However, 148 this does not address the above mentioned problem of RSVP soft-state 149 timeout that can occur in the control-plane. 151 This document defines a solution to the RSVP soft-state timeout issue 152 by providing mechanisms in the control-plane to complement the FRR 153 procedures of [RFC4090]. The solution allows to maintain the RSVP 154 soft-state for co-routed bidirectional protected GMPLS LSPs in the 155 control-plane and achieve co-routedness of the paths followed by the 156 traffic in the forward and reverse directions after FRR. 158 The procedures defined in this document apply to GMPLS signaled PSC 159 TE co-routed bidirectional protected LSPs and co-routed bidirectional 160 FRR bypass tunnels. Unless otherwise specified in this document, the 161 FRR procedures defined in [RFC4090] are not modified by this 162 document. The FRR mechanism for associated bidirectional GMPLS LSPs 163 where two unidirectional GMPLS LSPs are bound together by using the 164 association signaling [RFC7551] is outside the scope of this 165 document. 167 2. Conventions Used in This Document 169 2.1. Key Word Definitions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 2.2. Terminology 177 The reader is assumed to be familiar with the terminology in 178 [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090]. 180 Downstream PLR: Downstream Point of Local Repair. The PLR that 181 locally detects a failure in the downstream direction of the 182 traffic flow and reroutes traffic in the same direction of the 183 protected bidirectional LSP RSVP Path signaling. A downstream PLR 184 has a corresponding downstream MP. 186 Downstream MP: Downstream Merge Point. The LSR where one or more 187 backup tunnels rejoin the path of the protected LSP in the 188 downstream direction of the traffic flow. The same LSR can be 189 both a downstream MP and an upstream PLR simultaneously. 191 Upstream PLR: Upstream Point of Local Repair. The PLR that locally 192 detects a failure in the upstream direction of the traffic flow 193 and reroutes traffic in the opposite direction of the protected 194 bidirectional LSP RSVP Path signaling. An upstream PLR has a 195 corresponding upstream MP. 197 Upstream MP: Upstream Merge Point. The LSR where one or more backup 198 tunnels rejoin the path of the protected LSP in the upstream 199 direction of the traffic flow. The same LSR can be both an 200 upstream MP and a downstream PLR simultaneously. 202 Point of Remote Repair (PRR): A downstream MP that assumes the role 203 of upstream PLR upon receiving protected LSP's rerouted Path 204 message and triggers reroute of traffic and signaling in the 205 upstream direction of the traffic flow using the procedures 206 described in this document. 208 2.3. Abbreviations 210 GMPLS: Generalized Multi-Protocol Label Switching 212 LSP: Label Switched Path 214 LSR: Label Switching Router 216 MP: Merge Point 218 MPLS: Multi-Protocol Label Switching 220 PLR: Point of Local Repair 222 PSC: Packet Switched Capable 224 RSVP: Resource ReSerVation Protocol 226 TE: Traffic Engineering 228 3. Fast Reroute For Unidirectional GMPLS LSPs 230 The FRR procedures defined in [RFC4090] for RSVP-TE signaling 231 [RFC3209] are equally applicable to the unidirectional protected LSPs 232 signaled using GMPLS [RFC3473] and are not modified by the updates 233 defined in this document except the following. 235 When using the GMPLS out-of-band signaling [RFC3473], after a link 236 failure event, the RSVP messages are not rerouted over the bypass 237 tunnel by the downstream PLR but instead rerouted over a 238 control-channel to the downstream MP. 240 4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs 242 This section describes signaling procedures for FRR bidirectional 243 bypass tunnel assignment for GMPLS signaled PSC co-routed 244 bidirectional TE LSPs for both in-band and out-of-band signaling. 246 4.1. Bidirectional GMPLS Bypass Tunnel Direction 248 This document defines procedures where bidirectional GMPLS bypass 249 tunnels are signaled in the same direction as the protected GMPLS 250 LSPs. In other words, the bidirectional GMPLS bypass tunnels 251 originate on the downstream PLRs and terminate on the corresponding 252 downstream MPs. As the originating downstream PLR has the policy 253 information about the locally provisioned bypass tunnels, it always 254 initiates the bypass tunnel assignment. The bidirectional GMPLS 255 bypass tunnels originating from the upstream PLRs and terminating on 256 the corresponding upstream MPs are outside the scope of this 257 document. 259 4.2. Merge Point Labels 261 To correctly reroute data traffic over a node protection bypass 262 tunnel, the downstream and upstream PLRs have to know, in advance, 263 the downstream and upstream MP labels of the protected LSP so that 264 data in the forward and reverse directions can be redirected through 265 the bypass tunnel after FRR respectively. 267 [RFC4090] defines procedures for the downstream PLR to obtain the 268 protected LSP's downstream MP label from recorded labels in the 269 RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the 270 downstream PLR. 272 To obtain the upstream MP label, the procedures specified in 273 [RFC4090] are used to record the upstream MP label in the RRO of the 274 RSVP Path message of the protected LSP. The upstream PLR obtains the 275 upstream MP label from the recorded labels in the RRO of the received 276 RSVP Path message. 278 4.3. Merge Point Addresses 280 To correctly assign a bidirectional bypass tunnel, the downstream and 281 upstream PLRs have to know, in advance, the downstream and upstream 282 MP addresses. 284 [RFC4561] defines procedures for the downstream PLR to obtain the 285 protected LSP's downstream MP address from the recorded Node-IDs in 286 the RRO of the RSVP Resv message received at the downstream PLR. 288 To obtain the upstream MP address, the procedures specified in 289 [RFC4561] are used to record upstream MP Node-ID in the RRO of the 290 RSVP Path message of the protected LSP. The upstream PLR obtains the 291 upstream MP address from the recorded Node-IDs in the RRO of the 292 received RSVP Path message. 294 4.4. RRO IPv4/IPv6 Subobject Flags 296 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 297 and are equally applicable to the FRR procedure for the protected 298 bidirectional GMPLS LSPs. 300 The procedures defined in [RFC4090] are used by the downstream PLR to 301 signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP 302 Resv message of the protected LSP. Similarly, those procedures are 303 used by the downstream PLR to signal the IPv4/IPv6 subobject flags 304 downstream in the RRO of the RSVP Path message of the protected LSP. 306 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination 308 This document defines signaling procedures and a new 309 BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) 310 used to co-ordinate the bidirectional bypass tunnel assignment 311 between the downstream and upstream PLRs. 313 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure 315 It is desirable to coordinate the bidirectional bypass tunnel 316 selected at the downstream and upstream PLRs so that the rerouted 317 traffic flows on co-routed paths after FRR. To achieve this, a new 318 RSVP subobject is defined for RRO that identifies a bidirectional 319 bypass tunnel that is assigned at a downstream PLR to protect a 320 bidirectional LSP. 322 When the procedures defined in this document are in use, the 323 BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in 324 the RSVP Path RRO message of the GMPLS signaled bidirectional 325 protected LSP to record the downstream bidirectional bypass tunnel 326 assignment. This subobject is sent in the RSVP Path RRO message 327 every time the downstream PLR assigns or updates the bypass tunnel 328 assignment. The downstream PLR can assign a bypass tunnel when 329 processing the first Path message of the protected LSP, however, it 330 can not update the forwarding plane until it receives the Resv 331 message containing the downstream MP label. 333 The upstream PLR (downstream MP) simply reflects the bypass tunnel 334 assignment in the reverse direction. The absence of 335 BYPASS_ASSIGNMENT subobject in RRO means that the relevant node or 336 interface is not protected by a bidirectional bypass tunnel. Hence, 337 the upstream PLR need not assign a bypass tunnel in the reverse 338 direction. 340 When the BYPASS_ASSIGNMENT subobject is added in the RRO: 342 o The IPv4 or IPv6 subobject containing Node-ID address MUST also be 343 added [RFC4561]. The Node-ID address MUST match the source 344 address of the bypass tunnel selected for this protected LSP. 346 o The BYPASS_ASSIGNMENT subobject MUST be added immediately after 347 the Node-ID address. 349 o The Label subobject MUST also be added [RFC3209]. 351 The rules for adding an IPv4 or IPv6 Interface address subobject and 352 Unnumbered Interface ID subobject as specified in [RFC3209] and 353 [RFC4090] are not modified by the above procedure. The options 354 specified in Section 6.1.3 in [RFC4990] are also applicable as long 355 as above mentioned rules are followed when using the FRR procedures 356 defined in this document. 358 An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT 359 subobjects in the Path RRO in order to assign a reverse bypass 360 tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject, 361 selects a reverse bypass tunnel that terminates locally with the 362 destination address and tunnel-ID from the subobject, and has a 363 source address matching the Node-ID address. The RRO can contain 364 multiple addresses to identify a node, however, the upstream PLR 365 relies on the Node-ID address preceding the BYPASS_ASSIGNMENT 366 subobject for identifying the bypass tunnel. If the bypass tunnel is 367 not found, the upstream PLR SHOULD send a Notify message [RFC3473] 368 with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub- 369 code - Bypass Tunnel Not Found (value: TBA3) to the downstream PLR. 370 Upon receiving this error, the downstream PLR SHOULD remove the 371 bypass tunnel assignment and select an alternate bypass tunnel if one 372 available. The RRO containing BYPASS_ASSIGNMENT subobject(s) is then 373 simply forwarded downstream in the RSVP Path message. 375 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment 377 The bidirectional bypass tunnel assignment co-ordination procedure 378 defined in this document can be used for both facility backup 379 described in Section 3.2 of [RFC4090] and one-to-one backup described 380 in Section 3.1 of [RFC4090]. As specified in [RFC4090], Section 4.2, 381 the DETOUR_OBJECT can be used in one-to-one backup method to identify 382 the detour LSPs. In one-to-one backup method, if the bypass tunnel 383 is already in-use at the upstream PLR, it SHOULD send a Notify 384 message [RFC3473] with Error-code - FRR Bypass Assignment Error 385 (value: TBA1) and Sub-code - One-to-one Bypass Already In-use (value: 386 TBA4) to the downstream PLR. Upon receiving this error, the 387 downstream PLR SHOULD remove the bypass tunnel assignment and select 388 an alternate bypass tunnel if one available. 390 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments 392 The upstream PLR may receive multiple bypass tunnel assignments for a 393 protected LSP from different downstream PLRs. The choice of a 394 reverse bypass tunnel is based on the local policy on the upstream 395 PLR. Examples of such a policy could be to prefer link protection 396 over node protection, or to prefer the bypass tunnel to the furthest 397 upstream node. 399 As shown in Example 1 and Example 2, for the protected bidirectional 400 GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass 401 tunnel assignments, one from downstream PLR R4 for node protection 402 and one from downstream PLR R5 for link protection. In Example 1, R6 403 prefers the link protection bypass tunnel from downstream PLR R5 404 whereas in Example 2, R6 prefers the node protection bypass tunnel 405 from downstream PLR R4. 407 +------->>-------+ 408 / +->>--+ \ 409 / / \ \ 410 / / \ \ 411 [R4]--->>---[R5]--->>---[R6] 412 PATH -> \ / 413 \ / 414 +-<<--+ 416 Example 1: Link protection is preferred on downstream MP 418 +------->>--------+ 419 / +->>--+ \ 420 / / \ \ 421 / / \ \ 422 [R4]--->>---[R5]--->>---[R6] 423 \ PATH -> / 424 \ / 425 \ / 426 +-------<<--------+ 428 Example 2: Node protection is preferred on downstream MP 430 In both examples above, the upstream PLR SHOULD send a Notify message 431 [RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1) 432 and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the 433 downstream PLR to indicate that it cannot use the bypass tunnel 434 assignment in the reverse direction. Upon receiving this error, the 435 downstream PLR MAY remove the bypass tunnel assignment and select an 436 alternate bypass tunnel if one available. 438 If multiple bypass tunnel assignments are present on the upstream PLR 439 R6 at the time of a failure, any resulted asymmetry gets corrected 440 using the re-coroute procedure after FRR as specified in Section 441 5.2.2 of this document. 443 5. Fast Reroute For Bidirectional GMPLS LSPs with In-band Signaling 445 When a bidirectional bypass tunnel is used, after a link failure, 446 following procedure is followed when using the in-band signaling: 448 o The downstream PLR reroutes traffic and RSVP Path signaling over 449 the bidirectional bypass tunnel using the procedures defined in 450 [RFC4090]. 452 o Upstream PLR reroutes traffic upon detecting the link failure or 453 upon receiving RSVP Path message over the bidirectional bypass 454 tunnel. 456 o Upstream PLR also reroutes RSVP Resv signaling after receiving 457 RSVP Path message over the bidirectional bypass tunnel. 459 The above procedure allows both traffic and RSVP signaling to flow on 460 symmetric paths in the forward and reverse directions of a protected 461 bidirectional GMPLS LSP. The following sections describe the 462 handling for link protection and node protection bypass tunnels. 464 5.1. Link Protection for Bidirectional GMPLS LSPs 466 <- RESV 467 [R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6] 468 PATH -> \ / 469 \ / 470 +<<----->>+ 471 T3 472 PATH -> 473 <- RESV 475 Protected LSP: {R1-R2-R3-R4-R5-R6} 476 R3's Bypass T3: {R3-R4} 478 Figure 1: Flow of RSVP signaling after link failure and FRR 480 Consider the TE network shown in Figure 1. Assume every link in the 481 network is protected with a link protection bypass tunnel (e.g., 482 bypass tunnel T3). For the protected co-routed bidirectional LSP 483 whose head-end is on node R1 and tail-end is on node R6, each 484 traversed node (a potential PLR) assigns a link protection co-routed 485 bidirectional bypass tunnel. 487 5.1.1. Behavior After Link Failure 489 Consider the link R3-R4 on the protected LSP path fails. The 490 downstream PLR R3 and upstream PLR R4 independently trigger fast 491 reroute to redirect traffic onto bypass tunnel T3 in the forward and 492 reverse directions. The downstream PLR R3 also reroutes RSVP Path 493 messages onto the bypass tunnel T3 using the procedures described in 494 [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the 495 reverse bypass tunnel T3 upon receiving RSVP Path message over bypass 496 tunnel T3. 498 5.1.2. Revertive Behavior After Fast Reroute 500 The revertive behavior defined in [RFC4090], Section 6.5.2, is 501 applicable to the link protection of bidirectional GMPLS LSPs. When 502 using the local revertive mode, after the link R3-R4 (in Figure 1) is 503 restored, following node behaviors apply: 505 o The downstream PLR R3 starts sending the Path messages and traffic 506 flow of the protected LSP over the restored link and stops sending 507 them over the bypass tunnel. 509 o The upstream PLR R4 starts sending the traffic flow of the 510 protected LSP over the restored link and stops sending it over the 511 bypass tunnel. 513 o When upstream PLR R4 receives the protected LSP Path messages over 514 the restored link, if not already done, it starts sending Resv 515 messages and traffic flow of the protected LSP over the restored 516 link and stops sending them over the bypass tunnel. 518 5.2. Node Protection for Bidirectional GMPLS LSPs 520 T1 521 +<<------->>+ 522 / \ 523 / \ <- RESV 524 [R1]----[R2]----[R3]--x--[R4]----[R5]----[R6] 525 PATH -> \ / 526 \ / 527 +<<------->>+ 528 T2 530 Protected LSP: {R1-R2-R3-R4-R5-R6} 531 R3's Bypass T2: {R3-R5} 532 R4's Bypass T1: {R4-R2} 534 Figure 2: Flow of RSVP signaling after link failure and FRR 536 Consider the TE network shown in Figure 2. Assume every link in the 537 network is protected with a node protection bypass tunnel. For the 538 protected co-routed bidirectional LSP whose head-end is on node R1 539 and tail-end is on node R6, each traversed node (a potential PLR) 540 assigns a node protection co-routed bidirectional bypass tunnel. 542 The solution introduces two phases to invoking FRR procedures by the 543 PLR after the link failure. The first phase comprises of FRR 544 procedures to fast reroute data traffic onto bypass tunnels in the 545 forward and reverse directions. The second phase re-coroutes the 546 data and signaling in the forward and reverse directions after the 547 first phase. 549 5.2.1. Behavior After Link Failure 551 Consider a link R3-R4 (in Figure 2) on the protected LSP path fails. 552 The downstream PLR R3 and upstream PLR R4 independently trigger fast 553 reroute procedures to redirect traffic onto respective bypass tunnels 554 T2 and T1 in the forward and reverse directions. The downstream PLR 555 R3 also reroutes RSVP Path messages over the bypass tunnel T2 using 556 the procedures described in [RFC4090]. Note, at this point, node R4 557 stops receiving RSVP Path refreshes for the protected bidirectional 558 LSP while protected traffic continues to flow over bypass tunnels. 559 As node R4 does not receive Path messages, it does not reroute RSVP 560 Resv messages over the reverse bypass tunnel. 562 5.2.2. Behavior After Link Failure To Re-coroute 564 The downstream MP R5 that receives rerouted protected LSP RSVP Path 565 message through the bypass tunnel, in addition to the regular MP 566 processing defined in [RFC4090], gets promoted to a Point of Remote 567 Repair (PRR) role and performs the following actions to re-coroute 568 signaling and data traffic over the same path in the reverse 569 direction: 571 o Finds the bypass tunnel in the reverse direction that terminates 572 on the downstream PLR R3. Note: the downstream PLR R3's address 573 can be extracted from the "IPV4 tunnel sender address" in the 574 SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], 575 Section 6.1.1). 577 o If reverse bypass tunnel is found and the protected LSP traffic is 578 not already rerouted over the found bypass tunnel T2, the PRR R5 579 activates FRR reroute procedures to direct traffic over the found 580 bypass tunnel T2 in the reverse direction. In addition, the PRR 581 R5 also reroutes RSVP Resv over the bypass tunnel T2 in the 582 reverse direction. 584 o If reverse bypass tunnel is not found, the PRR R5 immediately 585 tears down the protected LSP. 587 <- RESV 588 [R1]----[R2]----[R3]--X--[R4]----[R5]----[R6] 589 PATH -> \ / 590 \ / 591 +<<------->>+ 592 Bypass Tunnel T2 593 traffic + signaling 595 Protected LSP: {R1-R2-R3-R4-R5-R6} 596 R3's Bypass T2: {R3-R5} 598 Figure 3: Flow of RSVP signaling after FRR and re-coroute 600 Figure 3 describes the path taken by the traffic and signaling after 601 completing re-coroute of data and signaling in the forward and 602 reverse paths described above. Node R4 will stop receiving the Path 603 and Resv messages and it will timeout the RSVP soft-state, however, 604 this will not cause the LSP to be torn down. RSVP signaling at node 605 R2 is not affected by the FRR and re-corouting. 607 If downstream MP R5 receives multiple RSVP Path messages through 608 multiple bypass tunnels (e.g., as a result of multiple failures), the 609 PRR SHOULD identify a bypass tunnel that terminates on the farthest 610 downstream PLR along the protected LSP path (closest to the protected 611 bidirectional LSP head-end) and activate the reroute procedures 612 mentioned above. 614 5.2.2.1. Re-coroute in Data-plane After Link Failure 616 The downstream MP (upstream PLR) MAY optionally support re-corouting 617 in data-plane as follows. If the downstream MP has assigned a 618 bidirectional bypass tunnel, as soon as the downstream MP receives 619 the protected LSP packets on the bypass tunnel, it MAY switch the 620 upstream traffic on to the bypass tunnel. In order to identify the 621 protected LSP packets through the bypass tunnel, Penultimate Hop 622 Popping (PHP) of the bypass tunnel MUST be disabled. The downstream 623 MP checks whether the protected LSP signaling is rerouted over the 624 found bypass tunnel, and if not, it performs the signaling procedure 625 described in Section 5.2.2 of this document. 627 5.2.3. Revertive Behavior After Fast Reroute 629 The revertive behavior defined in [RFC4090], Section 6.5.2, is 630 applicable to the node protection of bidirectional GMPLS LSPs. When 631 using the local revertive mode, after the link R3-R4 (in Figures 2 632 and 3) is restored, following node behaviors apply: 634 o The downstream PLR R3 starts sending the Path messages and traffic 635 flow of the protected LSP over the restored link and stops sending 636 them over the bypass tunnel. 638 o The upstream PLR R4 starts sending the traffic flow of the 639 protected LSP over the restored link towards downstream PLR R3 and 640 forwarding the Path messages towards PRR R5 and stops sending the 641 traffic over the bypass tunnel. 643 o When upstream PLR R4 receives the protected LSP Path messages over 644 the restored link, if not already done, it starts sending Resv 645 messages and traffic flow over the restored link towards 646 downstream PLR R3 and forwarding the Path messages towards PRR R5 647 and stops sending them over the bypass tunnel. 649 o When PRR R5 receives the protected LSP Path messages over the 650 restored path, it starts sending Resv messages and traffic flow 651 over the restored path and stops sending them over the bypass 652 tunnel. 654 5.3. Unidirectional Link Failures 656 Unidirectional link failures can result in the traffic flowing on 657 asymmetric paths in the forward and reverse directions. In addition, 658 unidirectional link failures can cause RSVP soft-state timeout in the 659 control-plane in some cases. As an example, if the unidirectional 660 link failure is in the upstream direction (from R4 to R3 in Figures 1 661 and 2), the downstream PLR (node R3) can stop receiving the Resv 662 messages of the protected LSP from the upstream PLR (node R4 in 663 Figures 1 and 2) and this can cause RSVP soft-state timeout to occur 664 on the downstream PLR (node R3). 666 A unidirectional link failure in the downstream direction (from R3 to 667 R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when 668 using the FRR procedures defined in this document, since the upstream 669 PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the 670 re-coroute procedure (defined in Section 5.2.2 of this document) 671 after receiving RSVP Path messages of the protected LSP over the 672 bypass tunnel from the downstream PLR (node R3 in Figures 1 and 2). 674 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling 676 When using the GMPLS out-of-band signaling [RFC3473], after a link 677 failure event, the RSVP messages are not rerouted over the 678 bidirectional bypass tunnel by the downstream and upstream PLRs but 679 instead rerouted over the control-channels to the downstream and 680 upstream MPs, respectively. 682 The RSVP soft-state timeout after FRR as described in Section 5.2 of 683 this document is equally applicable to the GMPLS out-of-band 684 signaling as the RSVP signaling refreshes can stop reaching certain 685 nodes along the protected LSP path after the downstream and upstream 686 PLRs finish rerouting of the signaling messages. However, unlike 687 with the in-band signaling, unidirectional link failures as described 688 in Section 5.3 of this document do not result in soft-state timeout 689 with GMPLS out-of-band signaling. Apart from this, the FRR procedure 690 described in Section 5 of this document is equally applicable to the 691 GMPLS out-of-band signaling. 693 7. Message and Object Definitions 695 7.1. BYPASS_ASSIGNMENT Subobject 697 The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP 698 of the bypass tunnel being assigned by the PLR. This can be used to 699 coordinate the bypass tunnel assignment for the protected LSP by the 700 downstream and upstream PLRs in the forward and reverse directions 701 respectively prior or after the failure occurrence. 703 This subobject SHOULD be inserted into the Path RRO by the downstream 704 PLR. It SHOULD NOT be inserted into an RRO by a node which is not a 705 downstream PLR. It MUST NOT be changed by downstream LSRs and MUST 706 NOT be added to a Resv RRO. 708 The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format: 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Type:TBA5 | Length | Bypass Tunnel ID | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | IPv4 Bypass Destination Address | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject 720 Type 721 Downstream Bypass Assignment. Value is TBA5 by IANA. 723 Length 725 The Length contains the total length of the subobject in bytes, 726 including the Type and Length fields. The length is 8 bytes. 728 Bypass Tunnel ID 730 The bypass tunnel identifier (16 bits). 732 Bypass Destination Address 734 The bypass tunnel IPv4 destination address. 736 The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Type:TBA6 | Length | Bypass Tunnel ID | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | | 744 + + 745 | IPv6 Bypass Destination Address | 746 + (16 bytes) + 747 | | 748 + + 749 | | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject 754 Type 756 Downstream Bypass Assignment. Value is TBA6 by IANA. 758 Length 760 The Length contains the total length of the subobject in bytes, 761 including the Type and Length fields. The length is 20 bytes. 763 Bypass Tunnel ID 765 The bypass tunnel identifier (16 bits). 767 Bypass Destination Address 768 The bypass tunnel IPv6 destination address. 770 7.2. FRR Bypass Assignment Error Notify Message 772 New Error-code - FRR Bypass Assignment Error (value: TBA1) and its 773 sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] 774 in this document, that is carried by the Notify message (Type 21) 775 defined in [RFC3473] Section 4.3. This Error message is sent by the 776 upstream PLR to the downstream PLR to notify a bypass assignment 777 error. In the Notify message, the IP destination address is set to 778 the node address of the downstream PLR that had initiated the bypass 779 assignment. In the ERROR_SPEC Object, IP address is set to the node 780 address of the upstream PLR that detected the bypass assignment 781 error. This Error MUST NOT be sent in a Path Error message. This 782 Error does not cause the protected LSP to be torn down. 784 8. Compatibility 786 New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE 787 Object in this document that is carried in the RSVP Path message. 788 Per [RFC3209], nodes not supporting this subobject will ignore the 789 subobject but forward it without modification. As described in 790 Section 7 of this document, this subobject is not carried in the RSVP 791 Resv message and is ignored by sending the Notify message for FRR 792 Bypass Assignment Error (with Subcode: Bypass Assignment Cannot Be 793 Used) defined in this document. Nodes not supporting the Notify 794 message defined in this document will ignore it but forward it 795 without modification. 797 9. Security Considerations 799 This document introduces a new BYPASS_ASSIGNMENT subobject for the 800 RECORD_ROUTE Object that is carried in an RSVP signaling message. 801 Thus in the event of the interception of a signaling message, more 802 information about LSP's fast reroute protection can be deduced than 803 was previously the case. This is judged to be a very minor security 804 risk as this information is already available by other means. If a 805 MP does not find a matching bypass tunnel with given source and 806 destination addresses locally, it ignores the BYPASS_ASSIGNMENT 807 subobject. Due to this, security risk introduced by inserting a 808 random address in this subobject is minimal. The Notify message for 809 FRR Bypass Assignment Error defined in this document does not result 810 in tear-down of the protected LSP and is not service affecting. 812 Security considerations for RSVP-TE and GMPLS signaling extensions 813 are covered in [RFC3209] and [RFC3473]. Further, general 814 considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can 815 be found in [RFC5920]. This document updates the mechanisms defined 816 in [RFC4090], which also discusses related security measures and are 817 also applicable to this document. As specified in [RFC4090], a PLR 818 and its selected merge point trust RSVP messages received from each 819 other. The security considerations pertaining to the original RSVP 820 protocol [RFC2205] also remain relevant to the updates in this 821 document. 823 10. IANA Considerations 825 10.1. BYPASS_ASSIGNMENT Subobject 827 IANA manages the "RSVP PARAMETERS" registry located at 828 . IANA is requested 829 to assign a value for the new BYPASS_ASSIGNMENT subobject in the 830 "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. 832 This document introduces a new subobject for RECORD_ROUTE Object: 834 +--------+-------------------+---------+---------+---------------+ 835 | Type | Description | Carried | Carried | Reference | 836 | | | in Path | in Resv | | 837 +--------+-------------------+---------+---------+---------------+ 838 | TBA5 By| BYPASS_ASSIGNMENT | Yes | No | This document | 839 | IANA | IPv4 subobject | | | | 840 +--------+-------------------+---------+---------+---------------+ 841 | TBA6 By| BYPASS_ASSIGNMENT | Yes | No | This document | 842 | IANA | IPv6 subobject | | | | 843 +--------+-------------------+---------+---------+---------------+ 845 10.2. FRR Bypass Assignment Error Notify Message 847 IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 848 registry (see ). 849 The "Error Codes and Globally-Defined Error Value Sub-Codes" 850 subregistry is included in this registry. 852 This registry has been extended for the new Error-code and Sub-codes 853 defined in this document as follows: 855 o Error-code TBA1: FRR Bypass Assignment Error 857 o Sub-code TBA2: Bypass Assignment Cannot Be Used 858 o Sub-code TBA3: Bypass Tunnel Not Found 860 o Sub-code TBA4: One-to-one Bypass Already In-use 862 11. References 864 11.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 870 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 871 Functional Specification", RFC 2205, September 1997. 873 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 874 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 875 Tunnels", RFC 3209, December 2001. 877 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 878 Switching (GMPLS) Signaling Resource ReserVation Protocol- 879 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 880 January 2003. 882 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 883 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 884 May 2005. 886 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 887 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 888 4561, June 2006. 890 11.2. Informative References 892 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 893 Switching (GMPLS) Signaling Functional Description", RFC 894 3471, January 2003. 896 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 897 Addresses in Generalized Multiprotocol Label Switching 898 (GMPLS) Networks", RFC 4990, September 2007. 900 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 901 Networks", RFC 5920, July 2010. 903 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 904 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 905 Protection", RFC 6378, October 2011. 907 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 908 Extensions for Associated Bidirectional LSPs", RFC 7551, 909 May 2015. 911 Acknowledgements 913 Authors would like to thank George Swallow for many useful comments 914 and suggestions. Authors would like to thank Lou Berger for the 915 guidance on this work and for providing review comments. Authors 916 would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley, 917 Himanshu Shah, Gregory Mirsky and Mach Chen for reviewing this 918 document and providing valuable comments. A special thanks to Adrian 919 Farrel for his thorough review of this document. 921 Contributors 923 Frederic Jounay 924 Orange 925 CH 927 EMail: frederic.jounay@salt.ch 929 Lizhong Jin 930 Shanghai 931 CN 933 EMail: lizho.jin@gmail.com 935 Authors' Addresses 937 Mike Taillon 938 Cisco Systems, Inc. 940 EMail: mtaillon@cisco.com 942 Tarek Saad (editor) 943 Cisco Systems, Inc. 945 EMail: tsaad@cisco.com 947 Rakesh Gandhi (editor) 948 Cisco Systems, Inc. 950 EMail: rgandhi@cisco.com 952 Zafar Ali 953 Cisco Systems, Inc. 955 EMail: zali@cisco.com 957 Manav Bhatia 958 Nokia 959 Banglore, India 961 EMail: manav.bhatia@nokia.com