idnits 2.17.1 draft-gandhi-shah-teas-assoc-corouted-bidir-00.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 (January 11, 2016) is 3000 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) == Missing Reference: 'RFC4090' is mentioned on line 264, but not defined == Unused Reference: 'RFC3209' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC6689' is defined on line 347, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-teas-gmpls-lsp-fastreroute-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 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: July 14, 2016 Ciena 6 Jeremy Whittaker 7 Verizon 8 January 11, 2016 10 RSVP-TE Extensions For Associated Co-routed Bidirectional 11 Label Switched Paths (LSPs) 12 draft-gandhi-shah-teas-assoc-corouted-bidir-00 14 Abstract 16 In 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 RSVP Extended ASSOCIATION Object can be 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. The RSVP 22 REVERSE_LSP Object is used to enable an endpoint to trigger creation 23 of the reverse LSP along the same path as the forward LSP. 24 Fast-reroute procedures to ensure that the traffic flows on the co- 25 routed path after a failure event are also described. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 67 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 68 2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . . . 3 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Message and Object Definitions . . . . . . . . . . . . . . . . 4 71 4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 4 72 5. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Co-routed Bidirectional LSP Association . . . . . . . . . 6 74 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP . 6 75 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 In transport networks, there are requirements where a reverse LSP of 86 a bidirectional LSP needs to follow the same path as its forward LSP 87 [RFC6373]. 89 The RSVP Extended ASSOCIATION Object is specified in [RFC6780] which 90 can be used generically to associate (G)MPLS LSPs. [RFC7551] defines 91 mechanisms for binding two point-to-point unidirectional LSPs into an 92 associated bidirectional LSP. There are two models described for 93 provisioning the LSP, single-sided and double-sided. The double- 94 sided provisioned bidirectional LSPs are not considered in this 95 document. 97 The MPLS TP [RFC6370] architecture facilitates the co-routed 98 bidirectional LSP by using GMPLS extensions to achieve congruent 99 paths. The RSVP association signaling allows to take advantages of 100 the co-routed bidirectional LSPs without having to deploy GMPLS 101 extensions in the existing networks. The association signaling also 102 allows to take advantage of the existing fast-reroute mechanisms. 104 [GMPLS-FRR] defines fast-reroute procedures for GMPLS signaled LSPs 105 to ensure traffic flows on a co-routed path after a failure event on 106 the primary LSP path. [GMPLS-FRR] does not define fast-reroute 107 mechanisms for associated co-routed bidirectional LSPs. 109 This document describes how Extended ASSOCIATION Object can be used 110 to bind two reverse co-routed unidirectional LSPs into an associated 111 co-routed bidirectional LSP in single-sided provisioning case. The 112 REVERSE_LSP Object is used to enable an endpoint to trigger creation 113 of the reverse LSP along the same path as the forward LSP. Fast- 114 reroute procedures to ensure that the traffic flows on the co-routed 115 path after a failure event are also described. 117 2. Conventions Used in This Document 119 2.1. Key Word Definitions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2.2. Reverse Co-routed Unidirectional LSPs 127 Two reverse unidirectional LSPs are setup in the opposite directions 128 between a pair of source and destination nodes to form an associated 129 bidirectional LSP. A reverse unidirectional LSP originates on the 130 same node where the forward unidirectional LSP terminates, and it 131 terminates on the same node where the forward unidirectional LSP 132 originates. A reverse co-routed unidirectional LSP traverses along 133 the same path of the forward direction unidirectional LSP in the 134 opposite direction. 136 3. Overview 138 For single-sided provisioning, the Traffic Engineering (TE) tunnel is 139 configured only on one endpoint. An LSP for this tunnel is initiated 140 by the originating endpoint with Extended ASSOCIATION Object 141 containing Association Type set to "single-sided associated 142 bidirectional LSP" and REVERSE_LSP Object inserted in the Path 143 message. The remote endpoint then creates the corresponding reverse 144 TE tunnel and signals the reverse LSP in response using information 145 from the REVERSE_LSP Object and other objects present in the received 146 Path message [RFC7551]. The reverse LSP thus created may or may not 147 be congruent. 149 LSP1 --> 150 +-----+ +-----+ +-----+ 151 | A +-----------+ C +-----------+ B | 152 +-----+ +-----+ +-----+ 153 <-- LSP2 155 Figure 1: An Example of Associated Co-routed Bidirectional LSP 157 As shown in Figure 1, creation of reverse LSP2 on remote endpoint B 158 is triggered by LSP1. LSP2 follows the path in the reverse direction 159 using the EXPLICIT_ROUTE Object (ERO) from the received REVERSE_LSP 160 Object in LSP1. 162 For co-routed bidirectional LSP, the originating endpoint A ensures 163 the reverse LSP follow the same path as the forward LSP by populating 164 EXPLICIT_ROUTE Object in the REVERSE_LSP Object using the hops 165 traversed by the forward LSP in the reverse order. 167 4. Message and Object Definitions 169 4.1. Extended ASSOCIATION Object 171 The Extended ASSOCIATION Object is populated using the rules defined 172 in [RFC7551] for the Association Type "single-sided associated 173 bidirectional LSP". 175 The Extended Association ID is set by the originating node to the 176 value specified as following. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | LSP Source Address | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Flags | LSP-ID | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 2: IPv4 Extended Association ID Format 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | LSP Source Address | 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Flags | LSP-ID | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 3: IPv6 Extended Association ID Format 200 LSP Source Address 202 IPv4/IPv6 source address of the originating LSP. 204 LSP-ID 206 16-bits LSP-ID of the originating LSP. 208 Flags 210 Bit 0: COROUTED-LSP-FLAG: When set, this flag indicates the 211 associated bidirectional LSP is co-routed. 213 Bit 1-15: Not used. Must be set to 0. 215 5. Signaling Procedure 217 5.1. Co-routed Bidirectional LSP Association 219 In general, the processing rules for the Extended ASSOCIATION Object 220 as specified in [RFC6780] and [RFC7551] are followed for co-routed 221 bidirectional LSP association. 223 The originating head-end MUST add Extended ASSOCIATION Object with 224 Association Type set to "single-sided associated bidirectional LSP" 225 and the extended association ID as specified in Section 4.1 of this 226 document. The COROUTED-LSP-FLAG MUST be set to indicate the nodes on 227 the LSP path that bidirectional LSP is co-routed. In addition, the 228 originating head-end node MUST add EXPLICIT_ROUTE Object (ERO) in the 229 REVERSE_LSP Object by using the hops traversed by the forward LSP in 230 the reverse order to ensure that reverse LSP follows the same path as 231 forward direction LSP in the opposite direction. 233 As defined in [RFC7551], the remote endpoint simply copies the 234 content of the received Extended ASSOCIATION Object including the 235 extended association ID in the reverse LSP Extended ASSOCIATION 236 Object. In addition, the remote endpoint builds the ERO of the 237 reverse LSP using the ERO from the received REVERSE_LSP Object of the 238 forward LSP. 240 As contents of the Extended ASSOCIATION Object are unique for each 241 associated co-routed bidirectional LSP, a node can unambiguously 242 identify the associated LSP pair by matching their Extended 243 ASSOCIATION Objects. In addition, a node can identify an originating 244 (forward) LSP by matching the LSP source address with the source 245 address in the extended association ID. 247 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP 249 The procedures defined in [GMPLS-FRR] are used for associated co- 250 routed bidirectional LSP to ensure that traffic flows on a co-routed 251 path after a link or node failure. The COROUTED-LSP-FLAG is used by 252 the PLR nodes to provide fast-reroute protection using associated co- 253 routed bypass tunnels. 255 As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in RRO is 256 used to co-ordinate bypass tunnel assignment between a forward and 257 reverse direction PLRs. This subobject MUST be added by the forward 258 direction PLR in the Path message of the originating LSP. The 259 reverse direction PLR (forward direction LSP MP) simply reflects the 260 bypass tunnel assignment for the reverse direction LSP on the co- 261 routed path. 263 After a link or node failure, PLRs in both directions trigger fast- 264 reroute independently using the procedures defined in [RFC4090]. 266 As specified in [GMPLS-FRR], re-corouting procedure can be used to 267 reroute the traffic in the reverse direction on the co-routed bypass 268 tunnel path. Reverse direction PLR will assume the role of PRR and 269 trigger the fast-reroute in the reverse direction on the matching co- 270 routed bypass tunnel to ensure that both traffic and RSVP signaling 271 flow on the co-routed path after the failure. 273 6. Compatibility 275 The Extended ASSOCIATION Object has been defined in [RFC6780], with 276 class number in the form 11bbbbbb, which ensures compatibility with 277 non-supporting nodes. Per [RFC2205], such nodes will ignore the 278 object but forward it without modification. 280 This document defines the content of the Extended Association ID for 281 the Extended ASSOCIATION Object for co-routed bidirectional LSPs. 282 Operators wishing to use this function SHOULD ensure that it is 283 supported on the node that is expected to act on the association. 285 7. Security Considerations 287 This document uses signaling mechanisms defined in [RFC7551] and 288 [GMPLS-FRR] and does not introduce any additional security 289 considerations other than already covered in [RFC7551], [GMPLS-FRR] 290 and the MPLS/GMPLS security framework [RFC5920]. 292 Using the extended association ID in the intercepted signalling 293 message, a node may be able to get additional information of the LSP 294 such as co-routed type and the originating node. This is judged to 295 be a very minor security risk as this information is already 296 available by other means. 298 8. IANA Considerations 300 This informational document does not make any request for IANA 301 action. 303 9. References 305 9.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 311 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 312 Functional Specification", RFC 2205, September 1997. 314 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 315 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 316 Tunnels", RFC 3209, December 2001. 318 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 319 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 320 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 322 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 323 Association Object Extensions", RFC 6780, October 2012. 325 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 326 Extensions for Associated Bidirectional LSPs", RFC 7551, 327 May 2015. 329 [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., 330 Bhatia, M., Jin, L., "Extensions to Resource Reservation 331 Protocol For Fast Reroute of Traffic Engineering GMPLS 332 LSPs", draft-ietf-teas-gmpls-lsp-fastreroute-03, July 333 2015. 335 9.2. Informative References 337 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 338 Networks", RFC 5920, July 2010. 340 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 341 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 343 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 344 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 345 Framework", RFC 6373, September 2011. 347 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 348 6689, July 2012. 350 Authors' Addresses 352 Rakesh Gandhi (editor) 353 Cisco Systems, Inc. 355 EMail: rgandhi@cisco.com 357 Himanshu Shah 358 Ciena 360 EMail: hshah@ciena.com 362 Jeremy Whittaker 363 Verizon 365 EMail: jeremy.whittaker@verizon.com