idnits 2.17.1 draft-gandhishah-teas-assoc-corouted-bidir-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 (September 10, 2016) is 2778 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: March 14, 2017 Ciena 6 Jeremy Whittaker 7 Verizon 8 September 10, 2016 10 Fast Reroute Procedures For Associated Co-routed Bidirectional 11 Label Switched Paths (LSPs) 12 draft-gandhishah-teas-assoc-corouted-bidir-02 14 Abstract 16 In packet transport networks, there are requirements where reverse 17 unidirectional LSP of a bidirectional LSP needs to follow the same 18 path as its forward unidirectional LSP. The bidirectional LSP needs 19 to maintain co-routed-ness even after a failure event in the network. 20 This document describes RSVP signaling to unambiguously bind two co- 21 routed point-to-point LSPs into an associated co-routed bidirectional 22 LSP. Fast-reroute procedures are defined to ensure that the traffic 23 flows on the co-routed path after a failure event. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 59 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 60 2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Message and Object Definitions . . . . . . . . . . . . . . . . 6 63 4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 6 64 5. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Co-routed Bidirectional LSP Association . . . . . . . . . 7 66 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP . 8 67 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 In packet transport networks, there are requirements where a reverse 78 Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) of a 79 bidirectional LSP needs to follow the same path as its forward LSP 80 [RFC6373]. The bidirectional LSP needs to maintain co-routed-ness 81 even after a failure event in the network. 83 The Resource Reservation Protocol (RSVP) Extended ASSOCIATION Object 84 is specified in [RFC6780] which can be used generically to associate 85 (G)MPLS 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 for provisioning the 88 bidirectional LSP, single-sided and double-sided. Only the single- 89 sided provisioned bidirectional LSPs are considered in this document 90 for providing fast-reroute for the co-routed bidirectional LSPs. 92 The MPLS Transport Profile (TP) [RFC6370] architecture facilitates 93 the co-routed bidirectional LSP by using GMPLS extensions [RFC3473] 94 to achieve congruent paths. However, the RSVP association signaling 95 allows to enable co-routed bidirectional LSPs without having to 96 deploy GMPLS extensions in the existing networks. The association 97 signaling also allows to take advantage of the existing Traffic 98 Engineering (TE) mechanisms in the network. 100 [GMPLS-FRR] defines fast-reroute procedures for GMPLS signaled LSPs 101 to ensure traffic flows on a co-routed path after a failure event on 102 the LSP path. [GMPLS-FRR] defined fast-reroute mechanisms are 103 equally applicable to the associated co-routed bidirectional LSPs. 105 This document describes how Extended ASSOCIATION Object can be used 106 to unambiguously bind two reverse co-routed unidirectional LSPs into 107 an associated co-routed bidirectional LSP in the single-sided 108 provisioning case. Fast-reroute procedures are defined to ensure the 109 traffic flows on the co-routed path after a failure event. 111 2. Conventions Used in This Document 113 2.1. Key Word Definitions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2.2. Reverse Co-routed Unidirectional LSPs 121 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 122 opposite directions between a pair of source and destination nodes to 123 form an associated bidirectional LSP. A reverse unidirectional LSP 124 originates on the same node where the forward unidirectional LSP 125 terminates, and it terminates on the same node where the forward 126 unidirectional LSP originates. A reverse co-routed unidirectional 127 LSP traverses along the same path of the forward direction 128 unidirectional LSP in the opposite direction. 130 3. Overview 132 As specified in [RFC7551], in the single-sided provisioning case, the 133 RSVP Traffic Engineering (TE) tunnel is configured only on one 134 endpoint node. An LSP for this tunnel is initiated by the 135 originating endpoint with Extended ASSOCIATION Object containing 136 Association Type set to "single-sided associated bidirectional LSP" 137 and REVERSE_LSP Object inserted in the Path message. The remote 138 endpoint then creates the corresponding reverse TE tunnel and signals 139 the reverse LSP in response using the information from the 140 REVERSE_LSP Object and other objects present in the received Path 141 message. The reverse LSP thus created may or may not be congruent 142 and follow the same path as its forward LSP. 144 LSP1 --> LSP1 --> LSP1 --> 145 +-----+ +-----+ +-----+ +-----+ 146 | A +-----------+ B +-----------+ C |-----------+ D | 147 +-----+ +-----+ +-----+ +-----+ 148 <-- LSP2 <-- LSP2 <-- LSP2 150 Figure 1a: An Example of Associated Co-routed Bidirectional LSP 152 As shown in Figure 1a, LSP1 is provisioned on the originating 153 endpoint A. The creation of reverse LSP2 on the remote endpoint D is 154 triggered by the LSP1. LSP2 follows the path in the reverse 155 direction using the EXPLICIT_ROUTE Object (ERO) from the received 156 REVERSE_LSP Object in the Path message of LSP1 [RFC7551]. 158 For co-routed bidirectional LSP, the originating endpoint A can 159 ensure that the reverse LSP follows the same path as the forward LSP 160 (e.g. A-B-C-D) by populating the ERO in the REVERSE_LSP Object using 161 the hops traversed by the forward LSP in the reverse order (e.g. D-C- 162 B-A). 164 For fast-reroute, the associated co-routed bidirectional LSP signaled 165 using mechanisms defined in [RFC7551] requires solutions for the 166 following issues: 168 o Multiple forward and reverse LSPs of a bidirectional LSP may be 169 present at mid-point nodes with identical Extended ASSOCIATION 170 Objects. As examples, this can happen while RSVP states are timing 171 out, during recovery phase in RSVP graceful restart, etc. This 172 creates an ambiguity at mid-point nodes to identify the correct 173 associated LSP pair that can lead to undesirable fast-reroute bypass 174 assignment. 176 As shown in Figure 1b, LSP1 and LSP2 are an associated co-routed LSP 177 pair, similarly LSP3 and LSP4 are an associated co-routed LSP pair, 178 both pairs belong to the same associated bidirectional LSP and carry 179 identical Extended ASSOCIATION Objects. In this example, mid-point 180 nodes B and C may mistakenly associate LSP1 with non co-routed 181 reverse LSP4 instead of co-routed reverse LSP3 due to the matching 182 Extended ASSOCIATION Objects. 184 In order to ensure co-routed-ness, the mid-point nodes must 185 unambiguously identify the correct matching co-routed associated 186 forward and reverse LSP pair. To ensure this, the Extended 187 ASSOCIATION Object needs to be unique per associated co-routed 188 forward and reverse LSP pair. 190 LSP3 --> LSP3 --> 191 LSP1 --> LSP1 --> LSP1 --> 192 +-----+ +-----+ +-----+ +-----+ 193 | A +-----------+ B +-----------+ C |-----------+ D | 194 +-----+ +-----+ +-----+ +-----+ 195 <--LSP2 | <-- LSP2 | <-- LSP2 196 <--LSP4 | | <-- LSP4 197 | | 198 | LSP3 --> | 199 +-----+ +-----+ 200 + E +-----------+ F | 201 +-----+ +-----+ 202 <-- LSP4 204 Figure 1b: Example of LSPs with matching Extended ASSOCIATION Objects 206 o The ERO for the reverse LSP signaled by the originating endpoint 207 may contain loose next-hop(s) in case of loosely routed LSPs (e.g. 208 inter-domain LSPs). For co-routed bidirectional LSP, the mid-point 209 and endpoint nodes need to ensure that the loose next-hop expansion 210 for the reverse LSP is on the co-routed path as its forward LSP. To 211 achieve this, the expanding node may require the recorded path of the 212 forward LSP. 214 o In order to ensure that the traffic flows on the co-routed path 215 after a link or node failure on the LSP path, the mid-point Point of 216 Local Repair (PLR) nodes need to identify the correct matching pair 217 and know that it is co-routed. This way PLR nodes can assign 218 bidirectional co-routed bypass tunnels for fast-reroute. Such bypass 219 assignment requires co-ordination between the forward and reverse 220 direction PLR nodes. 222 4. Message and Object Definitions 224 4.1. Extended ASSOCIATION Object 226 The Extended ASSOCIATION Object is populated using the rules defined 227 in [RFC7551] for the Association Type "single-sided associated 228 bidirectional LSP". 230 The Extended Association ID is set by the originating node to the 231 value specified as following when the associated bidirectional LSP is 232 co-routed. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | IPv4 LSP Source Address | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Reserved | LSP-ID | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 : : 242 : Variable Length Extended ID : 243 : : 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2: IPv4 Extended Association ID Format 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 + + 253 | IPv6 LSP Source Address | 254 + + 255 | (16 bytes) | 256 + + 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Reserved | LSP-ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 : : 262 : Variable Length Extended ID : 263 : : 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 3: IPv6 Extended Association ID Format 268 LSP Source Address 270 IPv4/IPv6 source address of the originating LSP. 272 LSP-ID 274 16-bits LSP-ID of the originating LSP. 276 Variable Length Extended ID 278 Variable length Extended ID inserted by the originating node of 279 the Associated co-routed bidirectional LSP. 281 5. Signaling Procedure 283 5.1. Co-routed Bidirectional LSP Association 285 In general, the processing rules for the Extended ASSOCIATION Object 286 as specified in [RFC6780] and [RFC7551] are followed for co-routed 287 bidirectional LSP association. 289 The originating head-end node MUST add Extended ASSOCIATION Object 290 with Association Type set to "single-sided associated bidirectional 291 LSP" and the Extended Association ID set to the values specified in 292 Section 4.1 of this document in the RSVP Path message. The Extended 293 Association ID thus added allows to identify each associated LSP pair 294 of the associated co-routed bidirectional LSP. The presence of 295 Extended Association ID in this format indicates the nodes on the LSP 296 path that the bidirectional LSP is co-routed. In addition, the 297 originating head-end node MUST add EXPLICIT_ROUTE Object (ERO) in the 298 REVERSE_LSP Object by using the hops traversed by the forward LSP in 299 the reverse order to ensure that reverse LSP follows the same path as 300 forward direction LSP in the opposite direction. When the ERO 301 contains one or more loose next-hop(s), the originating endpoint MUST 302 add RECORD_ROUTE Object (RRO) in the Path message of the forward LSP 303 to record the hops traversed by the LSP. 305 As defined in [RFC7551], the remote endpoint simply copies the 306 contents of the received Extended ASSOCIATION Object including the 307 Extended Association ID in the Path message of the reverse LSP's 308 Extended ASSOCIATION Object. In addition, the remote endpoint builds 309 the ERO of the reverse LSP using the ERO from the received 310 REVERSE_LSP Object of the forward LSP. If ERO contains one or more 311 loose next-hop(s), the remote endpoint SHOULD use the recorded hops 312 from the RRO in the forward LSP to expand the loose next-hop(s), to 313 ensure that the reverse LSP follows the same path as the forward LSP. 315 As contents of the Extended ASSOCIATION Objects are unique for each 316 associated LSP pair of the associated co-routed bidirectional LSP, a 317 mid-point node can unambiguously identify the associated LSP pair by 318 matching their Extended ASSOCIATION Objects. When a mid-point node 319 needs to expand the loose next-hop in the ERO, it SHOULD use the 320 recorded hops from the RRO in the forward LSP to ensure that the 321 reverse LSP is co-routed and follows the same path as its forward 322 LSP. 324 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP 326 The procedures defined in [GMPLS-FRR] are used for associated 327 co-routed bidirectional LSP to ensure that the traffic flows on a 328 co-routed path after a link or node failure. 330 As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in the RRO 331 is signaled to co-ordinate bypass tunnel assignment between its 332 forward and reverse direction PLR nodes. This subobject MUST be 333 added by the forward direction PLR node in the Path message of the 334 originating LSP. The forward direction PLR node always initiates the 335 bypass tunnel assignment for the originating LSP. The reverse 336 direction PLR (forward direction LSP Merge Point (MP)) node simply 337 reflects the bypass tunnel assignment for the reverse direction LSP 338 on the co-routed path. 340 After a link or node failure, PLR nodes in both directions trigger 341 fast-reroute independently using the procedures defined in [RFC4090]. 342 As specified in [GMPLS-FRR], reverse direction PLR node triggers the 343 fast-reroute in the reverse direction on the matching associated co- 344 routed bypass tunnel to ensure that both traffic and RSVP signaling 345 flow on the co-routed path after the failure. 347 6. Compatibility 349 The Extended ASSOCIATION Object has been defined in [RFC6780], with 350 class number in the form 11bbbbbb, which ensures compatibility with 351 non-supporting nodes. Per [RFC2205], such nodes will ignore the 352 object but forward it without modification. 354 This document defines the procedures for fast-reroute for associated 355 co-routed bidirectional LSPs. Operators wishing to use this function 356 SHOULD ensure that it is supported on the nodes on the LSP path. The 357 Extended Association ID defined in this document is backwards 358 compatible with the functions defined in [RFC7551] and [RFC6780]. 360 7. Security Considerations 362 This document uses signaling mechanisms defined in [RFC7551] and 363 [GMPLS-FRR] and does not introduce any additional security 364 considerations other than already covered in [RFC7551], [GMPLS-FRR] 365 and the MPLS/GMPLS security framework [RFC5920]. 367 Using the Extended Association ID in the intercepted signalling 368 message, a node may be able to get additional information of the LSP 369 such as co-routed type and the originating node. This is judged to 370 be a very minor security risk as this information is already 371 available by other means. 373 8. IANA Considerations 375 This document does not make any request for IANA action. 377 9. References 379 9.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 385 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 386 Functional Specification", RFC 2205, September 1997. 388 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 389 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 390 May 2005. 392 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 393 Association Object Extensions", RFC 6780, October 2012. 395 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 396 Extensions for Associated Bidirectional LSPs", RFC 7551, 397 May 2015. 399 [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., 400 "Extensions to Resource Reservation Protocol For Fast 401 Reroute of Traffic Engineering GMPLS LSPs", draft-ietf- 402 teas-gmpls-lsp-fastreroute, work in progress. 404 9.2. Informative References 406 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 407 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 408 Tunnels", RFC 3209, December 2001. 410 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 411 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 412 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 414 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 415 Networks", RFC 5920, July 2010. 417 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 418 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 420 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 421 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 422 Framework", RFC 6373, September 2011. 424 Authors' Addresses 426 Rakesh Gandhi (editor) 427 Cisco Systems, Inc. 429 EMail: rgandhi@cisco.com 431 Himanshu Shah 432 Ciena 434 EMail: hshah@ciena.com 436 Jeremy Whittaker 437 Verizon 439 EMail: jeremy.whittaker@verizon.com