idnits 2.17.1 draft-gandhishah-teas-assoc-corouted-bidir-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 (March 10, 2017) is 2576 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 R. Gandhi, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended Status: Standards Track H. Shah 5 Expires: September 11, 2017 Ciena 6 Jeremy Whittaker 7 Verizon 8 March 10, 2017 10 Fast Reroute Procedures For Associated Bidirectional Label 11 Switched Paths (LSPs) 12 draft-gandhishah-teas-assoc-corouted-bidir-04 14 Abstract 16 Resource Reservation Protocol (RSVP) association signaling can be 17 used to bind two unidirectional LSPs into an associated bidirectional 18 LSP. When an associated bidirectional LSP is co-routed, the reverse 19 LSP follows the same path as its forward LSP. This document 20 describes Fast Reroute (FRR) procedures for both single-sided and 21 double-sided provisioned associated bidirectional LSPs. The FRR 22 procedures are applicable to co-routed and non co-routed LSPs. For 23 co-routed LSPs, the FRR procedures can ensure that traffic flows on 24 co-routed paths in the forward and reverse directions after a failure 25 event. 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) 2017 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 . . . . . . . . . . . . . . 3 61 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2.1. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 4 66 3.2. Bidirectional LSP Association At Mid-Points . . . . . . . 5 67 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Bidirectional LSP Fast Reroute . . . . . . . . . . . . . . 6 69 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 7 70 5. Message and Object Definitions . . . . . . . . . . . . . . . . 7 71 5.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 7 72 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION 83 Object is specified in [RFC6780] which can be used generically to 84 associate (G)Multi-Protocol Label Switching (MPLS) Label Switched 85 Paths (LSPs). [RFC7551] defines mechanisms for binding two point-to- 86 point unidirectional LSPs [RFC3209] into an associated bidirectional 87 LSP. There are two models described in [RFC7551] for provisioning an 88 associated bidirectional LSP, single-sided and double-sided. In both 89 models, the reverse LSP of the bidirectional LSP may or may not be 90 co-routed and follow the same path as its forward LSP. 92 [GMPLS-FRR] defines Fast Reroute (FRR) procedure for GMPLS signaled 93 LSPs to co-ordinate bypass tunnel assignments in the forward and 94 reverse directions. The mechanisms defined in [GMPLS-FRR] are 95 applicable to FRR of associated bidirectional LSPs. 97 In packet transport networks, there are requirements where the 98 reverse LSP of a bidirectional LSP needs to follow the same path as 99 its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] 100 architecture facilitates the co-routed bidirectional LSP by using the 101 GMPLS extensions [RFC3473] to achieve congruent paths. However, the 102 RSVP association signaling allows to enable co-routed bidirectional 103 LSPs without having to deploy GMPLS extensions in the existing 104 networks. The association signaling also allows to take advantage of 105 the existing Traffic Engineering (TE) and FRR mechanisms in the 106 network. 108 This document describes FRR procedures for both single-sided and 109 double-sided provisioned associated bidirectional LSPs. The FRR 110 procedures are applicable to co-routed and non co-routed LSPs. For 111 co-routed LSPs, the FRR procedures can ensure that traffic flows on 112 co-routed paths in the forward and reverse directions after a failure 113 event. 115 2. Conventions Used in This Document 117 2.1. Key Word Definitions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2.2. Terminology 125 The reader is assumed to be familiar with the terminology in 126 [RFC2205], [RFC3209], [RFC4090] and [RFC7551]. 128 2.2.1. Reverse Co-routed Unidirectional LSPs 130 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 131 opposite directions between a pair of source and destination nodes to 132 form an associated bidirectional LSP. A reverse unidirectional LSP 133 originates on the same node where the forward unidirectional LSP 134 terminates, and it terminates on the same node where the forward 135 unidirectional LSP originates. A reverse co-routed unidirectional 136 LSP traverses along the same path of the forward direction 137 unidirectional LSP in the opposite direction. 139 3. Overview 141 As specified in [RFC7551], in the single-sided provisioning case, the 142 RSVP TE tunnel is configured only on one endpoint node of the 143 bidirectional LSP. An LSP for this tunnel is initiated by the 144 originating endpoint with (Extended) ASSOCIATION Object containing 145 Association Type set to "single-sided associated bidirectional LSP" 146 and REVERSE_LSP Object inserted in the Path message. The remote 147 endpoint then creates the corresponding reverse TE tunnel and signals 148 the reverse LSP in response using the information from the 149 REVERSE_LSP Object and other objects present in the received Path 150 message. As specified in [RFC7551], in the double-sided provisioning 151 case, the RSVP TE tunnel is configured on both endpoint nodes of the 152 bidirectional LSP. Both forward and reverse LSPs are initiated 153 independently by the two endpoints with (Extended) ASSOCIATION Object 154 containing Association Type set to "double-sided associated 155 bidirectional LSP". In both single-sided and double-sided 156 provisioned bidirectional LSPs, the reverse LSP may or may not be 157 congruent (i.e. co-routed) and follow the same path as its forward 158 LSP. 160 In the case of single-sided provisioned LSP, the originating LSP with 161 REVERSE_LSP Object is identified as a forward LSP. In the case of 162 double-sided provisioned LSP, the LSP originating from the higher 163 node address (as source) and terminating on the lower node address 164 (as destination) is identified as a forward LSP. The reverse LSP of 165 the bidirectional LSP traverses in the opposite direction of the 166 forward LSP. 168 Both single-sided and double-sided associated bidirectional LSPs 169 require solutions to the following issues for fast reroute. 171 3.1. Fast Reroute Bypass Tunnel Assignment 173 In order to ensure that the traffic flows on a co-routed path after a 174 link or node failure on the protected LSP path, the mid-point Point 175 of Local Repair (PLR) nodes need to assign matching bidirectional 176 bypass tunnels for fast reroute. Even for a non co-routed 177 bidirectional LSP, it is desired that the same bidirectional bypass 178 tunnel is used in both directions of the protected LSP. Such bypass 179 assignment requires co-ordination between the forward and reverse 180 direction PLR nodes when more than one bypass tunnels are present on 181 a PLR node. 183 <-- Bypass N --> 184 +-----+ +-----+ 185 | H +---------+ I | 186 +--+--+ +--+--+ 187 | | 188 | | 189 LSP1 --> | LSP1 --> | LSP1 --> LSP1 --> 190 +----+ +--+--+ +--+--+ +----+ +----+ 191 | A +---------+ B +----X----+ C +---------+ D +---------+ E | 192 +----+ +--+--+ +--+--+ +----+ +----+ 193 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 194 | | 195 | | 196 +--+--+ +--+--+ 197 | F +---------+ G | 198 +-----+ +-----+ 199 <-- Bypass S --> 201 Figure 1: Multiple Bidirectional Bypass Tunnels 203 As shown in Figure 1, there are two bypass tunnels available, Bypass 204 N on path B-H-I-C and Bypass S on path B-F-G-C. The mid-point PLR 205 nodes B and C need to co-ordinate bypass tunnel assignment to ensure 206 that traffic in both directions flow through either on the Bypass N 207 path B-H-I-C or the Bypass S path B-F-G-C, after the link B-C 208 failure. 210 3.2. Bidirectional LSP Association At Mid-Points 212 In packet transport networks, a restoration LSP is signaled after a 213 link failure on the protected LSP and the protected LSP may or may 214 not be torn down [GMPLS-REST]. In this case, multiple forward and 215 reverse LSPs of a bidirectional LSP may be present at mid-point nodes 216 with identical (Extended) ASSOCIATION Objects. This creates an 217 ambiguity at mid-point nodes to identify the correct associated LSP 218 pair for fast reroute bypass assignment (e.g. during the recovery 219 phase of RSVP graceful restart procedure). 221 LSP3 --> LSP3 --> LSP3 --> 222 LSP1 --> LSP1 --> LSP1 --> LSP1 --> 223 +----+ +-----+ +-----+ +----+ +----+ 224 | A +---------+ B +----X----+ C +---------+ D +---------+ E | 225 +----+ +--+--+ +--+--+ +----+ +----+ 226 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 227 <-- LSP4 | | <-- LSP4 <-- LSP4 228 | | 229 | LSP3 --> | 230 +--+--+ +--+--+ 231 | F +---------+ G | 232 +-----+ +-----+ 233 <-- LSP4 235 Figure 2: Restoration LSP Set-up After Link Failure 237 As shown in Figure 2, protected LSPs LSP1 and LSP2 are an associated 238 LSP pair, similarly restoration LSPs LSP3 and LSP4 are an associated 239 LSP pair, both pairs belong to the same associated bidirectional LSP 240 and carry identical (Extended) ASSOCIATION Objects. In this example, 241 mid-point node D may mistakenly associate LSP1 with reverse LSP4 242 instead of reverse LSP3 due to the matching (Extended) ASSOCIATION 243 Objects. This may cause the bidirectional LSP to become non co- 244 routed. Since a reverse LSP reflects the bypass tunnel assignment 245 received in the forward LSP, this can also lead to undesired bypass 246 tunnel assignments. 248 4. Signaling Procedure 250 4.1. Bidirectional LSP Fast Reroute 252 The mechanisms defined in [GMPLS-FRR] are used for fast reroute of 253 both single-sided and double-sided associated bidirectional LSPs as 254 following. 256 o As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject is 257 signaled in the RRO of the Path message to co-ordinate bypass 258 tunnel assignment between the forward and reverse direction PLR 259 nodes. A BYPASS_ASSIGNMENT subobject MUST be added by the forward 260 direction PLR node in the Path message of the forward LSP to 261 indicate the bypass tunnel assigned. 263 o The forward direction PLR node always initiates the bypass tunnel 264 assignment for the forward LSP. The reverse direction PLR 265 (forward direction LSP Merge Point (MP)) node simply reflects the 266 bypass tunnel assignment for the reverse direction LSP. 268 o After a link or node failure, the PLR nodes in both forward and 269 reverse directions trigger fast reroute independently using the 270 procedures defined in [RFC4090]. 272 o When using a node protection bypass tunnel, asymmetry of paths can 273 occur in the forward and reverse directions of the bidirectional 274 LSP after a link failure when using co-routed LSPs [GMPLS-FRR]. 275 This can be corrected using the re-corouting procedure defined in 276 [GMPLS-FRR]. Unlike GMPLS LSPs, the asymmetry of paths in the 277 forward and reverse directions does not result in RSVP soft-state 278 time-out with the associated bidirectional LSPs. 280 4.2. Bidirectional LSP Association At Mid-points 282 In order to associate the correct LSPs at a mid-point node, an 283 endpoint node MUST signal Extended ASSOCIATION Object and add unique 284 Extended Association ID for each associated forward and reverse LSP 285 pair forming the bidirectional LSP. As an example, an endpoint node 286 MAY set the Extended Association ID to the value specified in Section 287 5.1 of this document. 289 o For single-sided provisioned bidirectional LSPs [RFC7551], the 290 originating endpoint signals the Extended ASSOCIATION Object with 291 a unique Extended Association ID. The remote endpoint copies the 292 contents of the received Extended ASSOCIATION Object including the 293 Extended Association ID in the RSVP Path message of the reverse 294 LSP's Extended ASSOCIATION Object. 296 o For double-sided provisioned bidirectional LSPs [RFC7551], both 297 endpoints need to ensure that the bidirectional LSP has a unique 298 Extended ASSOCIATION Object for each forward and reverse LSP pair 299 by provisioning appropriate Extended Association IDs signaled by 300 them. 302 5. Message and Object Definitions 304 5.1. Extended ASSOCIATION Object 306 The Extended Association ID in the Extended ASSOCIATION Object can be 307 set to the value specified as following to uniquely identify 308 associated forward and reverse LSP pair of a bidirectional LSP. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | IPv4 LSP Source Address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Reserved | LSP-ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 : : 318 : Variable Length ID : 319 : : 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 3: IPv4 Extended Association ID 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 + + 329 | IPv6 LSP Source Address | 330 + + 331 | (16 bytes) | 332 + + 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Reserved | LSP-ID | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 : : 338 : Variable Length ID : 339 : : 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 4: IPv6 Extended Association ID 344 LSP Source Address 346 IPv4/IPv6 source address of the forward LSP. 348 LSP-ID 350 16-bits LSP-ID of the forward LSP. 352 Variable Length ID 354 Variable length ID inserted by the endpoint node of the associated 355 bidirectional LSP [RFC6780]. 357 6. Compatibility 358 This document describes the procedures for fast reroute for 359 associated bidirectional LSPs. Operators wishing to use this 360 function SHOULD ensure that it is supported on the nodes on the LSP 361 path. 363 7. Security Considerations 365 This document uses signaling mechanisms defined in [RFC7551] and 366 [GMPLS-FRR] and does not introduce any additional security 367 considerations other than already covered in [RFC7551], [GMPLS-FRR] 368 and the MPLS/GMPLS security framework [RFC5920]. 370 8. IANA Considerations 372 This document does not make any request for IANA action. 374 9. References 376 9.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 382 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 383 Functional Specification", RFC 2205, September 1997. 385 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 386 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 387 May 2005. 389 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 390 Association Object Extensions", RFC 6780, October 2012. 392 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 393 Extensions for Associated Bidirectional LSPs", RFC 7551, 394 May 2015. 396 [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., 397 Bhatia, M., "Extensions to Resource Reservation Protocol 398 For Fast Reroute of Traffic Engineering GMPLS LSPs", 399 draft-ietf-teas-gmpls-lsp-fastreroute, work in progress. 401 9.2. Informative References 403 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 404 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 405 Tunnels", RFC 3209, December 2001. 407 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 408 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 409 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 411 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 412 Networks", RFC 5920, July 2010. 414 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 415 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 417 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 418 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 419 Framework", RFC 6373, September 2011. 421 [GMPLS-REST] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., 422 Brzozowski, P., "RSVP-TE Signaling Procedure for End-to- 423 End GMPLS Restoration and Resource Sharing", draft-ietf- 424 teas-gmpls-resource-sharing-proc, work in progress. 426 Authors' Addresses 428 Rakesh Gandhi (editor) 429 Cisco Systems, Inc. 431 EMail: rgandhi@cisco.com 433 Himanshu Shah 434 Ciena 436 EMail: hshah@ciena.com 438 Jeremy Whittaker 439 Verizon 441 EMail: jeremy.whittaker@verizon.com