idnits 2.17.1 draft-gandhishah-teas-assoc-corouted-bidir-03.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 (February 14, 2017) is 2626 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 4 Intended Status: Standards Track H. Shah 5 Expires: August 18, 2017 Ciena 6 Jeremy Whittaker 7 Verizon 8 February 14, 2017 10 Fast Reroute Procedures For Associated Co-routed Bidirectional 11 Label Switched Paths (LSPs) 12 draft-gandhishah-teas-assoc-corouted-bidir-03 14 Abstract 16 Resource Reservation Protocol (RSVP) association signaling can be 17 used to bind two unidirectional LSPs into an associated bidirectional 18 LSP. In packet transport networks, there are requirements where the 19 reverse unidirectional LSP of an associated bidirectional LSP needs 20 to follow the same path as its forward unidirectional LSP. In 21 addition, the associated bidirectional LSP needs to maintain 22 co-routed-ness even after a failure event in the network. This 23 document describes fast reroute procedures for associated 24 bidirectional LSPs that ensure the traffic flows on a co-routed path 25 after a failure event for single-sided provisioning model. 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. Co-routed Bidirectional LSP Association . . . . . . . . . 4 66 3.2. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5 67 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Co-routed Bidirectional LSP Association . . . . . . . . . 6 69 4.2. Fast Reroute For Associated Co-routed Bidirectional LSP . 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 this 89 document, only the single-sided provisioned associated bidirectional 90 LSPs are considered for co-routed-ness. 92 The MPLS Transport Profile (TP) [RFC6370] architecture facilitates 93 the co-routed bidirectional LSP by using the GMPLS extensions 94 [RFC3473] to achieve congruent paths. However, the RSVP association 95 signaling allows to enable co-routed bidirectional LSPs without 96 having to deploy GMPLS extensions in the existing networks. The 97 association signaling also allows to take advantage of the existing 98 Traffic Engineering (TE) mechanisms in the network. 100 In packet transport networks, there are requirements where the 101 reverse LSP of an associated bidirectional LSP needs to follow the 102 same path as its forward LSP [RFC6373]. In addition, the associated 103 bidirectional LSP needs to maintain co-routed-ness even after a 104 failure event in the network. 106 [GMPLS-FRR] defines fast reroute procedure for GMPLS signaled LSPs to 107 co-ordinate bypass tunnel assignments in the forward and reverse 108 directions. The mechanisms defined in [GMPLS-FRR] can be used for 109 fast reroute of the associated bidirectional LSPs. 111 This document describes fast reroute procedures for associated 112 co-routed bidirectional LSPs to ensure the traffic flows on the 113 co-routed path in the forward and reverse direction of the LSP after 114 a failure event. 116 2. Conventions Used in This Document 118 2.1. Key Word Definitions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2.2. Terminology 126 The reader is assumed to be familiar with the terminology in 128 [RFC2205], [RFC3209], [RFC7551], and [RFC4090]. 130 2.2.1. Reverse Co-routed Unidirectional LSPs 132 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 133 opposite directions between a pair of source and destination nodes to 134 form an associated bidirectional LSP. A reverse unidirectional LSP 135 originates on the same node where the forward unidirectional LSP 136 terminates, and it terminates on the same node where the forward 137 unidirectional LSP originates. A reverse co-routed unidirectional 138 LSP traverses along the same path of the forward direction 139 unidirectional LSP in the opposite direction. 141 3. Overview 143 As specified in [RFC7551], in the single-sided provisioning case, the 144 RSVP TE tunnel is configured only on one endpoint node. An LSP for 145 this tunnel is initiated by the originating endpoint with (Extended) 146 ASSOCIATION Object containing Association Type set to "single-sided 147 associated bidirectional LSP" and REVERSE_LSP Object inserted in the 148 Path message. The remote endpoint then creates the corresponding 149 reverse TE tunnel and signals the reverse LSP in response using the 150 information from the REVERSE_LSP Object and other objects present in 151 the received Path message. The reverse LSP thus created may or may 152 not be congruent and follow the same path as its forward LSP. 154 The single-sided associated co-routed bidirectional LSP signaled 155 using the mechanisms defined in [RFC7551] requires solutions for the 156 following issues for fast reroute to ensure co-routed-ness. 158 3.1. Co-routed Bidirectional LSP Association 160 Multiple forward and reverse LSPs of a bidirectional LSP may be 161 present at mid-point nodes with identical (Extended) ASSOCIATION 162 Objects. For example, this can occur while RSVP states are timing 163 out after fast reroute, or during recovery phase in RSVP graceful 164 restart. This creates an ambiguity at mid-point nodes to identify 165 the correct associated LSP pair for fast reroute bypass assignment. 167 LSP3 --> LSP3 --> 168 LSP1 --> LSP1 --> LSP1 --> 169 +-----+ +-----+ +-----+ +-----+ 170 | A +-----------+ B +-----------+ C +-----------+ D | 171 +-----+ +--+--+ +--+--+ +-----+ 172 <-- LSP2 | <-- LSP2 | <-- LSP2 173 <-- LSP4 | | <-- LSP4 174 | | 175 | LSP3 --> | 176 +--+--+ +--+--+ 177 | E +-----------+ F | 178 +-----+ +-----+ 179 <-- LSP4 181 Figure 1: Multiple LSPs with Matching (Extended) ASSOCIATION Object 183 As shown in Figure 1, LSP1 and LSP2 are an associated co-routed LSP 184 pair, similarly LSP3 and LSP4 are an associated co-routed LSP pair, 185 both pairs belong to the same associated bidirectional LSP and carry 186 identical (Extended) ASSOCIATION Objects. In this example, mid-point 187 nodes B and C may mistakenly associate LSP1 with non co-routed 188 reverse LSP4 instead of co-routed reverse LSP3 due to the matching 189 (Extended) ASSOCIATION Objects. 191 3.2. Fast Reroute Bypass Tunnel Assignment 193 In order to ensure that the traffic flows on the co-routed path after 194 a link or node failure on the LSP path, the mid-point Point of Local 195 Repair (PLR) nodes need to assign correct bidirectional co-routed 196 bypass tunnels for fast reroute. Such bypass assignment requires 197 co-ordination between the forward and reverse direction PLR nodes 198 when more than one bypass tunnels are present on a node. 200 +-----+ +-----+ 201 | G +-----------+ H | 202 +--+--+ +--+--+ 203 | | 204 | | 205 LSP1 --> | LSP1 --> | LSP1 --> 206 +-----+ +--+--+ +--+--+ +-----+ 207 | A +-----------+ B +-----------+ C +-----------+ D | 208 +-----+ +--+--+ +--+--+ +-----+ 209 <-- LSP2 | <-- LSP2 | <-- LSP2 210 | | 211 | | 212 +--+--+ +--+--+ 213 | E +-----------+ F | 214 +-----+ +-----+ 216 Figure 2: Multiple Bidirectional Bypass Tunnels 218 As shown in Figure 2, there are two bypass tunnels available, one on 219 path B-G-H-C and other on path B-E-F-C. In order to ensure co- 220 routed-ness, the mid-point PLR nodes B and C need to co-ordinate 221 bypass tunnel assignment to ensure that traffic in both directions 222 flow through either on path B-G-H-C or path B-E-F-C, after the link 223 B-C failure. 225 4. Signaling Procedure 227 4.1. Co-routed Bidirectional LSP Association 229 In order to ensure co-routed-ness, Extended ASSOCIATION Object is 230 used in the RSVP Path message using the procedures defined in 231 [RFC7551] as following. 233 o The originating head-end node MUST add Extended ASSOCIATION Object 234 with Association Type set to "single-sided associated 235 bidirectional LSP" and unique Extended Association ID for each 236 associated forward and reverse LSP pair forming the bidirectional 237 LSP. As an example, a node MAY set the Extended Association ID to 238 the values specified in Section 5.1 of this document. As 239 specified in [RFC7551], the remote endpoint copies the contents of 240 the received Extended ASSOCIATION Object including the Extended 241 Association ID in the RSVP Path message of the reverse LSP's 242 Extended ASSOCIATION Object. 244 o The originating head-end node MUST add an EXPLICIT_ROUTE Object 245 (ERO) in the REVERSE_LSP Object by using the hops traversed by the 246 forward LSP in the reverse order to ensure that reverse LSP 247 follows the same path as forward direction LSP in the opposite 248 direction. As specified in [RFC7551], the remote endpoint builds 249 the ERO of the reverse LSP using the ERO from the received 250 REVERSE_LSP Object of the forward LSP. 252 o When an ERO contains one or more loose next-hop(s), the 253 originating head-end MUST add RECORD_ROUTE Object (RRO) in the 254 Path message of the forward LSP to record the hops traversed by 255 the LSP. The remote endpoint SHOULD use the recorded hops from 256 the RRO in the forward LSP to expand the loose next-hop(s), to 257 ensure that the reverse LSP follows the same path as the forward 258 LSP. 260 4.2. Fast Reroute For Associated Co-routed Bidirectional LSP 262 The mechanisms defined in [GMPLS-FRR] can be used for associated 263 co-routed bidirectional LSP to ensure the traffic flows on a 264 co-routed path in the forward and reverse directions after a link or 265 node failure as following. 267 o As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject is 268 signaled in the RRO of the Path message to co-ordinate bypass 269 tunnel assignment between the forward and reverse direction PLR 270 nodes. A BYPASS_ASSIGNMENT subobject MUST be added by the forward 271 direction PLR node in the Path message of the originating LSP to 272 indicate the bypass tunnel assigned. 274 o The forward direction PLR node always initiates the bypass tunnel 275 assignment for the originating LSP. The reverse direction PLR 276 (forward direction LSP Merge Point (MP)) node simply reflects the 277 bypass tunnel assignment for the reverse direction LSP. 279 o After a link or node failure, the PLR nodes in both forward and 280 reverse directions trigger fast reroute independently using the 281 procedures defined in [RFC4090]. 283 o When using a node protection bypass tunnel, asymmetry of paths can 284 occur in the forward and reverse directions of the bidirectional 285 LSP after a link failure [GMPLS-FRR]. This is corrected using the 286 re-corouting procedure defined in [GMPLS-FRR]. Unlike GMPLS LSPs, 287 the asymmetry of paths does not result in RSVP soft-state time-out 288 with the associated bidirectional LSPs. 290 5. Message and Object Definitions 292 5.1. Extended ASSOCIATION Object 294 The Extended Association ID in the Extended ASSOCIATION Object can be 295 set by the originating node to the value specified as following when 296 the associated bidirectional LSP is co-routed. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | IPv4 LSP Source Address | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Reserved | LSP-ID | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 : : 307 : Variable Length ID : 308 : : 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 3: IPv4 Extended Association ID 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 + + 318 | IPv6 LSP Source Address | 319 + + 320 | (16 bytes) | 321 + + 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Reserved | LSP-ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 : : 327 : Variable Length ID : 328 : : 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 4: IPv6 Extended Association ID 333 LSP Source Address 335 IPv4/IPv6 source address of the originating LSP. 337 LSP-ID 339 16-bits LSP-ID of the originating LSP. 341 Variable Length ID 343 Variable length ID inserted by the originating node of the 344 Associated co-routed bidirectional LSP. 346 6. Compatibility 348 This document describes the procedures for fast reroute for 349 associated co-routed bidirectional LSPs. Operators wishing to use 350 this function SHOULD ensure that it is supported on the nodes on the 351 LSP path. 353 7. Security Considerations 355 This document uses signaling mechanisms defined in [RFC7551] and 356 [GMPLS-FRR] and does not introduce any additional security 357 considerations other than already covered in [RFC7551], [GMPLS-FRR] 358 and the MPLS/GMPLS security framework [RFC5920]. 360 8. IANA Considerations 362 This document does not make any request for IANA action. 364 9. References 366 9.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 372 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 373 Functional Specification", RFC 2205, September 1997. 375 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 376 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 377 May 2005. 379 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 380 Association Object Extensions", RFC 6780, October 2012. 382 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 383 Extensions for Associated Bidirectional LSPs", RFC 7551, 384 May 2015. 386 [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., 387 Bhatia, M., "Extensions to Resource Reservation Protocol 388 For Fast Reroute of Traffic Engineering GMPLS LSPs", 389 draft-ietf-teas-gmpls-lsp-fastreroute, work in progress. 391 9.2. Informative References 393 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 394 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 395 Tunnels", RFC 3209, December 2001. 397 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 398 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 399 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 401 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 402 Networks", RFC 5920, July 2010. 404 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 405 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 407 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 408 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 409 Framework", RFC 6373, September 2011. 411 Authors' Addresses 413 Rakesh Gandhi (editor) 414 Cisco Systems, Inc. 416 EMail: rgandhi@cisco.com 418 Himanshu Shah 419 Ciena 421 EMail: hshah@ciena.com 423 Jeremy Whittaker 424 Verizon 426 EMail: jeremy.whittaker@verizon.com