idnits 2.17.1 draft-gandhishah-teas-assoc-corouted-bidir-01.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 15, 2016) is 2957 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: September 16, 2016 Ciena 6 Jeremy Whittaker 7 Verizon 8 March 15, 2016 10 RSVP-TE Extensions For Associated Co-routed Bidirectional 11 Label Switched Paths (LSPs) 12 draft-gandhishah-teas-assoc-corouted-bidir-01 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. This document describes how 19 the RSVP association signaling is used to bind two co-routed 20 point-to-point unidirectional LSPs into an associated co-routed 21 bidirectional LSP in single-sided provisioning case. Fast-reroute 22 procedures are defined to ensure that the traffic flows on the 23 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 . . . . . . . . . . . . . . . . 5 63 4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 5 64 5. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Co-routed Bidirectional LSP Association . . . . . . . . . 6 66 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP . 7 67 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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]. 82 The Resource Reservation Protocol (RSVP) Extended ASSOCIATION Object 83 is specified in [RFC6780] which can be used generically to associate 84 (G)MPLS LSPs. [RFC7551] defines mechanisms for binding two point-to- 85 point unidirectional LSPs [RFC3209] into an associated bidirectional 86 LSP. There are two models described for provisioning the 87 bidirectional LSP, single-sided and double-sided. Only the single- 88 sided provisioned bidirectional LSPs are considered in this document. 90 The MPLS Transport Profile (TP) [RFC6370] architecture facilitates 91 the co-routed bidirectional LSP by using GMPLS extensions [RFC3473] 92 to achieve congruent paths. However, the RSVP association signaling 93 allows to enable co-routed bidirectional LSPs without having to 94 deploy GMPLS extensions in the existing networks. The association 95 signaling also allows to take advantage of the existing Traffic 96 Engineering (TE) mechanisms in the network. 98 [GMPLS-FRR] defines fast-reroute procedures for GMPLS signaled LSPs 99 to ensure traffic flows on a co-routed path after a failure event on 100 the primary LSP path. [GMPLS-FRR] defined fast-reroute mechanisms 101 are equally applicable to the associated co-routed bidirectional 102 LSPs. 104 This document describes how Extended ASSOCIATION Object is used to 105 bind two reverse co-routed unidirectional LSPs into an associated 106 co-routed bidirectional LSP in single-sided provisioning case. 107 Fast-reroute procedures are defined to ensure the traffic flows on 108 the co-routed path after a failure event. 110 2. Conventions Used in This Document 112 2.1. Key Word Definitions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2.2. Reverse Co-routed Unidirectional LSPs 120 Two reverse unidirectional point-to-point (P2P) LSPs are setup in the 121 opposite directions between a pair of source and destination nodes to 122 form an associated bidirectional LSP. A reverse unidirectional LSP 123 originates on the same node where the forward unidirectional LSP 124 terminates, and it terminates on the same node where the forward 125 unidirectional LSP originates. A reverse co-routed unidirectional 126 LSP traverses along the same path of the forward direction 127 unidirectional LSP in the opposite direction. 129 3. Overview 131 As specified in [RFC7551], in single-sided provisioning case, the 132 RSVP Traffic Engineering (TE) tunnel is configured only on one 133 endpoint. An LSP for this tunnel is initiated by the originating 134 endpoint with Extended ASSOCIATION Object containing Association Type 135 set to "single-sided associated bidirectional LSP" and REVERSE_LSP 136 Object inserted in the Path message. The remote endpoint then 137 creates the corresponding reverse TE tunnel and signals the reverse 138 LSP in response using information from the REVERSE_LSP Object and 139 other objects present in the received Path message. The reverse LSP 140 thus created may or may not be congruent i.e. follow the same path as 141 its forward LSP. 143 LSP1 --> 144 +-----+ +-----+ +-----+ +-----+ 145 | A +-----------+ B +-----------+ C |-----------+ D | 146 +-----+ +-----+ +-----+ +-----+ 147 <-- LSP2 149 Figure 1: An Example of Associated Co-routed Bidirectional LSP 151 As shown in Figure 1, LSP1 is provisioned on the originating endpoint 152 A. The creation of reverse LSP2 on the remote endpoint D is 153 triggered by the LSP1. LSP2 follows the path in the reverse 154 direction using the EXPLICIT_ROUTE Object (ERO) from the received 155 REVERSE_LSP Object in the Path message of LSP1 [RFC7551]. 157 For co-routed bidirectional LSP, the originating endpoint A can 158 ensure that the reverse LSP follows the same path as the forward LSP 159 (e.g. A-B-C-D) by populating the ERO in the REVERSE_LSP Object using 160 the hops traversed by the forward LSP in the reverse order (e.g. D-C- 161 B-A). 163 The associated co-routed bidirectional LSP when using above 164 mechanisms defined in [RFC7551] requires solutions for the following 165 issues: 167 o Multiple forward and reverse LSPs of a bidirectional LSP may be 168 present at mid-point nodes with identical Extended ASSOCIATION 169 Objects. In order to ensure co-routed-ness, the mid-point node must 170 identify the correct matching co-routed associated forward and 171 reverse LSPs. To ensure this, additional information is required in 172 the Extended ASSOCIATION Object that is unique per co-routed 173 associated forward and reverse LSPs. 175 o The ERO for the reverse LSP signaled by the originating endpoint 176 may contain loose next-hop(s) in case of loosely routed LSPs (e.g. 177 inter-domain LSPs). The mid-point and endpoint nodes need to ensure 178 that the loose next-hop expansion for the reverse LSP is on the co- 179 routed path for the bidirectional LSP. As such, an expanding node 180 may require the recorded path of the forward LSP. 182 o In order to ensure that the traffic flows on the co-routed path 183 after a link or node failure on the LSP path, the mid-point Point of 184 Local Repair (PLR) nodes need to know that the associated 185 bidirectional LSP is co-routed. This way mid-point PLR nodes can 186 assign co-routed bidirectional bypass tunnels for fast-reroute. Such 187 bypass assignment also requires co-ordination between the forward and 188 reverse direction PLR nodes. 190 4. Message and Object Definitions 192 4.1. Extended ASSOCIATION Object 194 The Extended ASSOCIATION Object is populated using the rules defined 195 in [RFC7551] for the Association Type "single-sided associated 196 bidirectional LSP". 198 The Extended Association ID is set by the originating node to the 199 value specified as following. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | LSP Source Address | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Flags | LSP-ID | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: IPv4 Extended Association ID Format 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | LSP Source Address | 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Flags | LSP-ID | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 3: IPv6 Extended Association ID Format 223 LSP Source Address 225 IPv4/IPv6 source address of the originating LSP. 227 LSP-ID 229 16-bits LSP-ID of the originating LSP. 231 Flags 233 Bit 0: COROUTED-LSP: When set, this flag indicates the associated 234 bidirectional LSP is co-routed. 236 Bit 1-15: Not used. Must be set to 0. 238 5. Signaling Procedure 240 5.1. Co-routed Bidirectional LSP Association 242 In general, the processing rules for the Extended ASSOCIATION Object 243 as specified in [RFC6780] and [RFC7551] are followed for co-routed 244 bidirectional LSP association. 246 The originating head-end node MUST add Extended ASSOCIATION Object 247 with Association Type set to "single-sided associated bidirectional 248 LSP" and the extended association ID set to the value specified in 249 Section 4.1 of this document in the RSVP Path message. The COROUTED- 250 LSP flag MUST be set to indicate the nodes on the LSP path that the 251 bidirectional LSP is co-routed. In addition, the originating head- 252 end node MUST add EXPLICIT_ROUTE Object (ERO) in the REVERSE_LSP 253 Object by using the hops traversed by the forward LSP in the reverse 254 order to ensure that reverse LSP follows the same path as forward 255 direction LSP in the opposite direction. When the ERO contains one 256 or more loose next-hop(s), the originating endpoint MUST add 257 RECORD_ROUTE Object (RRO) in the Path message of the forward LSP to 258 record the hops traversed by the LSP. 260 As defined in [RFC7551], the remote endpoint simply copies the 261 contents of the received Extended ASSOCIATION Object including the 262 extended association ID in the Path message of the reverse LSP's 263 Extended ASSOCIATION Object. In addition, the remote endpoint builds 264 the ERO of the reverse LSP using the ERO from the received 265 REVERSE_LSP Object of the forward LSP. If ERO contains one or more 266 loose next-hop(s), the remote endpoint SHOULD use the recorded hops 267 from the RRO in the forward LSP to expand the loose next-hop(s), to 268 ensure that the reverse LSP follows the same path as the forward LSP. 270 As contents of the Extended ASSOCIATION Objects are unique for each 271 associated co-routed bidirectional LSP, a transit node can 272 unambiguously identify the associated LSP pair by matching their 273 Extended ASSOCIATION Objects. At a transit LSR, reverse LSP can 274 identify the matching forward LSP by checking the originating LSP 275 source address and LSP-ID in the extended association ID. When a 276 transit node needs to expand the loose next-hop in the ERO, it SHOULD 277 use the recorded hops from the RRO in the forward LSP to ensure that 278 the reverse LSP is co-routed. 280 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP 282 The procedures defined in [GMPLS-FRR] are used for associated 283 co-routed bidirectional LSP to ensure that the traffic flows on a 284 co-routed path after a link or node failure. The COROUTED-LSP flag 285 is used by the Point of Local Repair (PLR) nodes to provide fast- 286 reroute protection using associated co-routed bypass tunnels. 288 As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in the RRO 289 is used to co-ordinate bypass tunnel assignment between a forward and 290 reverse direction PLR nodes. This subobject MUST be added by the 291 forward direction PLR node in the Path message of the originating 292 LSP. The forward direction PLR node always initiates the bypass 293 tunnel assignment for the originating LSP. The reverse direction PLR 294 (forward direction LSP Merge Point (MP)) node simply reflects the 295 bypass tunnel assignment for the reverse direction LSP on the 296 co-routed path. 298 After a link or node failure, PLR nodes in both directions trigger 299 fast-reroute independently using the procedures defined in [RFC4090]. 301 As specified in [GMPLS-FRR], re-corouting procedure can be used to 302 reroute the traffic in the reverse direction on the co-routed bypass 303 tunnel path. Reverse direction PLR node will assume the role of 304 Point of Remote Repair (PRR) and trigger the fast-reroute in the 305 reverse direction on the matching associated co-routed bypass tunnel 306 to ensure that both traffic and RSVP signaling flow on the co-routed 307 path after the failure. 309 6. Compatibility 311 The Extended ASSOCIATION Object has been defined in [RFC6780], with 312 class number in the form 11bbbbbb, which ensures compatibility with 313 non-supporting nodes. Per [RFC2205], such nodes will ignore the 314 object but forward it without modification. 316 This document defines the content of the Extended Association ID for 317 the Extended ASSOCIATION Object for co-routed bidirectional LSPs. 318 Operators wishing to use this function SHOULD ensure that it is 319 supported on the node that is expected to act on the association. 321 7. Security Considerations 323 This document uses signaling mechanisms defined in [RFC7551] and 324 [GMPLS-FRR] and does not introduce any additional security 325 considerations other than already covered in [RFC7551], [GMPLS-FRR] 326 and the MPLS/GMPLS security framework [RFC5920]. 328 Using the extended association ID in the intercepted signalling 329 message, a node may be able to get additional information of the LSP 330 such as co-routed type and the originating node. This is judged to 331 be a very minor security risk as this information is already 332 available by other means. 334 8. IANA Considerations 336 This document does not make any request for IANA action. 338 9. References 340 9.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 346 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 347 Functional Specification", RFC 2205, September 1997. 349 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 350 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 351 May 2005. 353 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 354 Association Object Extensions", RFC 6780, October 2012. 356 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 357 Extensions for Associated Bidirectional LSPs", RFC 7551, 358 May 2015. 360 [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., 361 Bhatia, M., Jin, L., "Extensions to Resource Reservation 362 Protocol For Fast Reroute of Traffic Engineering GMPLS 363 LSPs", draft-ietf-teas-gmpls-lsp-fastreroute. 365 9.2. Informative References 367 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 368 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 369 Tunnels", RFC 3209, December 2001. 371 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 372 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 373 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 375 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 376 Networks", RFC 5920, July 2010. 378 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 379 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 381 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 382 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 383 Framework", RFC 6373, September 2011. 385 Authors' Addresses 387 Rakesh Gandhi (editor) 388 Cisco Systems, Inc. 390 EMail: rgandhi@cisco.com 392 Himanshu Shah 393 Ciena 395 EMail: hshah@ciena.com 397 Jeremy Whittaker 398 Verizon 400 EMail: jeremy.whittaker@verizon.com