idnits 2.17.1 draft-ietf-teas-gmpls-lsp-fastreroute-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 1, 2016) is 2765 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 (==), 1 comment (--). 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 Intended Status: Standards Track R. Gandhi, Ed. 5 Expires: April 4, 2017 Z. Ali 6 Cisco Systems 7 October 1, 2016 9 Extensions to Resource Reservation Protocol For Fast Reroute of 10 Traffic Engineering GMPLS LSPs 11 draft-ietf-teas-gmpls-lsp-fastreroute-06 13 Abstract 15 This document defines Resource Reservation Protocol - Traffic 16 Engineering (RSVP-TE) signaling extensions to support Fast Reroute 17 (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol 18 Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling 19 extensions allow the coordination of a bidirectional bypass tunnel 20 assignment protecting a common facility in both forward and reverse 21 directions of a co-routed bidirectional LSP. In addition, these 22 extensions enable the re-direction of bidirectional traffic and 23 signaling onto bypass tunnels that ensure co-routedness of data and 24 signaling paths in the forward and reverse directions after FRR to 25 avoid RSVP soft-state timeout. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 5 64 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 65 4. Fast Reroute for Bidirectional GMPLS LSPs . . . . . . . . . . 5 66 4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 5 67 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6 69 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 70 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 7 71 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling 72 Procedure . . . . . . . . . . . . . . . . . . . . . . 7 73 4.5.2. Multiple Bidirectional Bypass Tunnel Assignments . . . 8 74 4.6. Fast Reroute Procedure After Link Failure . . . . . . . . 9 75 5. Link Protection for Bidirectional GMPLS LSPs . . . . . . . . . 10 76 5.1. Behavior After Link Failure . . . . . . . . . . . . . . . 10 77 5.2. Revertive Behavior After Fast Reroute . . . . . . . . . . 11 78 6. Node Protection for Bidirectional GMPLS LSPs . . . . . . . . . 11 79 6.1. Behavior After Link Failure . . . . . . . . . . . . . . . 12 80 6.2. Behavior After Link Failure To Re-coroute . . . . . . . . 12 81 6.3. Revertive Behavior After Fast Reroute . . . . . . . . . . 13 82 7. Unidirectional Link Failures . . . . . . . . . . . . . . . . . 14 83 8. Message and Object Definitions . . . . . . . . . . . . . . . . 14 84 8.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 14 85 8.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 16 86 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 11.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17 90 11.2. FRR Bypass Assignment Error Notify Message . . . . . . . 17 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 93 12.2. Informative References . . . . . . . . . . . . . . . . . 18 94 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels can be 101 setup using Generalized Multi-Protocol Label Switching (GMPLS) 102 signaling procedures specified in [RFC3473] for both unidirectional 103 and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely 104 deployed in the packet TE networks today and is desirable for TE 105 GMPLS LSPs. Using FRR methods also allows the leveraging of the 106 existing mechanisms for failure detection and restoration in deployed 107 networks. 109 The FRR procedures defined in [RFC4090] describe the behavior of the 110 Point of Local Repair (PLR) to reroute traffic and signaling onto the 111 bypass tunnel in the event of a failure for protected LSPs. Those 112 procedures are applicable to the unidirectional protected LSPs 113 signaled using either RSVP-TE [RFC3209] or GMPLS procedures 114 [RFC3473]. When using the FRR procedures defined in [RFC4090] with 115 co-routed bidirectional GMPLS LSPs, it is desired that same PLR and 116 Merge Point (MP) pairs are selected in each direction and both PLR 117 and MP assign the same bidirectional bypass tunnel. This document 118 extends the FRR procedures defined in [RFC4090] to coordinate the 119 bidirectional bypass tunnel assignment and to exchange MP labels 120 between upstream and downstream PLRs of the protected co-routed 121 bidirectional LSP. 123 When using FRR procedures with co-routed bidirectional GMPLS LSPs, it 124 is possible in some cases for the RSVP signaling refreshes to stop 125 reaching certain nodes along the protected LSP path after the PLRs 126 finish rerouting signaling onto the bypass tunnels. This can occur 127 after a failure event when using node protection bypass tunnels and 128 when RSVP signaling is sent in-band with data. As shown in Figure 2, 129 this is possible even with selecting the same bidirectional bypass 130 tunnels in both directions and the same PLR and MP pairs. This is 131 caused by the asymmetry of paths that may be taken by the 132 bidirectional LSP's signaling in the forward and reverse directions 133 due to upstream and downstream PLRs independently triggering FRR. In 134 such cases, after FRR, the RSVP soft-state timeout causes the 135 protected bidirectional LSP to be torn down, with subsequent traffic 136 loss. 138 Protection State Coordination Protocol [RFC6378] is applicable to FRR 139 [RFC4090] for local protection of co-routed bidirectional LSPs in 140 order to minimize traffic disruptions in both directions. However, 141 this does not address the above mentioned problem of RSVP soft-state 142 timeout in control plane. 144 This document proposes a solution to the RSVP soft-state timeout 145 issue by providing mechanisms in the control plane to complement the 146 FRR procedures of [RFC4090]. The proposal allows to maintain the 147 RSVP soft-state for co-routed bidirectional protected GMPLS LSPs and 148 achieve co-routedness of the paths followed by the traffic and 149 signaling in the forward and reverse directions after FRR. 151 Procedures defined in this document apply to GMPLS signaled PSC TE 152 co-routed bidirectional protected LSPs and FRR co-routed 153 bidirectional bypass tunnels. Unless otherwise specified in this 154 document, the FRR procedures defined in [RFC4090] are not modified by 155 this document. FRR mechanism for associated bidirectional GMPLS LSPs 156 where two unidirectional GMPLS LSPs are bound together by using 157 association signaling [RFC7551] is outside the scope of this 158 document. 160 2. Conventions Used in This Document 162 2.1. Key Word Definitions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 2.2. Terminology 170 The reader is assumed to be familiar with the terminology in 171 [RFC2205], [RFC3209], [RFC3471], [RFC3473] and [RFC4090]. 173 Downstream PLR: Downstream Point of Local Repair. The PLR that 174 locally detects a failure in the downstream direction of the traffic 175 flow and reroutes traffic in the same direction of the protected 176 bidirectional LSP RSVP Path signaling. A downstream PLR has a 177 corresponding downstream MP. 179 Downstream MP: Downstream Merge Point. The LSR where one or more 180 backup tunnels rejoin the path of the protected LSP in the downstream 181 direction of the traffic flow. The same LSR may be both a downstream 182 MP and an upstream PLR simultaneously. 184 Upstream PLR: Upstream Point of Local Repair. The PLR that locally 185 detects a failure in the upstream direction of the traffic flow and 186 reroutes traffic in the opposite direction of the protected 187 bidirectional LSP RSVP Path signaling. An upstream PLR has a 188 corresponding upstream MP. 190 Upstream MP: Upstream Merge Point. The LSR where one or more backup 191 tunnels rejoin the path of the protected LSP in the upstream 192 direction of the traffic flow. The same LSR may be both an upstream 193 MP and a downstream PLR simultaneously. 195 Point of Remote Repair (PRR): A downstream MP that assumes the role 196 of upstream PLR upon receiving protected LSP's Path message over the 197 bypass tunnel and triggers reroute of traffic and signaling in the 198 upstream direction of the traffic flow using the procedures described 199 in this document. 201 2.3. Acronyms and Abbreviations 203 GMPLS: Generalized Multi-Protocol Label Switching 205 LSP: An MPLS Label Switched Path 207 LSR: An MPLS Label Switching Router 209 MP: Merge Point 211 MPLS: Multi-Protocol Label Switching 213 PLR: Point of Local Repair 215 PSC: Packet Switched Capable 217 RSVP: Resource ReSerVation Protocol 219 TE: Traffic Engineering 221 3. Fast Reroute For Unidirectional GMPLS LSPs 223 The FRR procedures defined in [RFC4090] are applicable to 224 unidirectional protected LSPs signaled using either RSVP-TE or GMPLS 225 procedures and are not modified by the extensions defined in this 226 document. 228 4. Fast Reroute for Bidirectional GMPLS LSPs 230 This section describes signaling procedures for FRR bidirectional 231 bypass tunnel assignment for GMPLS signaled PSC co-routed 232 bidirectional TE LSPs. 234 4.1. Bidirectional GMPLS Bypass Tunnel Direction 236 This document defines procedures where bidirectional GMPLS bypass 237 tunnels are signaled in the same direction as the protected GMPLS 238 LSPs. In other words, the bidirectional GMPLS bypass tunnels 239 originate on the downstream PLR and terminate on the downstream MP. 240 As the originating downstream PLR has the policy information about 241 the locally provisioned bypass tunnels, it always initiates the 242 bypass tunnel assignment. The bidirectional GMPLS bypass tunnels 243 originating from the upstream PLR and terminating on the upstream MP 244 are outside the scope of this document. 246 4.2. Merge Point Labels 248 To correctly reroute data traffic over a node protection bypass 249 tunnel, the downstream and upstream PLRs have to know, in advance, 250 the downstream and upstream MP labels of the protected LSP so that 251 data in the forward and reverse directions can be redirected through 252 the bypass tunnel after FRR respectively. 254 [RFC4090] defines procedures for the downstream PLR to obtain the 255 protected LSP's downstream MP label from recorded labels in the 256 RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the 257 downstream PLR. 259 To obtain the upstream MP label, the procedures specified in 260 [RFC4090] are used to record the upstream MP label in the RRO of the 261 RSVP Path message of the protected LSP. The upstream PLR obtains the 262 upstream MP label from the recorded labels in the RRO of the received 263 RSVP Path message. 265 4.3. Merge Point Addresses 267 To correctly assign a bidirectional bypass tunnel, the downstream and 268 upstream PLRs have to know, in advance, the downstream and upstream 269 MP addresses. 271 [RFC4561] defines procedures for the downstream PLR to obtain the 272 protected LSP's downstream MP address from the recorded Node-IDs in 273 the RRO of the RSVP Resv message received at the downstream PLR. 275 To obtain the upstream MP address, the procedures specified in 276 [RFC4561] are used to record upstream MP Node-ID in the RRO of the 277 RSVP Path message of the protected LSP. The upstream PLR obtains the 278 upstream MP address from the recorded Node-IDs in the RRO of the 279 received RSVP Path message. 281 4.4. RRO IPv4/IPv6 Subobject Flags 283 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 284 and are equally applicable to the FRR procedure for bidirectional 285 GMPLS LSPs. 287 The procedures defined in [RFC4090] are used by the downstream PLR to 288 signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP 289 Resv message of the protected LSP. Similarly, those procedures are 290 used by the downstream PLR to signal the IPv4/IPv6 subobject flags 291 downstream in the RRO of the RSVP Path message of the protected LSP. 293 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination 295 This document defines signaling procedures and a new 296 BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) 297 used to co-ordinate the bidirectional bypass tunnel assignment 298 between the downstream and upstream PLRs. 300 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure 302 It is desirable to coordinate the bidirectional bypass tunnel 303 selected at the downstream and upstream PLRs so that rerouted traffic 304 and signaling flow on co-routed paths after FRR. To achieve this, a 305 new RSVP subobject is defined for RRO that identifies a bidirectional 306 bypass tunnel that is assigned at a downstream PLR to protect a 307 bidirectional LSP. 309 When the procedures defined in this document are in use, the 310 BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in 311 the RSVP Path RRO message of the GMPLS signaled bidirectional 312 protected LSP to record the downstream bidirectional bypass tunnel 313 assignment. This subobject is sent in the RSVP Path RRO message 314 every time the downstream PLR assigns or updates the bypass tunnel 315 assignment. The downstream PLR can assign a bypass tunnel when 316 processing the first Path message of the protected LSP, however, it 317 can not update the forwarding plane until it receives the Resv 318 message containing the downstream MP label. 320 The upstream PLR (downstream MP) simply reflects the bypass tunnel 321 assignment in the reverse direction. The absence of 322 BYPASS_ASSIGNMENT subobject in RRO means that the relevant node or 323 interface is not protected by a bidirectional bypass tunnel. Hence, 324 the upstream PLR need not assign a bypass tunnel in the reverse 325 direction. 327 When the BYPASS_ASSIGNMENT subobject is added in the RRO: 329 o The IPv4 or IPv6 subobject containing Node-ID address MUST also be 330 added [RFC4561]. The Node-ID address must match the source 331 address of the bypass tunnel selected for this protected LSP. 333 o The BYPASS_ASSIGNMENT subobject MUST be added immediately after 334 the Node-ID address. 336 o The Label subobject MUST also be added [RFC3209]. 338 The rules for adding an IPv4 or IPv6 Interface address subobject and 339 Unnumbered Interface ID subobject as specified in [RFC3209] and 340 [RFC4090] are not modified by the above procedure. The options 341 specified in Section 6.1.3 in [RFC4990] are also applicable as long 342 as above mentioned rules are followed when using the FRR procedures 343 defined in this document. 345 An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT 346 subobjects in the Path RRO in order to assign a reverse bypass 347 tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject, 348 selects a reverse bypass tunnel that terminates locally with the 349 destination address and tunnel-ID from the subobject, and has a 350 source address matching the Node-ID address. The RRO may contain 351 multiple addresses to identify a node, however, the upstream PLR 352 relies on the Node-ID address preceding the BYPASS_ASSIGNMENT 353 subobject for identifying the bypass tunnel. If the bypass tunnel is 354 not found, the upstream PLR SHOULD send a Notify message [RFC3473] 355 with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub- 356 code - Bypass Tunnel Not Found (value: TBA3) to the downstream PLR. 357 The RRO containing BYPASS_ASSIGNMENT subobject(s) is then simply 358 forwarded downstream in the RSVP Path message. 360 The bypass assignment co-ordination procedure described in this 361 Section can be used for both facility backup described in Section 3.2 362 of [RFC4090] and one-to-one backup described in Section 3.1 of 363 [RFC4090]. As specified in [RFC4090], Section 4.2, the DETOUR_OBJECT 364 can be used in one-to-one backup method to identify detour LSPs. In 365 one-to-one backup method, if the bypass tunnel is already in-use at 366 the upstream PLR, it SHOULD send a Notify message [RFC3473] with 367 Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub-code - 368 One-to-one Bypass Already In-use (value: TBA4) to the downstream 369 PLR. 371 4.5.2. Multiple Bidirectional Bypass Tunnel Assignments 373 The upstream PLR may receive multiple bypass tunnel assignments for a 374 protected LSP from different downstream PLRs. The choice of a 375 reverse bypass tunnel is based on the local policy on the upstream 376 PLR. Examples of such a policy could be to prefer link protection 377 over node protection, or to prefer the bypass tunnel to the furthest 378 upstream node. 380 As shown in Example 1 and Example 2, for the protected bidirectional 381 GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass 382 tunnel assignments, one from downstream PLR R4 for node protection 383 and one from downstream PLR R5 for link protection. In Example 1, R6 384 prefers the link protection bypass tunnel from downstream PLR R5 385 whereas in Example 2, R6 prefers the node protection bypass tunnel 386 from downstream PLR R4. 388 +------->>-------+ 389 / +->>--+ \ 390 / / \ \ 391 / / \ \ 392 [R4]--->>---[R5]--->>---[R6] 393 PATH -> \ / 394 \ / 395 +-<<--+ 397 Example 1: Link protection is preferred on downstream MP 399 +------->>--------+ 400 / +->>--+ \ 401 / / \ \ 402 / / \ \ 403 [R4]--->>---[R5]--->>---[R6] 404 \ PATH -> / 405 \ / 406 \ / 407 +-------<<--------+ 409 Example 2: Node protection is preferred on downstream MP 411 In both examples above, the upstream PLR SHOULD send a Notify message 412 [RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1) 413 and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the 414 downstream PLR to indicate that it cannot use the bypass tunnel 415 assignment. The upstream PLR can then remove the bypass assignment 416 and select an alternate bypass tunnel. 418 If multiple bypass tunnel assignments are present on the upstream PLR 419 R6 at the time of a failure, any resulted asymmetry gets corrected 420 using the re-coroute procedure after FRR as specified in Section 6.2 421 of this document. 423 4.6. Fast Reroute Procedure After Link Failure 424 When a bidirectional bypass tunnel is used, after a link failure, 425 following procedure is followed: 427 o The downstream PLR reroutes traffic and RSVP Path signaling over 428 the bidirectional bypass tunnel using the procedures defined in 429 [RFC4090]. 431 o Upstream PLR reroutes traffic upon detecting the link failure or 432 upon receiving RSVP Path message over the bidirectional bypass 433 tunnel. 435 o Upstream PLR also reroutes RSVP Resv signaling after receiving 436 RSVP Path message over the bidirectional bypass tunnel. 438 This procedure allows both traffic and RSVP signaling to flow on 439 symmetric paths in the forward and reverse directions of a protected 440 bidirectional GMPLS LSP. This is described in Section 5 for link 441 protection bypass tunnels and Section 6 for node protection bypass 442 tunnels. 444 5. Link Protection for Bidirectional GMPLS LSPs 446 <- RESV 447 [R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6] 448 PATH -> \ / 449 \ / 450 +<<----->>+ 451 T3 452 PATH -> 453 <- RESV 455 Protected LSP: {R1-R2-R3-R4-R5-R6} 456 R3's Bypass T3: {R3-R4} 458 Figure 1: Flow of RSVP signaling after link failure and FRR 460 Consider the TE network shown in Figure 1. Assume every link in the 461 network is protected with a link protection bypass tunnel (e.g. 462 bypass tunnel T3). For the protected co-routed bidirectional LSP 463 whose head-end is on node R1 and tail-end is on node R6, each 464 traversed node (a potential PLR) assigns a link protection co-routed 465 bidirectional bypass tunnel. 467 5.1. Behavior After Link Failure 469 Consider the link R3-R4 on the protected LSP path fails. The 470 downstream PLR R3 and upstream PLR R4 independently trigger fast 471 reroute to redirect traffic onto bypass tunnels T3 in the forward and 472 reverse directions. The downstream PLR R3 also reroutes RSVP Path 473 messages onto the bypass tunnel T3 using the procedures described in 474 [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the 475 reverse bypass tunnel T3 upon receiving RSVP Path message over bypass 476 tunnel T3. 478 5.2. Revertive Behavior After Fast Reroute 480 Revertive behavior as defined in [RFC4090], Section 6.5.2, is 481 applicable to the link protection of bidirectional GMPLS LSPs. When 482 using the local revertive mode, after the link R3-R4 is restored, 483 following node behaviors apply: 485 o The downstream PLR R3 starts sending the Path messages and traffic 486 flow of the protected LSP over the restored link and stops sending 487 them over the bypass tunnel. 489 o The upstream PLR R4 starts sending the Resv messages and traffic 490 flow of the protected LSP over the restored link and stops sending 491 them over the bypass tunnel. 493 o When upstream PLR R4 receives the protected LSP Path messages over 494 the restored link, if not already done, it starts sending Resv 495 messages and traffic flow of the protected LSP over the restored 496 link and stops sending them over the bypass tunnel. 498 6. Node Protection for Bidirectional GMPLS LSPs 500 T1 501 +<<------->>+ 502 / \ 503 / \ <- RESV 504 [R1]----[R2]----[R3]--x--[R4]----[R5]----[R6] 505 PATH -> \ / 506 \ / 507 +<<------->>+ 508 T2 510 Protected LSP: {R1-R2-R3-R4-R5-R6} 511 R3's Bypass T2: {R3-R5} 512 R4's Bypass T1: {R4-R2} 514 Figure 2: Flow of RSVP signaling after link failure and FRR 516 Consider the TE network shown in Figure 2. Assume every link in the 517 network is protected with a node protection bypass tunnel. For the 518 protected co-routed bidirectional LSP whose head-end is on node R1 519 and tail-end is on node R6, each traversed node (a potential PLR) 520 assigns a node protection co-routed bidirectional bypass tunnel. 522 The proposed solution introduces two phases to invoking FRR 523 procedures by the PLR after the link failure. The first phase 524 comprises of FRR procedures to fast reroute data traffic onto bypass 525 tunnels in the forward and reverse directions. The second phase 526 re-coroutes the data and signaling in the forward and reverse 527 directions after the first phase. 529 6.1. Behavior After Link Failure 531 Consider a link R3-R4 on the protected LSP path fails. The 532 downstream PLR R3 and upstream PLR R4 independently trigger fast 533 reroute procedures to redirect traffic onto respective bypass tunnels 534 T2 and T1 in the forward and reverse directions. The downstream PLR 535 R3 also reroutes RSVP Path messages over the bypass tunnel T2 using 536 the procedures described in [RFC4090]. Note, at this point, node R4 537 stops receiving RSVP Path refreshes for the protected bidirectional 538 LSP while protected traffic continues to flow over bypass tunnels. 539 As node R4 does not receive Path messages over the bypass tunnel, it 540 does not reroute RSVP Resv messages over the reverse bypass tunnel. 542 6.2. Behavior After Link Failure To Re-coroute 544 The downstream MP R5 that receives rerouted protected LSP RSVP Path 545 message through the bypass tunnel, in addition to the regular MP 546 processing defined in [RFC4090], gets promoted to a Point of Remote 547 Repair (PRR) role and performs the following actions to re-coroute 548 signaling and data traffic over the same path in the reverse 549 direction: 551 o Finds the bypass tunnel in the reverse direction that terminates 552 on the downstream PLR R3. Note: the downstream PLR R3's address 553 can be extracted from the "IPV4 tunnel sender address" in the 554 SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], 555 Section 6.1.1). 557 o If reverse bypass tunnel is found and the protected LSP traffic is 558 not already rerouted over the found bypass tunnel T2, the PRR R5 559 activates FRR reroute procedures to direct traffic over the found 560 bypass tunnel T2 in the reverse direction. In addition, the PRR 561 R5 also reroutes RSVP Resv over the bypass tunnel T2 in the 562 reverse direction. 564 o If reverse bypass tunnel is not found, the PRR R5 immediately 565 tears down the protected LSP. 567 <- RESV 568 [R1]----[R2]----[R3]--X--[R4]----[R5]----[R6] 569 PATH -> \ / 570 \ / 571 +<<------->>+ 572 Bypass Tunnel T2 573 traffic + signaling 575 Protected LSP: {R1-R2-R3-R4-R5-R6} 576 R3's Bypass T2: {R3-R5} 578 Figure 3: Flow of RSVP signaling after FRR and re-coroute 580 Figure 3 describes the path taken by the traffic and signaling after 581 completing re-coroute of data and signaling in the forward and 582 reverse paths described above. Node R4 will stop receiving the Path 583 and Resv messages and it will timeout the RSVP soft-state, however, 584 this will not cause the LSP to be torn down. RSVP signaling at node 585 R2 is not affected by the FRR and re-corouting. 587 If downstream MP R5 receives multiple RSVP Path messages through 588 multiple bypass tunnels (e.g. as a result of multiple failures), the 589 PRR SHOULD identify a bypass tunnel that terminates on the farthest 590 downstream PLR along the protected LSP path (closest to the protected 591 bidirectional LSP head-end) and activate the reroute procedures 592 mentioned above. 594 The downstream MP (upstream PLR) MAY optionally support re-corouting 595 in data plane as follows. If the downstream MP is pre-configured 596 with bidirectional bypass tunnel, as soon as the downstream MP 597 receives the protected LSP packets on this bypass tunnel, it MAY 598 switch the upstream traffic on to this bypass tunnel. In order to 599 identify the protected LSP packets through this bypass tunnel, 600 Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled. 601 The signaling procedure described above in this Section will still 602 apply, and downstream MP checks whether the protected LSP traffic and 603 signaling is already rerouted over the found bypass tunnel, if not, 604 perform the above signaling procedure. 606 6.3. Revertive Behavior After Fast Reroute 608 Revertive behavior as defined in [RFC4090], Section 6.5.2, is 609 applicable to the node protection of bidirectional GMPLS LSPs. When 610 using the local revertive mode, after the link R3-R4 is restored, 611 following node behaviors apply: 613 o The downstream PLR R3 starts sending the Path messages and traffic 614 flow of the protected LSP over the restored link and stops sending 615 them over the bypass tunnel. 617 o The upstream PLR R4 starts sending the Resv messages and traffic 618 flow of the protected LSP over the restored link towards 619 downstream PLR R3 and forwarding the Path messages towards PRR R5 620 and stops sending them over the bypass tunnel. 622 o When upstream PLR R4 receives the protected LSP Path messages over 623 the restored link, if not already done, it starts sending Resv 624 messages and traffic flow over the restored link towards 625 downstream PLR R3 and forwarding the Path messages towards PRR R5 626 and stops sending them over the bypass tunnel. 628 o When PRR R5 receives the protected LSP Path messages over the 629 restored path, it starts sending Resv messages and traffic flow 630 over the restored path and stops sending them over the bypass 631 tunnel. 633 7. Unidirectional Link Failures 635 Unidirectional link failures may result in the traffic flowing on 636 asymmetric paths in the forward and reverse directions. In addition, 637 unidirectional link failures may cause RSVP soft-state timeout in the 638 control-plane in some cases. As an example, if the unidirectional 639 link failure is in the upstream direction (from R4 to R3 in Figures 1 640 and 2), the downstream PLR (node R3) can stop receiving the Resv 641 messages of the protected LSP from the upstream PLR (node R4 in 642 Figures 1 and 2) and this can cause RSVP soft-state timeout to occur 643 on the downstream PLR (node R3). 645 A unidirectional link failure in the downstream direction (from R3 to 646 R4 in Figure 1 and 2), does not cause RSVP soft-state timeout when 647 using the FRR procedures defined in this document, since the upstream 648 PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the 649 re-coroute procedure (defined in Section 6.2 of this document) after 650 receiving RSVP Path messages of the protected LSP over the bypass 651 tunnel from the downstream PLR (node R3 in Figures 1 and 2). 653 8. Message and Object Definitions 655 8.1. BYPASS_ASSIGNMENT Subobject 656 The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP 657 of the bypass tunnel being assigned by the PLR. This can be used to 658 coordinate the bypass tunnel assignment for the protected LSP by the 659 downstream and upstream PLRs in the forward and reverse directions 660 respectively prior or after the failure occurrence. 662 This subobject SHOULD be inserted into the Path RRO by the downstream 663 PLR. It SHOULD NOT be inserted into an RRO by a node which is not a 664 downstream PLR. It MUST NOT be changed by downstream LSRs and MUST 665 NOT be added to a Resv RRO. 667 The BYPASS_ASSIGNMENT subobject in RRO has the following format: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type:TBA | Length | Bypass Tunnel ID | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | IPv4 Bypass Destination Address | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type:TBA | Length | Bypass Tunnel ID | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | | 685 + + 686 | IPv6 Bypass Destination Address | 687 + (16 bytes) + 688 | | 689 + + 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject 695 Type 697 Downstream Bypass Assignment. Value is TBA by IANA. 699 Length 700 The Length contains the total length of the subobject in 701 bytes, including the Type and Length fields. The length is 8 bytes 702 with IPv4 address and 20 bytes with IPv6 object. 704 Bypass Tunnel ID 706 The bypass tunnel identifier (16 bits). 708 Bypass Destination Address 710 The bypass tunnel IPv4 or IPv6 destination address. 712 8.2. FRR Bypass Assignment Error Notify Message 714 New Error-code - FRR Bypass Assignment Error (value: TBA1) and its 715 sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] 716 in this document, that is carried by the Notify message (Type 21) 717 defined in [RFC3473] Section 4.3. This Error is sent by the upstream 718 PLR to the downstream PLR to notify a bypass assignment error. In 719 the Notify message, the IP destination address is set to the node 720 address of the downstream PLR that had initiated the bypass 721 assignment. In the ERROR_SPEC Object, IP address is set to the node 722 address of the upstream PLR that detected the bypass assignment 723 error. This Error MUST NOT be sent in a Path Error message. This 724 Error does not cause protected LSP to be torn down. 726 9. Compatibility 728 New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE 729 Object in this document that is carried in the RSVP Path message. 730 Per [RFC3209], nodes not supporting this subobject will ignore the 731 subobject but forward it without modification. As described in 732 Section 8, this subobject is not carried in the RSVP Resv message. A 733 new Notify message for FRR Bypass Assignment Error is defined in this 734 document. Nodes not supporting this message will ignore it but 735 forward it without modification. 737 10. Security Considerations 739 This document introduces a new BYPASS_ASSIGNMENT subobject for the 740 RECORD_ROUTE Object that is carried in an RSVP signaling message. 741 Thus in the event of the interception of a signaling message, more 742 information about LSP's fast reroute protection can be deduced than 743 was previously the case. This is judged to be a very minor security 744 risk as this information is already available by other means. 746 Otherwise, this document introduces no additional security 747 considerations. For general discussion on MPLS and GMPLS related 748 security issues, see the MPLS/GMPLS security framework [RFC5920]. 750 11. IANA Considerations 752 11.1. BYPASS_ASSIGNMENT Subobject 754 IANA manages the "RSVP PARAMETERS" registry located at 755 . IANA is requested 756 to assign a value for the new BYPASS_ASSIGNMENT subobject in the 757 "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. 759 This document introduces a new subobject for RECORD_ROUTE Object: 761 +--------+-------------------+---------+---------+---------------+ 762 | Type | Description | Carried | Carried | Reference | 763 | | | in Path | in Resv | | 764 +--------+-------------------+---------+---------+---------------+ 765 | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | 766 | IANA | IPv4 subobject | | | | 767 +--------+-------------------+---------+---------+---------------+ 768 | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | 769 | IANA | IPv6 subobject | | | | 770 +--------+-------------------+---------+---------+---------------+ 772 11.2. FRR Bypass Assignment Error Notify Message 774 IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 775 registry (see ). 776 The "Error Codes and Globally-Defined Error Value Sub-Codes" 777 subregistry is included in this registry. 779 This registry has been extended for the new Error-code and Sub-codes 780 defined in this document as follows: 782 o Error-code TBA1: FRR Bypass Assignment Error 784 o Sub-code TBA2: Bypass Assignment Cannot Be Used 786 o Sub-code TBA3: Bypass Tunnel Not Found 788 o Sub-code TBA4: One-to-one Bypass Already In-use 790 12. References 792 12.1. Normative References 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, March 1997. 797 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 798 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 799 Functional Specification", RFC 2205, September 1997. 801 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 802 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 803 Tunnels", RFC 3209, December 2001. 805 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 806 Switching (GMPLS) Signaling Resource ReserVation Protocol- 807 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 808 January 2003. 810 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 811 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 812 May 2005. 814 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 815 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 816 4561, June 2006. 818 12.2. Informative References 820 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 821 Switching (GMPLS) Signaling Functional Description", RFC 822 3471, January 2003. 824 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 825 Addresses in Generalized Multiprotocol Label Switching 826 (GMPLS) Networks", RFC 4990, September 2007. 828 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 829 Networks", RFC 5920, July 2010. 831 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 832 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 833 Protection", RFC 6378, October 2011. 835 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 836 Extensions for Associated Bidirectional LSPs", RFC 7551, 837 May 2015. 839 Acknowledgements 841 Authors would like to thank George Swallow for his detailed and 842 useful comments and suggestions. Authors would also like to thank 843 Nobo Akiya, Loa Andersson, Matt Hartley and Gregory Mirsky for 844 reviewing this document. A special thanks to Adrian Farrel for his 845 thorough review of this document. 847 Contributors 849 Frederic Jounay 850 Orange CH 852 EMail: frederic.jounay@salt.ch 854 Manav Bhatia 855 Nokia 856 Banglore, India 858 EMail: manav.bhatia@nokia.com 860 Lizhong Jin 861 Shanghai, China 863 EMail: lizho.jin@gmail.com 865 Authors' Addresses 867 Mike Taillon 868 Cisco Systems, Inc. 870 EMail: mtaillon@cisco.com 872 Tarek Saad (editor) 873 Cisco Systems, Inc. 875 EMail: tsaad@cisco.com 877 Rakesh Gandhi (editor) 878 Cisco Systems, Inc. 880 EMail: rgandhi@cisco.com 882 Zafar Ali 883 Cisco Systems, Inc. 885 EMail: zali@cisco.com