idnits 2.17.1 draft-ali-ccamp-rsvp-te-include-route-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 45 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 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: 'OSPF-TE-METRIC' is mentioned on line 107, but not defined == Missing Reference: 'ISIS-TE-METRIC' is mentioned on line 107, but not defined == Missing Reference: 'RFC2205' is mentioned on line 371, but not defined == Missing Reference: 'RFC4874' is mentioned on line 372, but not defined == Unused Reference: 'RFC6001' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC2209' is defined on line 458, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: August 13, 2014 Matt Hartley 6 Ori Gerstel 7 Cisco Systems 8 Kenji Kumaki 9 KDDI Corporation 10 Ruediger Kunze 11 Deutsche Telekom AG 12 February 14, 2014 14 Include Routes - Extension to 15 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 16 draft-ali-ccamp-rsvp-te-include-route-06.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current 26 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 This Internet-Draft will expire on August 13, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 There are scenarios that require two or more LSPs or segments of 56 LSPs to follow same route in the network. This document specifies 57 methods to communicate route inclusions along the loose hops during 58 path setup using the Resource ReserVation Protocol-Traffic 59 Engineering (RSVP-TE) protocol. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 65 this document are to be interpreted as described in RFC 2119 66 [RFC2119]. 68 Table of Contents 70 Copyright Notice.................................................1 71 1. Introduction..................................................2 72 2. RSVP-TE signaling extensions..................................4 73 2.1. IPv4 Point-to-Point Path ERO subobject................4 74 2.2. IPv6 Point-to-Point Path ERO subobject................5 75 2.3. Processing rules for Path ERO subobjects..............7 76 3. Security Considerations.......................................8 77 4. IANA Considerations...........................................8 78 4.1. New ERO subobject types...............................8 79 4.2. New RSVP error sub-codes..............................9 80 5. Acknowledgments...............................................9 81 6. References...................................................10 82 6.1. Normative References.................................10 83 6.2. Informative References...............................10 85 1. Introduction 87 There are scenarios that require two or more Label Switched 88 Paths (LSPs) to follow same route in the network. E.g., many 89 deployments require member LSPs of a bundle/ aggregated link (or 90 Forwarding Adjacency (FA))) follow the same route. Possible 91 reasons for two or more LSPs to follow the same end-to-end or 92 partial route include, but are not limited to: 94 . Fate sharing: an application may require that two or more 95 LSPs fail together. In the example of bundle link this would 97 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 99 mean that if one component goes down, the entire bundle goes 100 down. 102 . Homogeneous Attributes: it is often required that two or more 103 LSPs have the same TE metrics like latency, latency variation, 104 etc. In the example of a bundle/ aggregated link this would 105 meet the requirement that all component links (FAs) of a 106 bundle should have same latency and latency variation. As 107 noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 108 networks, such as financial information networks, network 109 performance (e.g. latency and latency variation) is becoming 110 critical and hence having bundles with component links (FAs) 111 with homogeneous latency and latency variation is important. 113 The RSVP-TE specification [RFC3209] and GMPLS extensions to 114 RSVP-TE [RFC3473] allow abstract nodes and resources to be 115 explicitly included in a path setup, e.g., using IPv4 prefix ERO 116 subobject [RFC3209], IPv6 prefix ERO subobject [RFC3209] and 117 Unnumbered Interface ID ERO subobject [RFC3477], etc. When a 118 source node has full topological knowledge and is permitted to 119 signal an Explicit Route Object, these methods can be used to 120 satisfy the inclusion requirements mentioned above. However, 121 there are scenarios when path computations are performed by 122 remote nodes, thus there is a need for relevant inclusion 123 requirements to be communicated to those nodes. These include 124 (but are not limited to): 126 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 127 inter-domain LSPs; 129 . Generalized Multi-Protocol Label Switching (GMPLS) User- 130 Network Interface (UNI) where path computation may be 131 performed by the (server layer) core node [RFC4208]. 133 These use-cases require the relevant path-inclusion information 134 to be communicated to the route expanding nodes. This document 135 defines the necessary extensions to RSVP-TE protocol. 137 This document assumes that node expanding the route is normally a 138 hop of the included LSP. Therefore, the node calculating or 139 expanding the route of the signaled LSP has the knowledge of the 140 inclusion route. 142 However, there is a race condition in which included LSP is yet 143 to be signaled. This draft addresses this race condition, as 144 detailed in Section 2.2. 146 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 148 2. RSVP-TE signaling extensions 150 New IPv4 and IPv6 Point-to-Point (P2P) Path ERO subobject types 151 are defined in this document. These ERO subobjects are used to 152 communicate path inclusion requirements to the ERO expanding 153 node(s). For this purpose, the subobjects carry RSVP-TE 154 Forwarding Equivalence Class (FEC) of the reference LSP who's 155 Path is be used to expand the loose hop of the LSP being 156 signaled. 158 2.1. IPv4 Point-to-Point Path ERO subobject 160 The IPv4 Point-to-Point Path ERO subobject is defined as 161 follows: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |L| Type | Length |M| Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | IPv4 tunnel end point address | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Reserved (MUST be zero) | Tunnel ID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Extended Tunnel ID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | IPv4 tunnel sender address | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Reserved (MUST be zero) | LSP ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 L 180 The L bit is an attribute of the subobject. The L bit is 181 set if the subobject represents a loose hop in the ERO. 182 If the bit is not set, the subobject represents a strict 183 hop in the explicit route. 185 This document only defines the use of the subobject in 186 loose hopes in the ERO, i.e., L bit MUST of set to 1. 188 Type 190 IPv4 Point-to-Point Path ERO subobject 191 (to be assigned by IANA; suggested value: 38). 193 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 195 Length 197 The length contains the total length of the subobject in 198 bytes, including the type and length fields. The length is 199 always 24. 201 M bit: When "mandatory inclusion" bit is set, the route of the 202 LSP being signaled MUST follow the path specified by the Path 203 ERO subobject. When mandatory inclusion is not set, the route 204 of the LSP being signaled SHOULD follow the path specified by 205 the Path ERO subobject. 207 The remaining fields are used to specify RSVP-TE FEC of the 208 reference LSP who's Path is be used to expand the route of the 209 LSP being signaled. Specifically, 211 Tunnel ID 213 Tunnel ID of the reference LSP who's Path is be used to 214 expand the route of the LSP being signaled. 216 Extended Tunnel ID 218 Extended Tunnel ID of the reference LSP who's Path is be 219 used to expand the route of the LSP being signaled. 221 IPv4 tunnel sender address 223 IPv4 tunnel sender address of the reference LSP who's 224 path is be used to expand the route of the LSP being 225 signaled. 227 LSP ID 229 LSP ID of the reference LSP who's Path is be used to 230 expand the route of the LSP being signaled. 232 2.2. IPv6 Point-to-Point Path ERO subobject 234 The IPv6 Point-to-Point Path ERO subobject is defined as 235 follows: 237 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |L| Type | Length |M| Reserved | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | IPv6 tunnel end point address | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | IPv6 tunnel end point address (cont.) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | IPv6 tunnel end point address (cont.) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | IPv6 tunnel end point address (cont.) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Must Be Zero | Tunnel ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Extended Tunnel ID | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Extended Tunnel ID (cont.) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Extended Tunnel ID (cont.) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Extended Tunnel ID (cont.) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | IPv4 tunnel sender address | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | IPv4 tunnel sender address (cont.) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | IPv4 tunnel sender address (cont.) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | IPv4 tunnel sender address (cont.) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Reserved (MUST be zero) | LSP ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 L 274 The L bit is an attribute of the subobject. The L bit is 275 set if the subobject represents a loose hop in the ERO. 276 If the bit is not set, the subobject represents a strict 277 hop in the explicit route. 279 This document only defines the use of the subobject in 280 loose hopes in the ERO, i.e., L bit MUST of set to 1. 282 Type 284 IPv6 Point-to-Point Path ERO subobject 286 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 288 (to be assigned by IANA; suggested value: 39). 290 Length 292 The length contains the total length of the subobject in 293 bytes, including the type and length fields. The length is 294 always 48. 296 M bit: The M bit usage is as defined for the M bit of IPv4 297 Point-to-Point Path ERO subobject. 299 The remaining fields are used to specific RSVP-TE FEC of the 300 reference LSP who's Path is be used to expand the route of the 301 LSP being signaled, as detailed in Section 2.1. 303 2.3. Processing rules for Path ERO subobjects 305 The basic processing rules of an ERO are not altered. Please 306 refer to [RFC3209] for details. 308 If an LSR strips all local subobjects from an ERO carried in a 309 Path message (according to the procedures in [RFC3209]) and 310 finds that the next subobject is an IPv4 P2P Path ERO subobject 311 or IPv6 P2P LSP subject, it MUST attempt to resolve the Path ERO 312 subobject as described in the following. 314 If the L bit of the Path ERO subobject is not set, i.e., the 315 subobject represents a strict hop in the explicit route, the 316 processing node MUST respond with a PathErr message with the 317 error code "Routing Problem" (24) and the error value "Bad 318 initial subobject" (4). 320 If the M bit is set, the processing node follows the following 321 procedure: 323 - If the path taken by the LSP referenced in the Path ERO 324 subobject is known to the processing node and the path 325 contains the loose abstract node in the ERO hop, the 326 processing node MUST ensure that loose hop expansion to the 327 next abstract node follows the referenced path. 329 - If the path taken by the LSP referenced in the Path ERO 330 subobject does not contain the loose abstract node in the ERO 331 hop, the processing node MUST sent a PathErr message with the 332 error code "Routing Problem" (24) and the new error value 334 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 336 "unknown or inconsistent LSP suboject" (value to be assigned 337 by IANA) for the signaled LSP. 339 - If the path referenced in the LSP subobject is unknown to the 340 processing node, the processing node SHOULD ignore the Path 341 ERO subobject and SHOULD proceed with the signaling request. 342 After sending the Resv for the signaled LSP, the processing 343 node SHOULD return a PathErr with the error code "Notify 344 Error" (25) and error sub-code "TBD" (value to be assigned by 345 IANA, suggested value: TBD) for the signaled LSP. 347 If the M bit is not set, the processing node follows the 348 following procedure: 350 - If the path taken by the LSP referenced in the Path ERO 351 subobject is known to the processing node and the path 352 contains the loose abstract node in the ERO hop, the 353 processing node SHOULD ensure that loose hop expansion to the 354 next abstract node follows the referenced path. 356 - If the path taken by the LSP referenced in the Path ERO 357 subobject is unknown to the processing node and/ or the 358 referenced path does not contain the loose abstract node in 359 the ERO hop, the processing node SHOULD ignore the route 360 inclusion specified in the Path ERO subobject and SHOULD 361 compute a suitable path to the loose abstract node in the ERO 362 hop and proceed with the signaling request. After sending the 363 Resv for the signaled LSP, the processing node SHOULD return a 364 PathErr with the error code "Notify Error" (25) and error sub- 365 code " unknown or inconsistent LSP suboject" (value to be 366 assigned by IANA) for the signaled LSP. 368 3. Security Considerations 370 This document does not introduce any additional security issues 371 above those identified in [RFC5920], [RFC2205], [RFC3209], and 372 [RFC3473] and [RFC4874]. 374 4. IANA Considerations 376 4.1. New ERO subobject types 378 This document adds the following new subobject of the existing 379 entry for ERO (20, EXPLICIT_ROUTE): 381 Value Description 383 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 385 ----- ------------ 387 TBA IPv4 Point-to-Point Path ERO 388 subobject 390 TBA IPv6 Point-to-Point Path ERO 391 subobject 393 These subobject may be present in the Explicit Route Object, but 394 not in the Route Record Object. 396 4.2. New RSVP error sub-codes 398 IANA registry: RSVP PARAMETERS 399 Subsection: Error Codes and Globally-Defined Error Value Sub- 400 Codes 402 For Error Code "Routing Problem" (24) (see [RFC3209]) the 403 following sub-codes are defined. 405 Sub-code Value 406 -------- ----- 408 Unknown or inconsistent LSP suboject To be assigned by IANA. 410 For Error Code "Notify Error" (25) (see [RFC3209]) the following 411 sub-codes are defined. 413 Sub-code Value 414 -------- ----- 416 Unknown or inconsistent LSP suboject To be assigned by IANA. 418 5. Acknowledgments 420 Authors would like to thank Gabriele Maria Galimberti, Luyuan 421 Fang and Walid Wakim for their review comments. 423 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 425 6. References 427 6.1. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 433 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 434 LSP Tunnels", RFC 3209, December 2001. 436 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 437 Switching (GMPLS) Signaling Resource ReserVation 438 Protocol-Traffic Engineering (RSVP-TE) Extensions", 439 RFC 3473, January 2003. 441 6.2. Informative References 443 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 444 "Generalized Multiprotocol Label Switching (GMPLS) 445 User-Network Interface (UNI): Resource ReserVation 446 Protocol-Traffic Engineering (RSVP-TE) Support for the 447 Overlay Model", RFC 4208, October 2005. 449 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., 450 Brungard, D., and JL. Le Roux, "Generalized MPLS 451 (GMPLS) Protocol Extensions for Multi-Layer and Multi- 452 Region Networks (MLN/MRN)", RFC 6001, October 2010. 454 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 455 Links in Resource ReSerVation Protocol - Traffic 456 Engineering (RSVP-TE)", RFC 3477, January 2003. 458 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 459 Protocol (RSVP) -- Version 1 Message Processing 460 Rules", RFC 2209, September 1997. 462 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 463 Networks", RFC 5920, July 2010. 465 Authors' Addresses 466 Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt 468 Zafar Ali 469 Cisco Systems, Inc. 470 Email: zali@cisco.com 472 George Swallow 473 Cisco Systems, Inc. 474 swallow@cisco.com 476 Clarence Filsfils 477 Cisco Systems, Inc. 478 cfilsfil@cisco.com 480 Matt Hartley 481 Cisco Systems 482 Email: mhartley@cisco.com 484 Ori Gerstel 485 Cisco Systems 486 ogerstel@cisco.com 488 Kenji Kumaki 489 KDDI Corporation 490 Email: ke-kumaki@kddi.com 492 Rudiger Kunze 493 Deutsche Telekom AG 494 Ruediger.Kunze@telekom.de