idnits 2.17.1 draft-ietf-teas-gmpls-lsp-fastreroute-02.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, 2015) is 3376 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BID-ASSOC' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Mike Taillon 3 Internet-Draft Tarek Saad, Ed. 4 Intended Status: Standards Track Rakesh Gandhi, Ed. 5 Expires: July 30, 2015 Zafar Ali 6 (Cisco Systems, Inc.) 7 Manav Bhatia 8 Lizhong Jin 10 January 26, 2015 12 Extensions to Resource Reservation Protocol For Fast Reroute of 13 Traffic Engineering GMPLS LSPs 14 draft-ietf-teas-gmpls-lsp-fastreroute-02 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) 2015 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 70 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 5 71 4.1. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5 72 4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . 5 73 4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 74 4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6 75 4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6 76 4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . 7 77 4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 8 78 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 9 79 5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10 80 5.2. Revertive Behavior Post Link Failure After FRR . . . . . . 10 81 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10 82 6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11 83 6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11 84 6.3. Revertive Behavior Post Link Failure . . . . . . . . . . . 12 85 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 12.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are 98 signaled using Generalized Multi-Protocol Label Switching (GMPLS) 99 signaling procedures specified in [RFC3473] for both unidirectional 100 and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely 101 deployed in the packet TE networks today and is preferred for TE 102 GMPLS tunnels. Using FRR methods also allows to leverage existing 103 mechanisms for failure detection and restoration in the deployed 104 networks. 106 FRR procedures defined in [RFC4090] describe the behavior of the 107 Point of Local Repair (PLR) to reroute traffic and signaling onto the 108 bypass tunnel in the event of a failure for unidirectional LSPs. 109 These procedures are applicable to unidirectional protected LSPs 110 signaled using either RSVP-TE [RFC3209] or GMPLS procedures 111 [RFC3473], however don't address issues that arise when employing FRR 112 for bidirectional co-routed GMPLS Label Switched Paths (LSPs). 114 When bidirectional bypass tunnels are used to locally protect 115 bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs 116 may independently assign different bidirectional bypass tunnels in 117 the forward and reverse directions. There is no mechanism in FRR 118 procedures defined in [RFC4090] to coordinate the bidirectional 119 bypass tunnel selection between the downstream and upstream PLRs. 121 When using FRR procedures with bidirectional co-routed GMPLS LSPs, it 122 is possible in some cases (e.g. when using node protection bypass 123 tunnels post a link failure event and when RSVP signaling is sent 124 in-fiber and in-band with data), the RSVP signaling refreshes may 125 stop reaching some nodes along the primary bidirectional LSP path 126 after the PLRs complete rerouting traffic and signaling onto the 127 bypass tunnels. This is caused by the asymmetry of paths that may be 128 taken by the bidirectional LSP's signaling in the forward and reverse 129 directions after FRR reroute. In such cases, the RSVP soft-state 130 timeout eventually causes the protected bidirectional LSP to be 131 destroyed, and consequently impacts protected traffic flow after FRR. 133 Protection State Coordination Protocol [RFC6378] is applicable to FRR 134 [RFC4090] for local protection of bidirectional co-routed LSPs in 135 order to minimize traffic disruptions in both directions. However, 136 this does not address the above mentioned problem of RSVP soft-state 137 timeout in control plane. 139 This document proposes solutions to the above mentioned problems by 140 providing mechanisms in the control plane to complement FRR 141 procedures of [RFC4090] in order to maintain the RSVP soft-state for 142 bidirectional co-routed protected GMPLS LSPs and achieve symmetry in 143 the paths followed by the traffic and signaling in the forward and 144 reverse directions post FRR. The document further extends RSVP 145 signaling so that the bidirectional bypass tunnel selected by the 146 upstream PLR matches the one selected by the downstream PLR node for 147 a bidirectional co-routed LSP. 149 Unless otherwise specified in this document, fast reroute procedures 150 defined in [RFC4090] are not modified for GMPLS signaled tunnels. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 The reader is assumed to be familiar with the terminology in 159 [RFC2205] and [RFC3209]. 161 LSR: An MPLS Label-Switch Router. 163 LSP: An MPLS Label-Switched Path. 165 Local Repair: Techniques used to repair LSP tunnels quickly when a 166 node or link along the LSP's path fails. 168 PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a 169 detour LSP. 171 PSC: Packet Switched Capable. 173 Protected LSP: An LSP is said to be protected at a given hop if it 174 has one or multiple associated bypass tunnels originating at that 175 hop. 177 Bypass Tunnel: An LSP that is used to protect a set of LSPs passing 178 over a common facility. 180 NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that 181 bypasses a single link of the protected LSP. 183 NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel 184 that bypasses a single node of the protected LSP. 186 MP: Merge Point. The LSR where one or more bypass tunnels rejoin the 187 path of the protected LSP downstream of the potential failure. The 188 same LSR may be both an MP and a PLR simultaneously. 190 Downstream PLR: A PLR that locally detects a fault and reroutes 191 traffic in the same direction of the protected bidirectional LSP RSVP 192 Path signaling. A downstream PLR has a corresponding downstream MP. 194 Upstream PLR: A PLR that locally detects a fault and reroutes traffic 195 in the opposite direction of the protected bidirectional LSP RSVP 196 Path signaling. An upstream PLR has a corresponding upstream MP. 198 Point of Remote Repair (PRR): An upstream PLR that triggers reroute 199 of traffic and signaling based on procedures described in this 200 document. 202 3. Fast Reroute For Unidirectional GMPLS LSPs 204 FRR procedures defined in [RFC4090] are applicable to unidirectional 205 protected LSPs signaled using either RSVP-TE or GMPLS procedures and 206 are not modified by the extensions defined in this document. These 207 FRR procedures also apply to bidirectional associated GMPLS LSPs 208 where two unidirectional GMPLS LSPs are bound together by using 209 association signaling [BID-ASSOC]. 211 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs 213 This section describes signaling procedures for bidirectional bypass 214 tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE 215 LSPs. 217 4.1. Merge Point Labels 219 To correctly reroute data traffic over a node protection bypass 220 tunnel, the downstream and upstream PLRs have to know, in advance, 221 the downstream and upstream Merge Point (MP) labels so that data in 222 the forward and reverse directions can be tunneled through the bypass 223 tunnel post FRR respectively. 225 [RFC4090] defines procedures for the downstream PLR to obtain the 226 protected LSP's downstream MP label from recorded labels in the RRO 227 of the RSVP Resv message received at the downstream PLR. 229 To obtain the upstream MP label, existing methods [RFC4090] to record 230 upstream MP label are used in the RRO of the RSVP Path message. The 231 upstream PLR can obtain the upstream MP label from the recorded label 232 in the RRO of the received RSVP Path message. 234 4.2. Merge Point Addresses 236 To correctly assign a bidirectional bypass tunnel, the downstream and 237 upstream PLRs have to know, in advance, the downstream and upstream 238 Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR 239 to obtain the protected LSP's merge point address in multi-domain 240 routing networks where a domain is defined as an Interior Gateway 241 Protocol (IGP) area or an Autonomous System (AS). 243 [RFC4561] defines procedures for the downstream PLR to obtain the 244 protected LSP's downstream merge point address from the recorded 245 node-IDs in the RRO of the RSVP Resv message received at the 246 downstream PLR. 248 To obtain the upstream MP address, existing methods [RFC4561] to 249 record upstream MP node-ID are used in the RRO of the RSVP Path 250 message. The upstream PLR can obtain the upstream MP address from 251 the recorded node-IDs in the RRO of the received RSVP Path message. 253 4.3. RRO IPv4/IPv6 Subobject Flags 255 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 256 and are applicable to the FRR procedure for the bidirectional GMPLS 257 tunnels. 259 [RFC4090] defined procedure is used by the downstream PLR 260 independently to signal the Ipv4/IPv6 subobject flags in the RRO of 261 the RSVP Path message. Similarly, this procedure is used by the 262 upstream PLR independently to signal the IPv4/IPv6 subobject flags in 263 the RRO of the RSVP Resv message. 265 4.4. Bypass Tunnel Assignment Co-ordination 267 This document defines signaling procedure and a new BYPASS_ASSIGNMENT 268 subobject in RSVP RECORD_ROUTE object used to co-ordinate the 269 bidirectional bypass tunnel selection between the downstream and 270 upstream PLRs. 272 4.4.1. Bypass Tunnel Assignment Signaling Procedure 274 It is desirable to coordinate the bidirectional bypass tunnel 275 selected at the downstream and upstream PLRs so that rerouted traffic 276 and signaling flow on co-routed paths post FRR. To achieve this, a 277 new RSVP subobject is defined for RECORD_ROUTE object (RRO) that 278 identifies a bidirectional bypass tunnel that is assigned at a 279 downstream PLR to protect a bidirectional LSP. 281 The BYPASS_ASSIGNMENT subobject is added by each downstream PLR in 282 the RSVP Path RECORD_ROUTE message of the GMPLS signaled 283 bidirectional primary LSP to record the downstream bidirectional 284 bypass tunnel assignment. This subobject is sent in the RSVP Path 285 RECORD_ROUTE message every time the downstream PLR assigns or updates 286 the bypass tunnel assignment so the upstream PLR may reflect the 287 assignment too. 289 When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE 290 object: 292 o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node- 293 ID subobject containing the node's address. 295 o The Node-ID subobject MUST also be added. 297 o The IPv4 or IPv6 subobject MUST also be added. 299 In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR 300 SHOULD NOT assign a bypass tunnel in the reverse direction. This 301 allows the downstream PLR to always initiate the bypass assignment 302 and upstream PLR to simply reflect the bypass assignment. 304 The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT 305 subobject, whose bypass tunnel and the node-ID subobject when used as 306 a "bypass tunnel source" terminates locally, assigns the matching 307 bidirectional bypass tunnel in the reverse direction, and forwards 308 the RSVP Path message downstream. Otherwise, the bypass tunnel 309 assignment subobject is simply forwarded downstream along in the RSVP 310 Path message. 312 Bypass assignment co-ordination procedure described above can be used 313 for both one-to-one backup described in Section 3.1 of [RFC4090] and 314 facility backup described in Section 3.2 of [RFC4090]. 316 4.4.2. Bypass Tunnel Assignment Policy 318 In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT 319 subobjects from multiple downstream PLRs, the decision of selecting a 320 bypass tunnel in the reverse direction can be based on a local 321 policy, for example, prefer link protection versus node protection 322 bypass tunnel, or prefer the most upstream versus least upstream node 323 protection bypass tunnel. However, it is recommended that nodes 324 along the LSP path employ identical policy for bypass tunnel 325 assignment. 327 When different policies are used for bypass tunnel assignment on the 328 LSP path, it may result in some links in the reverse direction not 329 assigned bypass protection as shown in examples below. 331 As shown in Example 1, node A assigns a node protection bypass tunnel 332 in the forward direction but node C does not assign a node protection 333 bypass tunnel in the reverse direction for a protected bidirectional 334 GMPLS LSP. Both nodes B and C assign a link protection bypass 335 tunnel. As a result, there is no fast reroute protection available 336 in the reverse direction for link A-B for this LSP. 338 +------->>------+ 339 / +->>-+ \ 340 / / \ \ 341 / / \ \ 342 A -------- B --------- C 343 \ / 344 \ / 345 +-<<-+ 347 Example 1: An example of different bypass assignment policy 349 As shown in Example 2, nodes A and C assign a node protection bypass 350 tunnel for a protected bidirectional GMPLS LSP. Node B assigns a 351 link protection bypass tunnel but node C does not assign a reverse 352 link protection bypass tunnel. As a result, there is no fast reroute 353 protection available in the reverse direction for link A-B for this 354 LSP. 356 +------>>------+ 357 / +->>-+ \ 358 / / \ \ 359 / / \ \ 360 A -------- B --------- C 361 \ / 362 \ / 363 \ / 364 +------<<-------+ 366 Example 2: An example of different bypass assignment policy 368 4.4.3. BYPASS_ASSIGNMENT Subobject 370 The BYPASS_ASSIGNMENT subobject is used to inform the MP of the 371 bypass tunnel being assigned by the PLR. This can be used to 372 coordinate the bypass tunnel assignment for the protected LSP by the 373 downstream and upstream PLRs in the forward and reverse directions 374 respectively prior or post the failure occurrence. This subobject 375 SHOULD only be inserted into the RSVP Path message by the downstream 376 PLR and MUST NOT be changed by downstream LSRs. 378 The BYPASS_ASSIGNMENT subobject in RRO has the following format: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | Bypass Tunnel ID | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Type 388 Downstream Bypass Assignment. 390 Length 392 The Length contains the total length of the subobject in 393 bytes, including the Type and Length fields. 395 Bypass Tunnel ID 397 The bypass tunnel identifier (16 bits). 399 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs 401 When a bidirectional link protection bypass tunnel is used, after a 402 link failure, downstream PLR reroutes RSVP Path and traffic over 403 bypass tunnel using procedures defined in [RFC4090]. Upstream PLR 404 may reroute traffic and RSVP Resv upon detecting the link failure or 405 upon receiving RSVP Path message over a bidirectional bypass tunnel. 406 This allows both traffic and RSVP signaling to flow on symmetric 407 paths in the forward and reverse directions of a bidirectional 408 tunnel. 410 <-RESV 411 [R1]---[R2]----[R3]------x-----[R4]-----[R5] 412 -> PATH \ / 413 +<<-------->>+ 414 T3 415 -> PATH 416 RESV <- 418 Protected LSP: {R1-R2-R3-R4-R5} 419 R3's Bypass T3: {R3-R4} 421 Figure 1: Flow of RSVP signaling post FRR after link failure 423 Consider the Traffic Engineered (TE) network shown in Figure 1. 424 Assume every link in the network is protected with a link protection 425 bypass tunnel (e.g. bypass tunnel T3). For the protected 426 bidirectional co-routed LSP whose (active) head-end is on router R1 427 and (passive) tail-end is on router R5, each traversed router (a 428 potential PLR) assigns a link protection bidirectional co-routed 429 bypass tunnel. 431 5.1. Behavior Post Link Failure After FRR 433 Consider a link R3-R4 on the protected LSP path fails. The 434 downstream PLR R3 and upstream PLR R4 independently trigger fast 435 reroute procedures to redirect traffic onto bypass tunnels T3 in the 436 forward and reverse directions. The downstream PLR R3 also reroutes 437 RSVP Path state onto the bypass tunnel T3 using procedures described 438 in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the 439 reverse bypass tunnel T3 upon receiving RSVP Path message over bypass 440 tunnel T3. 442 5.2. Revertive Behavior Post Link Failure After FRR 444 Revertive behavior as defined in [RFC4090], Section 6.5.2, is 445 applicable to the link protection of GMPLS bidirectional LSPs. When 446 using the local revertive mode, when downstream MP receives Path 447 messages over the restored path, it starts sending Resv over the 448 restored path and stops sending Resv over the reverse bypass tunnel. 449 No additional procedure other than that specified in [RFC4090] is 450 introduced for revertive behavior by this document. 452 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs 454 T1 455 +<<--------->>+ 456 / \ <-RESV 457 [R1]---[R2]----[R3]--x--[R4]---[R5]---[R6] 458 -> PATH \ / 459 +<<--------->>+ 460 T2 462 Protected LSP: {R1-R2-R3-R4-R5-R6} 463 R3's Bypass T2: {R3-R5} 464 R4's Bypass T1: {R4-R2} 466 Figure 2: Flow of RSVP signaling post FRR after link failure 468 Consider the Traffic Engineered (TE) network shown in Figure 2. 469 Assume every link in the network is protected with a node protection 470 bypass tunnel. For the protected bidirectional co-routed LSP whose 471 (active) head-end is on router R1 and (passive) tail-end is on router 472 R6, each traversed router (a potential PLR) assigns a node protection 473 bidirectional co-routed bypass tunnel. 475 The proposed solution introduces two phases to invoking FRR 476 procedures by the PLR post the link failure. The first phase 477 comprises of FRR procedures to fast reroute data traffic onto bypass 478 tunnels in the forward and reverse directions. The second phase 479 re-coroutes the data and signaling in the forward and reverse 480 directions after the first phase. 482 6.1. Behavior Post Link Failure After FRR 484 Consider a link R3-R4 on the protected LSP path fails. The 485 downstream PLR R3 and upstream PLR R4 independently trigger fast 486 reroute procedures to redirect traffic onto respective bypass tunnels 487 T2 and T1 in the forward and reverse directions. The downstream PLR 488 R3 also reroutes RSVP Path state onto the bypass tunnel T2 using 489 procedures described in [RFC4090]. Note, at this point, router R4 490 stops receiving RSVP Path refreshes for the protected bidirectional 491 LSP while primary protected traffic continues to flow over bypass 492 tunnels. 494 6.2. Behavior Post Link Failure To Re-coroute 496 The downstream Merge Point (MP) R5 that receives rerouted protected 497 LSP RSVP Path message through the bypass tunnel, in addition to the 498 regular MP processing defined in [RFC4090], gets promoted to a Point 499 of Remote Repair (PRR role) and performs the following actions to 500 re-coroute signaling and data traffic over the same path in both 501 directions: 503 o Finds the bypass tunnel in the reverse direction 504 that terminates on the Downstream PLR R3. Note: the Downstream 505 PLR R3's address is extracted from the "IPV4 tunnel sender 506 address" in the SENDER_TEMPLATE object. 508 o If reverse bypass tunnel is found and the primary LSP traffic 509 and signaling are not already rerouted over the found bypass 510 tunnel, the PRR R5 activates FRR reroute procedures to direct 511 traffic and RSVP Resv over the found bypass tunnel T2 in the 512 reverse direction. 514 o If reverse bypass tunnel is not found, the PRR R5 signals a new 515 reverse bypass tunnel that terminates on the downstream PLR R3 516 and activates FRR reroute procedures over the new bypass tunnel 517 to direct traffic and RSVP Resv in the reverse direction. 519 o If reverse bypass tunnel can not be successfully signaled, 520 the PRR R5 immediately tears down the primary LSP. 522 If downstream MP R5 receives multiple RSVP Path messages through 523 multiple bypass tunnels (e.g. as a result of multiple failures), the 524 PRR SHOULD identify a bypass tunnel that terminates on the farthest 525 downstream PLR along the protected LSP path (closest to the primary 526 bidirectional tunnel head-end) and activate the reroute procedures 527 mentioned above. 529 <- RESV 530 [R1]---[R2]----[R3]--X--[R4]---[R5]---[R6] 531 PATH -> \ / 532 +<<------->>+ 533 Bypass Tunnel T2 534 traffic + signaling 536 Protected LSP: {R1-R2-R3-R4-R5-R6} 537 R3's Bypass T2: {R3-R5} 539 Figure 3: Flow of RSVP signaling post FRR after re-corouted 541 Figure 3 describes the path taken by the traffic and signaling after 542 completing re-coroute of data and signaling in the forward and 543 reverse paths described earlier. 545 The downstream MP MAY optionally support re-corouting in data plane 546 as follows. If the downstream MP is pre-configured with 547 bidirectional bypass tunnel, as soon as the MP node receives the 548 primary tunnel packets on this bypass tunnel, it MAY switch the 549 upstream traffic on to this bypass tunnel. In order to identify the 550 primary tunnel packets through this bypass tunnel, Penultimate Hop 551 Popping (PHP) of the bypass tunnel MUST be disabled. The signaling 552 procedure described above in this Section will still apply, and MP 553 checks whether the primary tunnel traffic and signaling is already 554 rerouted over the found bypass tunnel, if not, perform the above 555 signaling procedure. 557 6.3. Revertive Behavior Post Link Failure 559 Revertive behavior as defined in [RFC4090], Section 6.5.2, is 560 applicable to node protection of GMPLS bidirectional LSPs. When 561 using the local revertive mode, when downstream MP (R4) (before 562 re-corouting) and PRR (R5) (after re-corouting) receive Path messages 563 over the restored path, they start sending Resv over the restored 564 path and stop sending Resv over the reverse bypass tunnel. No 565 additional procedure other than that specified in [RFC4090] is 566 introduced for revertive behavior by this document. 568 7. Compatibility 570 New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE 571 Object in this document. Per [RFC2205], nodes not supporting this 572 subobject will ignore the subobject but forward it without 573 modification. 575 8. Security Considerations 577 This document introduces one new RSVP subobject that is carried in a 578 signaling message. Thus in the event of the interception of a 579 signaling message, slightly more information about the state of the 580 network could be deduced than was previously the case. This is 581 judged to be a very minor security risk as this information is 582 already available by other means. 584 Otherwise, this document introduces no additional security 585 considerations. For general discussion on MPLS and GMPLS related 586 security issues, see the MPLS/GMPLS security framework [RFC5920]. 588 9. IANA Considerations 590 IANA manages the "RSVP PARAMETERS" registry located at 591 http://www.iana.org/assignments/rsvp-parameters. IANA is requested 592 to assign a value for the new BYPASS_ASSIGNMENT subobject in the 593 "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. 595 This document introduces a new RRO subobject: 597 +--------------+-----------------------------+---------------+ 598 | Value | Description | Reference | 599 +--------------+-----------------------------+---------------+ 600 | TBA By IANA | BYPASS_ASSIGNMENT subobject | This document | 601 +--------------+-----------------------------+---------------+ 603 10. Acknowledgements 605 Authors would like to thank George Swallow for his detailed and 606 useful comments and suggestions. Authors would also like to thank 607 Nobo Akiya, Loa Andersson and Gregory Mirsky for reviewing this 608 document. 610 11. Contributing Authors 612 Frederic Jounay 613 Orange CH 615 Email: frederic.jounay@orange.ch 617 12. References 619 12.1. Normative References 621 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 622 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 623 Functional Specification", RFC 2205, September 1997. 625 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 626 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 627 Tunnels", RFC 3209, December 2001. 629 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 630 Switching (GMPLS) Signaling Resource ReserVation Protocol- 631 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 632 January 2003. 634 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 635 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 636 May 2005. 638 [BID-ASSOC] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 639 Extensions for Associated Bidirectional LSPs", December 640 2014. 642 12.2. Informative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition 648 of a Record Route Object (RRO) Node-Id Sub-Object", RFC 649 4561, June 2006. 651 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 652 Networks", RFC 5920, July 2010. 654 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 655 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 656 Protection", RFC 6378, October 2011. 658 Authors' Addresses 660 Mike Taillon 661 Cisco Systems, Inc. 663 Email: mtaillon@cisco.com 665 Tarek Saad (editor) 666 Cisco Systems, Inc. 668 Email: tsaad@cisco.com 670 Rakesh Gandhi (editor) 671 Cisco Systems, Inc. 673 Email: rgandhi@cisco.com 675 Zafar Ali 676 Cisco Systems, Inc. 678 Email: zali@cisco.com 680 Manav Bhatia 681 India 683 Email: manav@ionosnetworks.com 685 Lizhong Jin 686 Shanghai, China 688 Email: lizho.jin@gmail.com