idnits 2.17.1 draft-gandhishah-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 (March 7, 2016) is 2971 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 8, 2016 Ciena 6 Jeremy Whittaker 7 Verizon 8 March 7, 2016 10 RSVP-TE Extensions For Associated Co-routed Bidirectional 11 Label Switched Paths (LSPs) 12 draft-gandhishah-teas-assoc-corouted-bidir-00 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 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 25 co-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 packet transport networks, there are requirements where a reverse 86 LSP of a bidirectional LSP needs to follow the same path as its 87 forward LSP [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 92 [RFC3209] into an associated bidirectional LSP. There are two models 93 described for provisioning the LSP, single-sided and double-sided. 94 The double-sided provisioned bidirectional LSPs are not considered in 95 this document. 97 The MPLS TP [RFC6370] architecture facilitates the co-routed 98 bidirectional LSP by using GMPLS extensions [RFC3473] to achieve 99 congruent paths. The RSVP association signaling allows to take 100 advantages of the co-routed bidirectional LSPs without having to 101 deploy GMPLS extensions in the existing networks. The association 102 signaling also allows to take advantage of the existing TE mechanisms 103 such as fast-reroute. 105 [GMPLS-FRR] defines fast-reroute procedures for GMPLS signaled LSPs 106 to ensure traffic flows on a co-routed path after a failure event on 107 the primary LSP path. [GMPLS-FRR] defined fast-reroute mechanisms 108 are equally applicable to the associated co-routed bidirectional 109 LSPs. 111 This document describes how Extended ASSOCIATION Object can be used 112 to bind two reverse co-routed unidirectional LSPs into an associated 113 co-routed bidirectional LSP in single-sided provisioning case. The 114 REVERSE_LSP Object is used to enable an endpoint to trigger creation 115 of the reverse LSP along the same path as the forward LSP. 116 Fast-reroute procedures to ensure that the traffic flows on the 117 co-routed path after a failure event are also described. 119 2. Conventions Used in This Document 121 2.1. Key Word Definitions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2.2. Reverse Co-routed Unidirectional LSPs 129 Two reverse unidirectional LSPs are setup in the opposite directions 130 between a pair of source and destination nodes to form an associated 131 bidirectional LSP. A reverse unidirectional LSP originates on the 132 same node where the forward unidirectional LSP terminates, and it 133 terminates on the same node where the forward unidirectional LSP 134 originates. A reverse co-routed unidirectional LSP traverses along 135 the same path of the forward direction unidirectional LSP in the 136 opposite direction. 138 3. Overview 140 For single-sided provisioning, the RSVP Traffic Engineering (TE) 141 tunnel is configured only on one endpoint. An LSP for this tunnel is 142 initiated by the originating endpoint with Extended ASSOCIATION 143 Object containing Association Type set to "single-sided associated 144 bidirectional LSP" and REVERSE_LSP Object inserted in the Path 145 message. The remote endpoint then creates the corresponding reverse 146 TE tunnel and signals the reverse LSP in response using information 147 from the REVERSE_LSP Object and other objects present in the received 148 Path message [RFC7551]. The reverse LSP thus created may or may not 149 be congruent. 151 LSP1 --> 152 +-----+ +-----+ +-----+ 153 | A +-----------+ C +-----------+ B | 154 +-----+ +-----+ +-----+ 155 <-- LSP2 157 Figure 1: An Example of Associated Co-routed Bidirectional LSP 159 As shown in Figure 1, creation of reverse LSP2 on remote endpoint B 160 is triggered by LSP1. LSP2 follows the path in the reverse direction 161 using the EXPLICIT_ROUTE Object (ERO) from the received REVERSE_LSP 162 Object in the Path message of LSP1. 164 For co-routed bidirectional LSP, the originating endpoint A ensures 165 the reverse LSP follow the same path as the forward LSP by populating 166 EXPLICIT_ROUTE Object in the REVERSE_LSP Object using the hops 167 traversed by the forward LSP in the reverse order. 169 4. Message and Object Definitions 171 4.1. Extended ASSOCIATION Object 173 The Extended ASSOCIATION Object is populated using the rules defined 174 in [RFC7551] for the Association Type "single-sided associated 175 bidirectional LSP". 177 The Extended Association ID is set by the originating node to the 178 value specified as following. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | LSP Source Address | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Flags | LSP-ID | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2: IPv4 Extended Association ID Format 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 | LSP Source Address | 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Flags | LSP-ID | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 3: IPv6 Extended Association ID Format 202 LSP Source Address 204 IPv4/IPv6 source address of the originating LSP. 206 LSP-ID 208 16-bits LSP-ID of the originating LSP. 210 Flags 212 Bit 0: COROUTED-LSP-FLAG: When set, this flag indicates the 213 associated bidirectional LSP is co-routed. 215 Bit 1-15: Not used. Must be set to 0. 217 5. Signaling Procedure 219 5.1. Co-routed Bidirectional LSP Association 221 In general, the processing rules for the Extended ASSOCIATION Object 222 as specified in [RFC6780] and [RFC7551] are followed for co-routed 223 bidirectional LSP association. 225 The originating head-end MUST add Extended ASSOCIATION Object with 226 Association Type set to "single-sided associated bidirectional LSP" 227 and the extended association ID as specified in Section 4.1 of this 228 document. The COROUTED-LSP-FLAG MUST be set to indicate the nodes on 229 the LSP path that bidirectional LSP is co-routed. In addition, the 230 originating head-end node MUST add EXPLICIT_ROUTE Object (ERO) in the 231 REVERSE_LSP Object by using the hops traversed by the forward LSP in 232 the reverse order to ensure that reverse LSP follows the same path as 233 forward direction LSP in the opposite direction. 235 As defined in [RFC7551], the remote endpoint simply copies the 236 content of the received Extended ASSOCIATION Object including the 237 extended association ID in the reverse LSP Extended ASSOCIATION 238 Object. In addition, the remote endpoint builds the ERO of the 239 reverse LSP using the ERO from the received REVERSE_LSP Object of the 240 forward LSP. 242 As contents of the Extended ASSOCIATION Object are unique for each 243 associated co-routed bidirectional LSP, a node can unambiguously 244 identify the associated LSP pair by matching their Extended 245 ASSOCIATION Objects. At a transit LSR, reverse LSP can identify the 246 matching forward LSP by checking the originating LSP source address 247 and LSP-ID in the extended association ID. In addition, a node can 248 identify an originating (forward) LSP by matching the LSP source 249 address with the source address in the extended association ID. 251 5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP 253 The procedures defined in [GMPLS-FRR] are used for associated 254 co-routed bidirectional LSP to ensure that traffic flows on a 255 co-routed path after a link or node failure. The COROUTED-LSP-FLAG 256 is used by the Point of Local Repair (PLR) nodes to provide fast- 257 reroute protection using associated co-routed bypass tunnels. 259 As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in RRO is 260 used to co-ordinate bypass tunnel assignment between a forward and 261 reverse direction PLRs. This subobject MUST be added by the forward 262 direction PLR in the Path message of the originating LSP. The 263 reverse direction PLR (forward direction LSP merge-point (MP)) simply 264 reflects the bypass tunnel assignment for the reverse direction LSP 265 on the co-routed path. 267 After a link or node failure, PLRs in both directions trigger fast- 268 reroute independently using the procedures defined in [RFC4090]. 270 As specified in [GMPLS-FRR], re-corouting procedure can be used to 271 reroute the traffic in the reverse direction on the co-routed bypass 272 tunnel path. Reverse direction PLR will assume the role of Point of 273 Remote Repair (PRR) and trigger the fast-reroute in the reverse 274 direction on the matching co-routed bypass tunnel to ensure that both 275 traffic and RSVP signaling flow on the co-routed path after the 276 failure. 278 6. Compatibility 280 The Extended ASSOCIATION Object has been defined in [RFC6780], with 281 class number in the form 11bbbbbb, which ensures compatibility with 282 non-supporting nodes. Per [RFC2205], such nodes will ignore the 283 object but forward it without modification. 285 This document defines the content of the Extended Association ID for 286 the Extended ASSOCIATION Object for co-routed bidirectional LSPs. 287 Operators wishing to use this function SHOULD ensure that it is 288 supported on the node that is expected to act on the association. 290 7. Security Considerations 292 This document uses signaling mechanisms defined in [RFC7551] and 293 [GMPLS-FRR] and does not introduce any additional security 294 considerations other than already covered in [RFC7551], [GMPLS-FRR] 295 and the MPLS/GMPLS security framework [RFC5920]. 297 Using the extended association ID in the intercepted signalling 298 message, a node may be able to get additional information of the LSP 299 such as co-routed type and the originating node. This is judged to 300 be a very minor security risk as this information is already 301 available by other means. 303 8. IANA Considerations 305 This document does not make any request for IANA action. 307 9. References 309 9.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 315 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 316 Functional Specification", RFC 2205, September 1997. 318 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 319 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 320 May 2005. 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. 334 9.2. Informative References 336 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 337 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 338 Tunnels", RFC 3209, December 2001. 340 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 341 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 342 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 344 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 345 Networks", RFC 5920, July 2010. 347 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 348 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 350 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 351 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 352 Framework", RFC 6373, September 2011. 354 Authors' Addresses 356 Rakesh Gandhi (editor) 357 Cisco Systems, Inc. 359 EMail: rgandhi.ietf@gmail.com 361 Himanshu Shah 362 Ciena 364 EMail: hshah@ciena.com 366 Jeremy Whittaker 367 Verizon 369 EMail: jeremy.whittaker@verizon.com