idnits 2.17.1 draft-ietf-teas-gmpls-lsp-fastreroute-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (January 26, 2016) is 3011 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: July 29, 2016 Z. Ali 6 (Cisco Systems, Inc.) 7 M. Bhatia 8 L. Jin 10 January 26, 2016 12 Extensions to Resource Reservation Protocol For Fast Reroute of 13 Traffic Engineering GMPLS LSPs 14 draft-ietf-teas-gmpls-lsp-fastreroute-04 16 Abstract 18 This document defines Resource Reservation Protocol - Traffic 19 Engineering (RSVP-TE) signaling extensions to support Fast Reroute 20 (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol 21 Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling 22 extensions allow the coordination of bidirectional bypass tunnel 23 assignment protecting a common facility in both forward and reverse 24 directions of a co-routed bidirectional LSP. In addition, these 25 extensions enable the re-direction of bidirectional traffic and 26 signaling onto bypass tunnels that ensure co-routedness of data and 27 signaling paths in the forward and reverse directions after FRR to 28 avoid RSVP soft-state timeout. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 69 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 72 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 5 73 4.1. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5 74 4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6 75 4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 76 4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6 77 4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6 78 4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . 7 79 4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 8 80 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 9 81 5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10 82 5.2. Revertive Behavior Post Link Failure After FRR . . . . . . 10 83 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10 84 6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11 85 6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11 86 6.3. Revertive Behavior Post Link Failure . . . . . . . . . . . 13 87 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 10.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are 100 signaled using Generalized Multi-Protocol Label Switching (GMPLS) 101 signaling procedures specified in [RFC3473] for both unidirectional 102 and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely 103 deployed in the packet TE networks today and is preferred for TE 104 GMPLS tunnels. Using FRR methods also allows to leverage existing 105 mechanisms for failure detection and restoration in the deployed 106 networks. 108 FRR procedures defined in [RFC4090] describe the behavior of the 109 Point of Local Repair (PLR) to reroute traffic and signaling onto the 110 bypass tunnel in the event of a failure for unidirectional LSPs. 111 These procedures are applicable to unidirectional protected LSPs 112 signaled using either RSVP-TE [RFC3209] or GMPLS procedures 113 [RFC3473], however don't address issues that arise when employing FRR 114 for bidirectional co-routed GMPLS Label Switched Paths (LSPs). 116 When bidirectional bypass tunnels are used to locally protect 117 bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs 118 may independently assign different bidirectional bypass tunnels in 119 the forward and reverse directions. There is no mechanism in FRR 120 procedures defined in [RFC4090] to coordinate the bidirectional 121 bypass tunnel selection between the downstream and upstream PLRs. 123 When using FRR procedures with bidirectional co-routed GMPLS LSPs, it 124 is possible in some cases (e.g. when using node protection bypass 125 tunnels post a link failure event and when RSVP signaling is sent 126 in-fiber and in-band with data), the RSVP signaling refreshes may 127 stop reaching some nodes along the primary bidirectional LSP path 128 after the PLRs complete rerouting traffic and signaling onto the 129 bypass tunnels. This is caused by the asymmetry of paths that may be 130 taken by the bidirectional LSP's signaling in the forward and reverse 131 directions after FRR reroute. In such cases, the RSVP soft-state 132 timeout eventually causes the protected bidirectional LSP to be 133 destroyed, and consequently impacts protected traffic flow after FRR. 135 Protection State Coordination Protocol [RFC6378] is applicable to FRR 136 [RFC4090] for local protection of bidirectional co-routed LSPs in 137 order to minimize traffic disruptions in both directions. However, 138 this does not address the above mentioned problem of RSVP soft-state 139 timeout in control plane. 141 This document proposes solutions to the above mentioned problems by 142 providing mechanisms in the control plane to complement FRR 143 procedures of [RFC4090] in order to maintain the RSVP soft-state for 144 bidirectional co-routed protected GMPLS LSPs and achieve symmetry in 145 the paths followed by the traffic and signaling in the forward and 146 reverse directions post FRR. The document further extends RSVP 147 signaling so that the bidirectional bypass tunnel selected by the 148 upstream PLR matches the one selected by the downstream PLR node for 149 a bidirectional co-routed LSP. 151 Unless otherwise specified in this document, fast reroute procedures 152 defined in [RFC4090] are not modified for GMPLS signaled tunnels. 154 2. Conventions Used in This Document 156 2.1. Key Word Definitions 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 2.2. Terminology 164 The reader is assumed to be familiar with the terminology in 165 [RFC2205] and [RFC3209]. 167 LSR: An MPLS Label-Switch Router. 169 LSP: An MPLS Label-Switched Path. 171 Local Repair: Techniques used to repair LSP tunnels quickly when a 172 node or link along the LSP's path fails. 174 PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a 175 detour LSP. 177 PSC: Packet Switched Capable. 179 Protected LSP: An LSP is said to be protected at a given hop if it 180 has one or multiple associated bypass tunnels originating at that 181 hop. 183 Bypass Tunnel: An LSP that is used to protect a set of LSPs passing 184 over a common facility. 186 NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that 187 bypasses a single link of the protected LSP. 189 NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel 190 that bypasses a single node of the protected LSP. 192 MP: Merge Point. The LSR where one or more bypass tunnels rejoin the 193 path of the protected LSP downstream of the potential failure. The 194 same LSR may be both an MP and a PLR simultaneously. 196 Downstream PLR: A PLR that locally detects a fault and reroutes 197 traffic in the same direction of the protected bidirectional LSP RSVP 198 Path signaling. A downstream PLR has a corresponding downstream MP. 200 Upstream PLR: A PLR that locally detects a fault and reroutes traffic 201 in the opposite direction of the protected bidirectional LSP RSVP 202 Path signaling. An upstream PLR has a corresponding upstream MP. 204 Point of Remote Repair (PRR): An upstream PLR that triggers reroute 205 of traffic and signaling based on procedures described in this 206 document. 208 3. Fast Reroute For Unidirectional GMPLS LSPs 210 FRR procedures defined in [RFC4090] are applicable to unidirectional 211 protected LSPs signaled using either RSVP-TE or GMPLS procedures and 212 are not modified by the extensions defined in this document. These 213 FRR procedures also apply to bidirectional associated GMPLS LSPs 214 where two unidirectional GMPLS LSPs are bound together by using 215 association signaling [RFC7551]. 217 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs 219 This section describes signaling procedures for bidirectional bypass 220 tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE 221 LSPs. 223 4.1. Merge Point Labels 225 To correctly reroute data traffic over a node protection bypass 226 tunnel, the downstream and upstream PLRs have to know, in advance, 227 the downstream and upstream Merge Point (MP) labels so that data in 228 the forward and reverse directions can be tunneled through the bypass 229 tunnel post FRR respectively. 231 [RFC4090] defines procedures for the downstream PLR to obtain the 232 protected LSP's downstream MP label from recorded labels in the RRO 233 of the RSVP Resv message received at the downstream PLR. 235 To obtain the upstream MP label, existing methods [RFC4090] to record 236 upstream MP label are used in the RRO of the RSVP Path message. The 237 upstream PLR can obtain the upstream MP label from the recorded label 238 in the RRO of the received RSVP Path message. 240 4.2. Merge Point Addresses 242 To correctly assign a bidirectional bypass tunnel, the downstream and 243 upstream PLRs have to know, in advance, the downstream and upstream 244 Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR 245 to obtain the protected LSP's merge point address in multi-domain 246 routing networks where a domain is defined as an Interior Gateway 247 Protocol (IGP) area or an Autonomous System (AS). 249 [RFC4561] defines procedures for the downstream PLR to obtain the 250 protected LSP's downstream merge point address from the recorded 251 node-IDs in the RRO of the RSVP Resv message received at the 252 downstream PLR. 254 To obtain the upstream MP address, existing methods [RFC4561] to 255 record upstream MP node-ID are used in the RRO of the RSVP Path 256 message. The upstream PLR can obtain the upstream MP address from 257 the recorded node-IDs in the RRO of the received RSVP Path message. 259 4.3. RRO IPv4/IPv6 Subobject Flags 261 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 262 and are applicable to the FRR procedure for the bidirectional GMPLS 263 tunnels. 265 [RFC4090] defined procedure is used by the downstream PLR 266 independently to signal the Ipv4/IPv6 subobject flags in the RRO of 267 the RSVP Path message. Similarly, this procedure is used by the 268 upstream PLR independently to signal the IPv4/IPv6 subobject flags in 269 the RRO of the RSVP Resv message. 271 4.4. Bypass Tunnel Assignment Co-ordination 273 This document defines signaling procedure and a new BYPASS_ASSIGNMENT 274 subobject in RSVP RECORD_ROUTE object used to co-ordinate the 275 bidirectional bypass tunnel selection between the downstream and 276 upstream PLRs. 278 4.4.1. Bypass Tunnel Assignment Signaling Procedure 280 It is desirable to coordinate the bidirectional bypass tunnel 281 selected at the downstream and upstream PLRs so that rerouted traffic 282 and signaling flow on co-routed paths post FRR. To achieve this, a 283 new RSVP subobject is defined for RECORD_ROUTE object (RRO) that 284 identifies a bidirectional bypass tunnel that is assigned at a 285 downstream PLR to protect a bidirectional LSP. 287 The BYPASS_ASSIGNMENT subobject is added by each downstream PLR in 288 the RSVP Path RECORD_ROUTE message of the GMPLS signaled 289 bidirectional primary LSP to record the downstream bidirectional 290 bypass tunnel assignment. This subobject is sent in the RSVP Path 291 RECORD_ROUTE message every time the downstream PLR assigns or updates 292 the bypass tunnel assignment so the upstream PLR may reflect the 293 assignment too. 295 When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE 296 object: 298 o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node- 299 ID subobject containing the node's address. 301 o The Node-ID subobject MUST also be added. 303 o The IPv4 or IPv6 subobject MUST also be added. 305 In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR 306 SHOULD NOT assign a bypass tunnel in the reverse direction. This 307 allows the downstream PLR to always initiate the bypass assignment 308 and upstream PLR to simply reflect the bypass assignment. 310 The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT 311 subobject, whose bypass tunnel and the node-ID subobject when used as 312 a "bypass tunnel source" terminates locally, assigns the matching 313 bidirectional bypass tunnel in the reverse direction, and forwards 314 the RSVP Path message downstream. Otherwise, the bypass tunnel 315 assignment subobject is simply forwarded downstream along in the RSVP 316 Path message. 318 Bypass assignment co-ordination procedure described above can be used 319 for both one-to-one backup described in Section 3.1 of [RFC4090] and 320 facility backup described in Section 3.2 of [RFC4090]. 322 4.4.2. Bypass Tunnel Assignment Policy 324 In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT 325 subobjects from multiple downstream PLRs, the decision of selecting a 326 bypass tunnel in the reverse direction can be based on a local 327 policy, for example, prefer link protection versus node protection 328 bypass tunnel, or prefer the most upstream versus least upstream node 329 protection bypass tunnel. However, it is recommended that nodes 330 along the LSP path employ identical policy for bypass tunnel 331 assignment. 333 When different policies are used for bypass tunnel assignment on the 334 LSP path, it may result in some links in the reverse direction not 335 assigned bypass protection as shown in examples below. 337 As shown in Example 1, node A assigns a node protection bypass tunnel 338 in the forward direction but node C does not assign a node protection 339 bypass tunnel in the reverse direction for a protected bidirectional 340 GMPLS LSP. Both nodes B and C assign a link protection bypass 341 tunnel. As a result, there is no fast reroute protection available 342 in the reverse direction for link A-B for this LSP. 344 +------->>------+ 345 / +->>-+ \ 346 / / \ \ 347 / / \ \ 348 A -------- B --------- C 349 \ / 350 \ / 351 +-<<-+ 353 Example 1: An example of different bypass assignment policy 355 As shown in Example 2, nodes A and C assign a node protection bypass 356 tunnel for a protected bidirectional GMPLS LSP. Node B assigns a 357 link protection bypass tunnel but node C does not assign a reverse 358 link protection bypass tunnel. As a result, there is no fast reroute 359 protection available in the reverse direction for link A-B for this 360 LSP. 362 +------>>------+ 363 / +->>-+ \ 364 / / \ \ 365 / / \ \ 366 A -------- B --------- C 367 \ / 368 \ / 369 \ / 370 +------<<-------+ 372 Example 2: An example of different bypass assignment policy 374 4.4.3. BYPASS_ASSIGNMENT Subobject 376 The BYPASS_ASSIGNMENT subobject is used to inform the MP of the 377 bypass tunnel being assigned by the PLR. This can be used to 378 coordinate the bypass tunnel assignment for the protected LSP by the 379 downstream and upstream PLRs in the forward and reverse directions 380 respectively prior or post the failure occurrence. This subobject 381 SHOULD only be inserted into the RSVP Path message by the downstream 382 PLR and MUST NOT be changed by downstream LSRs. 384 The BYPASS_ASSIGNMENT subobject in RRO has the following format: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | Bypass Tunnel ID | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Type 394 Downstream Bypass Assignment. 396 Length 398 The Length contains the total length of the subobject in 399 bytes, including the Type and Length fields. 401 Bypass Tunnel ID 403 The bypass tunnel identifier (16 bits). 405 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs 407 When a bidirectional link protection bypass tunnel is used, after a 408 link failure, downstream PLR reroutes RSVP Path and traffic over 409 bypass tunnel using procedures defined in [RFC4090]. Upstream PLR 410 may reroute traffic and RSVP Resv upon detecting the link failure or 411 upon receiving RSVP Path message over a bidirectional bypass tunnel. 412 This allows both traffic and RSVP signaling to flow on symmetric 413 paths in the forward and reverse directions of a bidirectional 414 tunnel. 416 <-RESV 417 [R1]---[R2]----[R3]------x-----[R4]-----[R5] 418 -> PATH \ / 419 +<<-------->>+ 420 T3 421 -> PATH 422 RESV <- 424 Protected LSP: {R1-R2-R3-R4-R5} 425 R3's Bypass T3: {R3-R4} 427 Figure 1: Flow of RSVP signaling post FRR after link failure 429 Consider the Traffic Engineered (TE) network shown in Figure 1. 430 Assume every link in the network is protected with a link protection 431 bypass tunnel (e.g. bypass tunnel T3). For the protected 432 bidirectional co-routed LSP whose (active) head-end is on router R1 433 and (passive) tail-end is on router R5, each traversed router (a 434 potential PLR) assigns a link protection bidirectional co-routed 435 bypass tunnel. 437 5.1. Behavior Post Link Failure After FRR 439 Consider a link R3-R4 on the protected LSP path fails. The 440 downstream PLR R3 and upstream PLR R4 independently trigger fast 441 reroute procedures to redirect traffic onto bypass tunnels T3 in the 442 forward and reverse directions. The downstream PLR R3 also reroutes 443 RSVP Path state onto the bypass tunnel T3 using procedures described 444 in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the 445 reverse bypass tunnel T3 upon receiving RSVP Path message over bypass 446 tunnel T3. 448 5.2. Revertive Behavior Post Link Failure After FRR 450 Revertive behavior as defined in [RFC4090], Section 6.5.2, is 451 applicable to the link protection of GMPLS bidirectional LSPs. When 452 using the local revertive mode, when downstream MP receives Path 453 messages over the restored path, it starts sending Resv over the 454 restored path and stops sending Resv over the reverse bypass tunnel. 455 No additional procedure other than that specified in [RFC4090] is 456 introduced for revertive behavior by this document. 458 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs 460 T1 461 +<<--------->>+ 462 / \ <-RESV 463 [R1]---[R2]----[R3]--x--[R4]---[R5]---[R6] 464 -> PATH \ / 465 +<<--------->>+ 466 T2 468 Protected LSP: {R1-R2-R3-R4-R5-R6} 469 R3's Bypass T2: {R3-R5} 470 R4's Bypass T1: {R4-R2} 472 Figure 2: Flow of RSVP signaling post FRR after link failure 474 Consider the Traffic Engineered (TE) network shown in Figure 2. 475 Assume every link in the network is protected with a node protection 476 bypass tunnel. For the protected bidirectional co-routed LSP whose 477 (active) head-end is on router R1 and (passive) tail-end is on router 478 R6, each traversed router (a potential PLR) assigns a node protection 479 bidirectional co-routed bypass tunnel. 481 The proposed solution introduces two phases to invoking FRR 482 procedures by the PLR post the link failure. The first phase 483 comprises of FRR procedures to fast reroute data traffic onto bypass 484 tunnels in the forward and reverse directions. The second phase 485 re-coroutes the data and signaling in the forward and reverse 486 directions after the first phase. 488 6.1. Behavior Post Link Failure After FRR 490 Consider a link R3-R4 on the protected LSP path fails. The 491 downstream PLR R3 and upstream PLR R4 independently trigger fast 492 reroute procedures to redirect traffic onto respective bypass tunnels 493 T2 and T1 in the forward and reverse directions. The downstream PLR 494 R3 also reroutes RSVP Path state onto the bypass tunnel T2 using 495 procedures described in [RFC4090]. Note, at this point, router R4 496 stops receiving RSVP Path refreshes for the protected bidirectional 497 LSP while primary protected traffic continues to flow over bypass 498 tunnels. 500 6.2. Behavior Post Link Failure To Re-coroute 502 The downstream Merge Point (MP) R5 that receives rerouted protected 503 LSP RSVP Path message through the bypass tunnel, in addition to the 504 regular MP processing defined in [RFC4090], gets promoted to a Point 505 of Remote Repair (PRR role) and performs the following actions to 506 re-coroute signaling and data traffic over the same path in both 507 directions: 509 o Finds the bypass tunnel in the reverse direction 510 that terminates on the Downstream PLR R3. Note: the Downstream 511 PLR R3's address is extracted from the "IPV4 tunnel sender 512 address" in the SENDER_TEMPLATE object. 514 o If reverse bypass tunnel is found and the primary LSP traffic 515 and signaling are not already rerouted over the found bypass 516 tunnel, the PRR R5 activates FRR reroute procedures to direct 517 traffic and RSVP Resv over the found bypass tunnel T2 in the 518 reverse direction. 520 o If reverse bypass tunnel is not found, the PRR R5 signals a new 521 reverse bypass tunnel that terminates on the downstream PLR R3 522 and activates FRR reroute procedures over the new bypass tunnel 523 to direct traffic and RSVP Resv in the reverse direction. 525 o If reverse bypass tunnel can not be successfully signaled, 526 the PRR R5 immediately tears down the primary LSP. 528 If downstream MP R5 receives multiple RSVP Path messages through 529 multiple bypass tunnels (e.g. as a result of multiple failures), the 530 PRR SHOULD identify a bypass tunnel that terminates on the farthest 531 downstream PLR along the protected LSP path (closest to the primary 532 bidirectional tunnel head-end) and activate the reroute procedures 533 mentioned above. 535 <- RESV 536 [R1]---[R2]----[R3]--X--[R4]---[R5]---[R6] 537 PATH -> \ / 538 +<<------->>+ 539 Bypass Tunnel T2 540 traffic + signaling 542 Protected LSP: {R1-R2-R3-R4-R5-R6} 543 R3's Bypass T2: {R3-R5} 545 Figure 3: Flow of RSVP signaling post FRR after re-corouted 547 Figure 3 describes the path taken by the traffic and signaling after 548 completing re-coroute of data and signaling in the forward and 549 reverse paths described earlier. 551 The downstream MP MAY optionally support re-corouting in data plane 552 as follows. If the downstream MP is pre-configured with 553 bidirectional bypass tunnel, as soon as the MP node receives the 554 primary tunnel packets on this bypass tunnel, it MAY switch the 555 upstream traffic on to this bypass tunnel. In order to identify the 556 primary tunnel packets through this bypass tunnel, Penultimate Hop 557 Popping (PHP) of the bypass tunnel MUST be disabled. The signaling 558 procedure described above in this Section will still apply, and MP 559 checks whether the primary tunnel traffic and signaling is already 560 rerouted over the found bypass tunnel, if not, perform the above 561 signaling procedure. 563 6.3. Revertive Behavior Post Link Failure 565 Revertive behavior as defined in [RFC4090], Section 6.5.2, is 566 applicable to node protection of GMPLS bidirectional LSPs. When 567 using the local revertive mode, when downstream MP (R4) (before 568 re-corouting) and PRR (R5) (after re-corouting) receive Path messages 569 over the restored path, they start sending Resv over the restored 570 path and stop sending Resv over the reverse bypass tunnel. No 571 additional procedure other than that specified in [RFC4090] is 572 introduced for revertive behavior by this document. 574 7. Compatibility 576 New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE 577 Object in this document. Per [RFC2205], nodes not supporting this 578 subobject will ignore the subobject but forward it without 579 modification. 581 8. Security Considerations 583 This document introduces one new RSVP subobject that is carried in a 584 signaling message. Thus in the event of the interception of a 585 signaling message, slightly more information about the state of the 586 network could be deduced than was previously the case. This is 587 judged to be a very minor security risk as this information is 588 already available by other means. 590 Otherwise, this document introduces no additional security 591 considerations. For general discussion on MPLS and GMPLS related 592 security issues, see the MPLS/GMPLS security framework [RFC5920]. 594 9. IANA Considerations 596 IANA manages the "RSVP PARAMETERS" registry located at 597 . IANA is requested 598 to assign a value for the new BYPASS_ASSIGNMENT subobject in the 599 "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. 601 This document introduces a new RECORD_ROUTE subobject: 603 +--------+-------------------+---------+---------+---------------+ 604 | Value | Description | Carried | Carried | Reference | 605 | | | in Path | in Resv | | 606 +--------+-------------------+---------+---------+---------------+ 607 | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | 608 | IANA | subobject | | | | 609 +--------+-------------------+---------+---------+---------------+ 611 10. References 613 10.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 619 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 620 Functional Specification", RFC 2205, September 1997. 622 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 623 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 624 Tunnels", RFC 3209, December 2001. 626 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 627 Switching (GMPLS) Signaling Resource ReserVation Protocol- 628 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 629 January 2003. 631 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 632 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 633 May 2005. 635 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 636 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 637 4561, June 2006. 639 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 640 Extensions for Associated Bidirectional LSPs", RFC 7551, 641 May 2015. 643 10.2. Informative References 645 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 646 Networks", RFC 5920, July 2010. 648 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 649 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 650 Protection", RFC 6378, October 2011. 652 Acknowledgements 654 Authors would like to thank George Swallow for his detailed and 655 useful comments and suggestions. Authors would also like to thank 656 Nobo Akiya, Loa Andersson and Gregory Mirsky for reviewing this 657 document. 659 Contributors 661 Frederic Jounay 662 Orange CH 664 EMail: frederic.jounay@orange.ch 666 Authors' Addresses 668 Mike Taillon 669 Cisco Systems, Inc. 671 EMail: mtaillon@cisco.com 673 Tarek Saad (editor) 674 Cisco Systems, Inc. 676 EMail: tsaad@cisco.com 678 Rakesh Gandhi (editor) 679 Cisco Systems, Inc. 681 EMail: rgandhi@cisco.com 683 Zafar Ali 684 Cisco Systems, Inc. 686 EMail: zali@cisco.com 688 Manav Bhatia 689 India 691 EMail: manav@ionosnetworks.com 693 Lizhong Jin 694 Shanghai, China 696 EMail: lizho.jin@gmail.com