idnits 2.17.1 draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05.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 (September 5, 2014) is 3518 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 CCAMP Working Group Mike Taillon 3 Internet-Draft Tarek Saad, Ed. 4 Intended Status: Standards Track Rakesh Gandhi, Ed. 5 Expires: March 9, 2015 Zafar Ali 6 (Cisco Systems, Inc.) 7 Manav Bhatia 8 Lizhong Jin 9 () 10 Frederic Jounay 11 (Orange CH) 12 September 5, 2014 14 Extensions to Resource Reservation Protocol For Fast Reroute of 15 Traffic Engineering GMPLS LSPs 16 draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 18 Abstract 20 This document defines Resource Reservation Protocol - Traffic 21 Engineering (RSVP-TE) signaling extensions to support Fast Reroute 22 (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol 23 Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling 24 extensions allow the coordination of bidirectional bypass tunnel 25 assignment protecting a common facility in both forward and reverse 26 directions of a co-routed bidirectional LSP. In addition, these 27 extensions enable the re-direction of bidirectional traffic and 28 signaling onto bypass tunnels that ensure co-routedness of data and 29 signaling paths in the forward and reverse directions after FRR to 30 avoid RSVP soft-state timeout. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 72 4. Bidirectional Bypass Tunnel Assignment for Bidirectional 73 GMPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.1. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5 75 4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . . 5 76 4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . . 6 77 4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6 78 4.4.1. Bypass Tunnel Assignment Co-ordination Signaling 79 Procedure . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.4.2. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 7 81 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 8 82 5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 8 83 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 9 84 6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 9 85 6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 10 86 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 11.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 Packet Switched Capable (PSC) bidirectional Traffic Engineering (TE) 98 tunnels are signaled using Generalized Multi-Protocol Label Switching 99 (GMPLS) signaling procedures specified in [RFC3473]. Fast Reroute 100 (FRR) [RFC4090] has been widely deployed in the packet TE networks 101 today and is preferred for bidirectional TE tunnels. Using FRR also 102 allows to leverage existing mechanisms for failure detection and 103 restoration in the deployed networks. 105 FRR procedures defined in [RFC4090] describe the behavior of the 106 Point of Local Repair (PLR) to reroute traffic and signaling onto the 107 bypass tunnel in the event of a failure for unidirectional LSPs. 108 These procedures are applicable to unidirectional protected LSPs 109 signaled using either RSVP-TE [RFC3209] or GMPLS procedures 110 [RFC3473], however don't address issues that arise when employing FRR 111 for bidirectional co-routed GMPLS Label Switched Paths (LSPs). 113 When bidirectional bypass tunnels are used to locally protect 114 bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs 115 may independently assign different bidirectional bypass tunnels in 116 the forward and reverse directions. There is no mechanism in FRR 117 procedures defined in [RFC4090] to coordinate the bidirectional 118 bypass tunnel selection between the downstream and upstream PLRs. 120 When using FRR procedures with bidirectional co-routed GMPLS LSPs, it 121 is possible in some cases (e.g. when using node protection bypass 122 tunnels post a link failure event and when RSVP signaling is sent in- 123 fiber and in-band with data), the RSVP signaling refreshes may stop 124 reaching some nodes along the primary bidirectional LSP path after 125 the PLRs complete rerouting traffic and signaling onto the bypass 126 tunnels. This is caused by the asymmetry of paths that may be taken 127 by the bidirectional LSP's signaling in the forward and reverse 128 directions after FRR reroute. In such cases, the RSVP soft-state 129 timeout eventually causes the protected bidirectional LSP to be 130 destroyed, and consequently impacts protected traffic flow after FRR. 132 This document proposes solutions to the above mentioned problems by 133 providing mechanisms in the control plane to complement FRR 134 procedures of [RFC4090] in order to maintain the RSVP soft-state for 135 bidirectional co-routed protected GMPLS LSPs and achieve symmetry in 136 the paths followed by the traffic and signaling in the forward and 137 reverse directions post FRR. The document further extends RSVP 138 signaling so that the bidirectional bypass tunnel selected by the 139 upstream PLR matches the one selected by the downstream PLR node for 140 a bidirectional co-routed LSP. 142 Unless otherwise specified in this document, fast reroute procedures 143 defined in [RFC4090] are not modified for bidirectional tunnels. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 The reader is assumed to be familiar with the terminology in 152 [RFC2205] and [RFC3209]. 154 LSR: Label-Switch Router. 156 LSP: An MPLS Label-Switched Path. In this document, an LSP will 157 always be explicitly routed. 159 Local Repair: Techniques used to repair LSP tunnels quickly when a 160 node or link along the LSP's path fails. 162 PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a 163 detour LSP. 165 Protected LSP: An LSP is said to be protected at a given hop if it 166 has one or multiple associated bypass tunnels originating at that 167 hop. 169 Bypass Tunnel: An LSP that is used to protect a set of LSPs passing 170 over a common facility. 172 NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that 173 bypasses a single link of the protected LSP. 175 NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel 176 that bypasses a single node of the protected LSP. 178 MP: Merge Point. The LSR where one or more bypass tunnels rejoin the 179 path of the protected LSP downstream of the potential failure. The 180 same LSR may be both an MP and a PLR simultaneously. 182 Downstream PLR: A PLR that locally detects a fault and reroutes 183 traffic in the same direction of the protected bidirectional LSP RSVP 184 Path signaling. 186 Upstream PLR: A PLR that locally detects a fault and reroutes traffic 187 in the opposite direction of the protected bidirectional LSP RSVP 188 Path signaling. 190 Point of Remote Repair (PRR): An upstream PLR that triggers reroute 191 of traffic and signaling based on procedures described in this 192 document. 194 3. Fast Reroute For Unidirectional GMPLS LSPs 196 FRR procedures defined in [RFC4090] are applicable to unidirectional 197 protected LSPs signaled using either RSVP-TE or GMPLS procedures and 198 are not modified by the extensions proposed in this document. These 199 FRR procedures also apply to bidirectional associated GMPLS LSPs 200 where two unidirectional GMPLS LSPs are bound together by using 201 association signaling [BID-ASSOC]. 203 4. Bidirectional Bypass Tunnel Assignment for Bidirectional GMPLS LSPs 205 This section describes signaling procedures for bidirectional bypass 206 tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE 207 LSPs. 209 4.1. Merge Point Labels 211 To correctly reroute data traffic over a node protection bypass 212 tunnel, the downstream and upstream PLRs have to know, in advance, 213 the downstream and upstream Merge Point (MP) labels so that data in 214 the forward and reverse directions can be tunneled through the bypass 215 tunnel post FRR respectively. 217 [RFC4090] defines procedures for the downstream PLR to obtain the 218 protected LSP's downstream MP label from recorded labels in the RRO 219 of the RSVP Resv message received at the downstream PLR. 221 To obtain the upstream MP label, existing methods [RFC4090] to record 222 upstream MP label are used in the RRO of the RSVP Path message. The 223 upstream PLR can obtain the upstream MP label from the recorded label 224 in the RRO of the received RSVP Path message. 226 4.2. Merge Point Addresses 228 To correctly assign a bidirectional bypass tunnel, the downstream and 229 upstream PLRs have to know, in advance, the downstream and upstream 230 Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR 231 to obtain the protected LSP's merge point address in multi-domain 232 routing networks where a domain is defined as an Interior Gateway 233 Protocol (IGP) area or an Autonomous System (AS). 235 [RFC4561] defines procedures for the downstream PLR to obtain the 236 protected LSP's downstream merge point address from the recorded 237 node-IDs in the RRO of the RSVP Resv message received at the 238 downstream PLR. 240 To obtain the upstream MP address, existing methods [RFC4561] to 241 record upstream MP node-ID are used in the RRO of the RSVP Path 242 message. The upstream PLR can obtain the upstream MP address from 243 the recorded node-IDs in the RRO of the received RSVP Path message. 245 4.3. RRO IPv4/IPv6 Subobject Flags 247 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 248 and are applicable to the FRR procedure for the bidirectional 249 tunnels. 251 [RFC4090] defined procedure is used by the downstream PLR 252 independently to signal the Ipv4/IPv6 subobject flags in the RRO of 253 the RSVP Path message. Similarly, this procedure is used by the 254 upstream PLR independently to signal the IPv4/IPv6 subobject flags in 255 the RRO of the RSVP Resv message. 257 4.4. Bypass Tunnel Assignment Co-ordination 259 This document defines a new BYPASS_ASSIGNMENT subobject in RSVP 260 RECORD_ROUTE object used to co-ordinate the bidirectional bypass 261 tunnel selection between the downstream and upstream PLRs. 263 4.4.1. Bypass Tunnel Assignment Co-ordination Signaling Procedure 265 It is desirable to coordinate the bidirectional bypass tunnel 266 selected at the downstream and upstream PLRs so that rerouted traffic 267 and signaling flow on co-routed paths post FRR. To achieve this, a 268 new RSVP subobject is defined for RECORD_ROUTE object (RRO) that 269 identifies a bidirectional bypass tunnel that is assigned at a 270 downstream PLR to protect a bidirectional LSP. 272 The BYPASS_ASSIGNMENT subobject is added by each downstream PLR in 273 the RSVP Path RECORD_ROUTE message of the GMPLS signaled 274 bidirectional primary LSP to record the downstream bidirectional 275 bypass tunnel assignment. This subobject is sent in the RSVP Path 276 RECORD_ROUTE message every time the downstream PLR assigns or updates 277 the bypass tunnel assignment so the upstream PLR may reflect the 278 assignment too. The BYPASS_ASSIGNMENT subobject is added in the 279 RECORD_ROUTE object prior to adding the node's IP address in the 280 node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject 281 without also adding a Node-ID subobject. A node MUST NOT add a 282 BYPASS_ASSIGNMENT subobject without also adding an IPv4 or IPv6 283 subobject. 285 The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT 286 subobject whose bypass tunnel and the node-ID subobject when used as 287 a bypass tunnel source terminates locally assigns the matching 288 bidirectional bypass tunnel in the reverse direction, and forwards 289 the RSVP Path message downstream. Otherwise, the bypass tunnel 290 assignment subobject is simply forwarded downstream along in the RSVP 291 Path message. 293 In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does 294 not assign a bypass tunnel in the reverse direction. This allows the 295 downstream PLR to always initiate the bypass assignment and upstream 296 PLR to simply reflect the bypass assignment. 298 In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT 299 subobjects from multiple downstream PLRs, the decision of selecting a 300 bypass tunnel in the reverse direction can be based on local policy, 301 for example, prefer link protection versus node protection bypass 302 tunnel, or prefer the most upstream versus least upstream node 303 protection bypass tunnel. 305 Bypass assignment co-ordination procedure described above can be used 306 for both one-to-one backup described in Section 3.1 of [RFC4090] and 307 facility backup described in Section 3.2 of [RFC4090]. 309 4.4.2. BYPASS_ASSIGNMENT Subobject 311 The BYPASS_ASSIGNMENT subobject is used to inform the MP of the 312 bypass tunnel being used by the PLR. This can be used to coordinate 313 the bypass tunnel used for the protected LSP by the downstream and 314 upstream PLRs in the forward and reverse directions respectively 315 prior or post the failure occurrence. This subobject SHOULD only be 316 inserted into the Path message by the downstream PLR and MUST NOT be 317 changed by downstream LSRs. 319 The BYPASS_ASSIGNMENT subobject in RRO has the following format: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | Bypass Tunnel ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type 329 Downstream Bypass Assignment. 331 Length 332 The Length contains the total length of the subobject in 333 bytes, including the Type and Length fields. 335 Bypass Tunnel ID 337 The bypass tunnel identifier (16 bits). 339 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs 341 When a bidirectional link protection bypass tunnel is used, after a 342 link failure, downstream PLR reroutes RSVP Path and traffic over 343 bypass tunnel using procedures defined in [RFC4090]. Upstream PLR 344 may reroute traffic and RSVP Resv upon detecting the link failure or 345 upon receiving RSVP Path message over a bidirectional bypass tunnel. 346 This allows both traffic and RSVP signaling to flow on symmetric 347 paths in the forward and reverse directions of a bidirectional 348 tunnel. 350 <-RESV 351 [R1]---[R2]----[R3]------x-----[R4]-----[R5] 352 -> PATH \ / 353 +<<-------->>+ 354 T3 355 -> PATH 356 RESV <- 358 Protected LSP: {R1-R2-R3-R4-R5} 359 R3's Bypass T3: {R3-R4} 361 Figure 1: Flow of RSVP signaling post FRR after link failure 363 Consider the Traffic Engineered (TE) network shown in Figure 1. 364 Assume every link in the network is protected with a link protection 365 bypass tunnel (e.g. bypass tunnel T3). For the protected 366 bidirectional co-routed LSP whose (active) head-end is on router R1 367 and (passive) tail-end is on router R5, each traversed router (a 368 potential PLR) assigns a link protection bidirectional co-routed 369 bypass tunnel. Consider a link R3-R4 on the protected LSP path 370 fails. 372 5.1. Behavior Post Link Failure After FRR 374 The downstream PLR R3 and upstream PLR R4 independently trigger fast 375 reroute procedures to redirect traffic onto bypass tunnels T3 in the 376 forward and reverse directions. The downstream PLR R3 also reroutes 377 RSVP Path state onto the bypass tunnel T3 using procedures described 378 in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the 379 reverse bypass tunnel T3 upon receiving RSVP Path message over bypass 380 tunnel T3. 382 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs 384 T1 385 +<<--------->>+ 386 / \ <-RESV 387 [R1]---[R2]----[R3]--x--[R4]---[R5]---[R6] 388 -> PATH \ / 389 +<<--------->>+ 390 T2 392 Protected LSP: {R1-R2-R3-R4-R5-R6} 393 R3's Bypass T2: {R3-R5} 394 R4's Bypass T1: {R4-R2} 396 Figure 2: Flow of RSVP signaling post FRR after link failure 398 Consider the Traffic Engineered (TE) network shown in Figure 2. 399 Assume every link in the network is protected with a node protection 400 bypass tunnel. For the protected bidirectional co-routed LSP whose 401 (active) head-end is on router R1 and (passive) tail-end is on router 402 R6, each traversed router (a potential PLR) assigns a node protection 403 bidirectional co-routed bypass tunnel. Consider a link R3-R4 on the 404 protected LSP path fails. 406 The proposed solution introduces two phases to invoking FRR 407 procedures by the PLR post the link failure. The first phase 408 comprises of FRR procedures to fast reroute data traffic onto bypass 409 tunnels in the forward and reverse directions. The second phase 410 re-coroutes the data and signaling in the forward and reverse 411 directions after the first phase. 413 6.1. Behavior Post Link Failure After FRR 415 The downstream PLR R3 and upstream PLR R4 independently trigger fast 416 reroute procedures to redirect traffic onto respective bypass tunnels 417 T2 and T1 in the forward and reverse directions. The downstream PLR 418 R3 also reroutes RSVP Path state onto the bypass tunnel T2 using 419 procedures described in [RFC4090]. Note, at this point, router R4 420 stops receiving RSVP Path refreshes for the protected bidirectional 421 LSP while primary protected traffic continues to flow over bypass 422 tunnels. 424 6.2. Behavior Post Link Failure To Re-coroute 426 The downstream Merge Point (MP) R5 that receives rerouted protected 427 LSP RSVP Path message through the bypass tunnel, in addition to the 428 regular MP processing defined in [RFC4090], gets promoted to a Point 429 of Remote Repair (PRR role) and performs the following actions to 430 re-coroute signaling and data traffic over the same path in both 431 directions: 433 - Finds the bypass tunnel in the reverse direction 434 that terminates on the Downstream PLR R3. Note: the Downstream 435 PLR R3's address is extracted from the "IPV4 tunnel sender 436 address" in the SENDER_TEMPLATE object. 438 - If found, checks whether the primary LSP traffic and signaling 439 are already rerouted over the found bypass tunnel. If not, PRR 440 R5 activates FRR reroute procedures to direct traffic and 441 RSVP Resv over the found bypass tunnel T2 in the 442 reverse direction. 444 If downstream MP R5 receives multiple RSVP Path messages through 445 multiple bypass tunnels (e.g. as a result of multiple failures), the 446 PRR SHOULD identify a bypass tunnel that terminates on the farthest 447 downstream PLR along the protected LSP path (closest to the primary 448 bidirectional tunnel head-end) and activate the reroute procedures 449 mentioned above. 451 <- RESV 452 [R1]---[R2]----[R3]--X--[R4]---[R5]---[R6] 453 PATH -> \ / 454 +<<------->>+ 455 Bypass Tunnel T2 456 traffic + signaling 458 Protected LSP: {R1-R2-R3-R4-R5-R6} 459 R3's Bypass T2: {R3-R5} 461 Figure 3: Flow of RSVP signaling post FRR after re-corouted 463 Figure 3 describes the path taken by the traffic and signaling after 464 completing re-coroute of data and signaling in the forward and 465 reverse paths described earlier. 467 The downstream MP MAY optionally support re-corouting in data plane 468 as follows. If the downstream MP is pre-configured with 469 bidirectional bypass tunnel, as soon as the MP node receives the 470 primary tunnel packets on this bypass tunnel, it MAY switch the 471 upstream traffic on to this bypass tunnel. In order to identify the 472 primary tunnel packets through this bypass tunnel, Penultimate Hop 473 Popping (PHP) of the bypass tunnel MUST be disabled. The signaling 474 procedure described above in this Section will still apply, and MP 475 checks whether the primary tunnel traffic and signaling is already 476 rerouted over the found bypass tunnel, if not, perform the above 477 signaling procedure. 479 7. Compatibility 481 New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE in 482 this document. Per [RFC2205], nodes not supporting this subobject 483 will ignore the subobject but forward it without modification. 485 8. Security Considerations 487 This document introduces one new RSVP subobject that is carried in a 488 signaling message. Thus in the event of the interception of a 489 signaling message, slightly more information about the state of the 490 network could be deduced than was previously the case. This is 491 judged to be a very minor security risk as this information is 492 already available by other means. 494 Otherwise, this document introduces no additional security 495 considerations. For general discussion on MPLS and GMPLS related 496 security issues, see the MPLS/GMPLS security framework [RFC5920]. 498 9. IANA Considerations 500 A new type for the new BYPASS_ASSIGNMENT subobject for RSVP 501 RECORD_ROUTE object is required. 503 10. Acknowledgements 505 Authors would like to thank George Swallow for his detailed and 506 useful comments and suggestions. 508 11. References 510 11.1. Normative References 512 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 513 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 514 Functional Specification", RFC 2205, September 1997. 516 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 517 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 518 Tunnels", RFC 3209, December 2001. 520 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 521 Switching (GMPLS) Signaling Resource ReserVation Protocol- 522 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 523 January 2003. 525 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 526 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 527 May 2005. 529 [BID-ASSOC] Zhang, F., Jing, R., and Gandhi, R., "RSVP-TE Extensions 530 for Associated Bidirectional LSPs", July 2014. 532 11.2. Informative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan, 538 "Definition of a Record Route Object (RRO) Node-Id 539 Sub-Object", RFC 4561, June 2006. 541 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 542 Networks", RFC5920, July 2010. 544 Authors' Addresses 546 Mike Taillon 547 Cisco Systems, Inc. 549 EMail: mtaillon@cisco.com 551 Tarek Saad (editor) 552 Cisco Systems, Inc. 554 EMail: tsaad@cisco.com 556 Rakesh Gandhi (editor) 557 Cisco Systems, Inc. 559 EMail: rgandhi@cisco.com 561 Zafar Ali 562 Cisco Systems, Inc. 564 EMail: zali@cisco.com 566 Manav Bhatia 567 India 569 Email: manav@ionosnetworks.com 571 Lizhong Jin 572 Shanghai, China 574 Email: lizho.jin@gmail.com 576 Frederic Jounay 577 Orange CH 579 Email: frederic.jounay@orange.ch