idnits 2.17.1 draft-ietf-ccamp-lsp-attribute-ro-05.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 == Line 162 has weird spacing: '...es TLVs as de...' -- The document date (October 23, 2014) is 3463 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) == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-wson-signaling-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP C. Margaria, Ed. 3 Internet-Draft Juniper 4 Intended status: Standards Track G. Martinelli 5 Expires: April 26, 2015 Cisco 6 S. Balls 7 B. Wright 8 Metaswitch 9 October 23, 2014 11 LSP Attribute in ERO 12 draft-ietf-ccamp-lsp-attribute-ro-05 14 Abstract 16 RFC5420 extends RSVP-TE to specify or record generic attributes which 17 apply to the whole of the path of an LSP. This document proposes an 18 extension to the RSVP ERO and RRO objects to allow it to specify or 19 record generic attributes which apply to a given hop. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 26, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Specifying Hop Attribute . . . . . . . . . . . . . . . . . . 3 60 3.1. ERO_HOP_ATTRIBUTE subobject . . . . . . . . . . . . . . . 3 61 3.2. HOP Attributes TLVs . . . . . . . . . . . . . . . . . . . 4 62 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Recording Hop attribute . . . . . . . . . . . . . . . . . . . 5 64 4.1. RRO_HOP_ATTRIBUTE subobject . . . . . . . . . . . . . . . 5 65 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2.1. Subobject presence rule . . . . . . . . . . . . . . . 6 67 4.2.2. Reporting Compliance with ERO Hop Attributes . . . . 6 68 4.2.3. Compatibility with RRO Attributes subobject . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 5.1. ERO LSP Attribute Subobject . . . . . . . . . . . . . . . 7 71 5.2. RRO LSP Attribute Subobject . . . . . . . . . . . . . . . 7 72 5.3. Existing LSP Attribute TLVs . . . . . . . . . . . . . . . 7 73 5.3.1. Attribute Flags . . . . . . . . . . . . . . . . . . . 8 74 5.3.2. Service ID TLV . . . . . . . . . . . . . . . . . . . 8 75 5.3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 86 Paths (LSPs) can be route-constrained by making use of the Explicit 87 Route (ERO) object and related sub-objects as defined in [RFC3209], 88 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 89 Several documents have identified the need for attributes that can be 90 targeted at specific hops in the path of an LSP, including [RFC6163], 91 [I-D.ietf-ccamp-wson-signaling], 92 [I-D.dong-ccamp-rsvp-te-mpls-tp-li-lb] or 93 [I-D.ali-ccamp-rc-objective-function-metric-bound],. This document 94 provides a generic mechanism for use by these other documents. 96 RSVP already supports generic extension of LSP attributes in 97 [RFC5420]. In order to support current and future ERO constraint 98 extensions this document defines a mechanism to define per-Hop 99 attributes. 101 1.1. Contributing Authors 103 1.2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Requirements 111 The requirement is to provide a generic mechanism to carry 112 information related to specific nodes when signaling an LSP. This 113 document does not restrict what that information can be used for. A 114 mechanism similar to LSP attribute defined [RFC5420] should be 115 expressed in ERO and SERO objects. A new ERO sub-object is defined, 116 containing a list of generic per-Hop attributes. The mechanism 117 defined in this document limits itself to single HOP attributes, and 118 does not address attributes valid for a LSP section 120 3. Specifying Hop Attribute 122 The ERO Attributes subobject may be carried in the ERO or SERO object 123 if they are present. The subobject uses the standard format of an 124 ERO subobject. 126 3.1. ERO_HOP_ATTRIBUTE subobject 128 The length is variable and content is a list of HOP Attributes TLVs 129 defined in Section 3.2. The size of the ERO sub-object limits the 130 size of the attribute TLV to 250 bytes. The typical size of 131 currently defined and forthcoming LSP_ATTRIBUTE TLVs applicable to a 132 specific hop (WSON_SIGNALING, OF and Metric) is not foreseen to 133 exceed this limit. 135 The ERO_HOP_ATTRIBUTE subobject is defined as follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |L| Type | Length | Reserved |R| 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 // Attributes TLVs // 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 The L, Type and Length parameters are as defined in [RFC3209] section 148 4.3.3. The Type for the ERO_HOP_ATTRIBUTE subobject is TBA by IANA. 149 The attributes TLV are encoded as defined in section Section 3.2. 151 Reserved Reserved, MUST be set to 0 when the subobject is inserted 152 in the ERO, MUST NOT be changed when a node process the ERO and 153 MUST be ignored on the node addressed by the preceding ERO 154 subobjects. 156 R This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE 157 semantic defined in [RFC5420]. When set it indicates required hop 158 attributes to be processed by the node. When cleared, it 159 indicates that the hop attributes are not required as described in 160 Section Section 3.3. 162 Attributes TLVs as defined in Section 3.2 . 164 3.2. HOP Attributes TLVs 166 ERO Attributes carried by the new objects defined in this document 167 are encoded within TLVs. One or more TLVs MAY be present in each 168 object. There are no ordering rules for TLVs, and interpretation 169 SHOULD NOT be placed on the order in which TLVs are received. The 170 TLV format is defined in [RFC5420] section 3. 172 3.3. Procedures 174 As described in [RFC3209] and [RFC3473] the ERO is managed as a list 175 where each hop information starts with a subobject identifying an 176 abstract node or link. The ERO_HOP_ATTRIBUTE subobject MUST be 177 appended after the existing subobjects defined in [RFC3209], 178 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 179 Several ERO_HOP_ATTRIBUTE subobject MAY be present, for each hop. 181 If a node is processing an ERO_HOP_ATTRIBUTE subobject and does not 182 support handling of the subobject it will behave as described in 183 [RFC3209] when an unrecognized ERO subobject is encountered. This 184 node will return a PathErr with error code "Routing Error" and error 185 value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object 186 included, truncated (on the left) to the offending unrecognized 187 subobject. 189 When the R bit is set a node MUST examine the attribute TLV present 190 in the subobject following the rules described in [RFC5420] section 191 5.2. When the R bit is not set a node MUST examine the attribute TLV 192 present in the subobject following the rules described in [RFC5420] 193 section 4.2. 195 A node processing an ERO_HOP_ATTRIBUTE subobject with an HOP 196 attribute TLV longer than the ERO subobject SHOULD return a PathErr 197 with error code "Routing Error" and error value "Bad EXPLICIT_ROUTE 198 object" with the EXPLICIT_ROUTE object included, truncated (on the 199 left) to the offending malformed subobject. The processing of the 200 Hop attribute TLVs SHOULD be described in the documents defining 201 them. 203 4. Recording Hop attribute 205 In some cases it is important to determine if an optional Hop 206 attribute has been processed by a node. 208 4.1. RRO_HOP_ATTRIBUTE subobject 210 The RRO_HOP_ATTRIBUTE subobject may be carried in the RECORD_ROUTE 211 object if it is present. The subobject uses the standard format of 212 an RRO subobject. 214 The RRO_HOP_ATTRIBUTE subobject is defined as follows: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Length | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | | 222 // Attributes TLVs // 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 The Type and Length parameters are as defined in [RFC3209] section 227 4.4.1. The Type for the RRO_HOP_ATTRIBUTE subobject is TBA by IANA. 228 The attributes TLV are encoded as defined in section Section 3.2. 230 Length The Length contains the total length of the subobject in 231 bytes, including the Type and Length fields. The Length MUST be 232 always divisible by 4. 234 Reserved Reserved, must be set to 0 when the subobject is inserted 235 in the RRO, MUST NOT be changed when a node process the RRO and 236 must be ignored on the node addressed by the preceding RRO 237 subobjects. 239 Attributes TLVs The processed or addition HOP attributes, using the 240 format defined in Section 3.2 . 242 4.2. Procedures 244 4.2.1. Subobject presence rule 246 The RRO rules defined in [RFC3209] are not changed. The 247 RRO_HOP_ATTRIBUTE subobject MUST be pushed after the RRO attribute 248 subobject (if present) defined in in [RFC5420]. The 249 RRO_HOP_ATTRIBUTE subobject MAY be present between a pair of 250 subobject identifying LSR or links. All such subobjects MUST be 251 forwarded unmodified by transit LSRs. 253 4.2.2. Reporting Compliance with ERO Hop Attributes 255 To report that an ERO Hop attribute has been considered, or to report 256 an additional attribute, an LSR MAY add a RRO_HOP_ATTRIBUTE subobject 257 with the HOP Attribute TLV which describes the attribute to be 258 reported. The requirement to report compliance MUST be specified in 259 the document that defines the usage of an Hop attribute. 261 4.2.3. Compatibility with RRO Attributes subobject 263 The RRO_HOP_ATTRIBUTE extends the capability of the RRO Attributes 264 subobject defined in [RFC5420] section 7.2 by allowing the node to 265 report the attribute value. The mechanism defined in this document 266 is compatible with the RRO Attributes using the following procedures. 268 For LSP attributes signaled in the LSP_ATTRIBUTES or 269 LSP_REQUIRED_ATTRIBUTES, a node SHOULD use the RRO Attributes to 270 report processing of those attributes. If a node desires to include 271 the LSP_ATTRIBUTE TLV, it SHOULD use both the RRO Attributes and 272 RRO_HOP_ATTRIBUTE. Head end nodes not supporting the 273 RRO_HOP_ATTRIBUTE will drop the information. 275 For LSP attributes signaled in the ERO Hop attribute and not in the 276 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES, if a node desires to 277 include the LSP_ATTRIBUTE, it SHOULD use the RRO_HOP_ATTRIBUTE and 278 SHOULD NOT use the RRO Attributes. 280 5. IANA Considerations 282 5.1. ERO LSP Attribute Subobject 284 IANA manages the "RSVP PARAMETERS" registry located at 285 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. 286 We request IANA to make an allocation in the Sub-object type 20 287 EXPLICIT_ROUTE - Type 1 Explicit Route registry. 289 This document introduces a new ERO sub-object: 291 Value Description Reference 292 ------ ----------------- -------------- 293 TBA ERO HOP Attribute This document 295 5.2. RRO LSP Attribute Subobject 297 IANA manages the "RSVP PARAMETERS" registry located at 298 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. 299 We request IANA to make an allocation in the Sub-object type 21 300 ROUTE_RECORD - Type 1 Route Record registry. 302 This document introduces a new RRO sub-object: 304 Value Description Reference 305 ------ ----------------- -------------- 306 TBA RRO HOP Attribute This document 308 5.3. Existing LSP Attribute TLVs 310 IANA manages the "RSVP-TE PARAMETERS" registry located at 311 http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- 312 parameters.xml. The "Attributes TLV Space" registry manage the 313 following attributes, as defined in [RFC5420]: 315 o TLV Type (T-field value) 317 o TLV Name 319 o Whether allowed on LSP_ATTRIBUTES object 321 o Whether allowed on LSP_REQUIRED_ATTRIBUTES object 323 We request IANA to add the following information for each TLV in the 324 RSVP TLV type identifier registry. 326 o Whether allowed on LSP attribute ERO subobject 328 The existing registry is modified for existing TLVs as follows: 330 5.3.1. Attribute Flags 332 The new TLV type definition is as follow 334 o TLV Type = 1 336 o TLV Name = Attribute Flags TLV 338 o Allowed on LSP_ATTRIBUTES object 340 o Allowed on LSP_REQUIRED_ATTRIBUTES object 342 o Allowed on LSP attribute ERO subobject 344 o Defining RFC = [RFC5420] 346 5.3.2. Service ID TLV 348 The new TLV type definition is as follow 350 o TLV Type = 2 352 o TLV Name = Service ID TLV 354 o Allowed on LSP_ATTRIBUTES object 356 o Not allowed on LSP_REQUIRED_ATTRIBUTES object 358 o Not allowed on LSP attribute ERO subobject 360 o Defining RFC = [RFC7260] 362 5.3.3. OAM Configuration TLV 364 The new TLV type definition is as follow 366 o TLV Type = 3 368 o TLV Name = OAM Configuration TLV 370 o Allowed on LSP_ATTRIBUTES object 372 o Allowed on LSP_REQUIRED_ATTRIBUTES object 373 o Not allowed on LSP attribute ERO subobject 375 o Defining RFC = [RFC6060] 377 6. Security Considerations 379 This document adds new subobject in the EXPLICIT_ROUTE and the 380 ROUTE_RECORD object carried in RSVP message used in MPLS and GMPLS 381 signaling. It builds on mechanism defined in [RFC3209] and [RFC5420] 382 and does not introduce any new security. The existing security 383 considerations described in [RFC2205], [RFC3209], [RFC3473] and 384 [RFC5420] do apply. 386 As any RSVP-TE signaling request, the procedures defined in this 387 document permit the transfer and reporting of functional preferences 388 on specific node. This may reveal information about the LSP request 389 and status to anyone with unauthorized access. The mechanism 390 described in this document do not contribute to this issue, which can 391 be only resolved by encrypting the content of the whole signaling 392 message. 394 In addition the reporting of attributes using the RRO may reveal 395 details about the node that the operator wishes to remains 396 confidential. The same strategy and policies that apply to other RRO 397 subobjects also apply to this new mechanism. It is recommended that 398 domain boundary policies take the releasing of RRO hop attributes 399 into consideration. 401 7. Acknowledgments 403 The authors would like to thanks Lou Berger for his directions and 404 Attila Takacs for inspiring this 405 [I-D.kern-ccamp-rsvpte-hop-attributes]. The authors also thanks Dirk 406 Schroetter for his contribution to the initial versions of the 407 documents (version -00 up to -02). 409 8. References 411 8.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 417 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 418 Functional Specification", RFC 2205, September 1997. 420 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 421 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 422 Tunnels", RFC 3209, December 2001. 424 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 425 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 426 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 428 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 429 in Resource ReSerVation Protocol - Traffic Engineering 430 (RSVP-TE)", RFC 3477, January 2003. 432 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 433 "GMPLS Segment Recovery", RFC 4873, May 2007. 435 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 436 Extension to Resource ReserVation Protocol-Traffic 437 Engineering (RSVP-TE)", RFC 4874, April 2007. 439 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 440 Ayyangarps, "Encoding of Attributes for MPLS LSP 441 Establishment Using Resource Reservation Protocol Traffic 442 Engineering (RSVP-TE)", RFC 5420, February 2009. 444 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 445 Topology Confidentiality in Inter-Domain Path Computation 446 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 448 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 449 Reservation Protocol (RSVP) Extensions for Path Key 450 Support", RFC 5553, May 2009. 452 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 453 "Generalized Multiprotocol Label Switching (GMPLS) Control 454 of Ethernet Provider Backbone Traffic Engineering (PBB- 455 TE)", RFC 6060, March 2011. 457 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 458 Extensions for Operations, Administration, and Maintenance 459 (OAM) Configuration", RFC 7260, June 2014. 461 8.2. Informative References 463 [I-D.ali-ccamp-rc-objective-function-metric-bound] 464 Ali, Z., Swallow, G., Filsfils, C., Fang, L., Kumaki, K., 465 Kunze, R., Ceccarelli, D., and X. Zhang, "Resource 466 ReserVation Protocol-Traffic Engineering (RSVP-TE) 467 Extension for Signaling Objective Function and Metric 468 Bound", draft-ali-ccamp-rc-objective-function-metric- 469 bound-05 (work in progress), February 2014. 471 [I-D.dong-ccamp-rsvp-te-mpls-tp-li-lb] 472 Dong, J., Chen, M., and Z. Li, "GMPLS RSVP-TE Extensions 473 for Lock Instruct and Loopback", draft-dong-ccamp-rsvp-te- 474 mpls-tp-li-lb-05 (work in progress), December 2012. 476 [I-D.ietf-ccamp-wson-signaling] 477 Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H. 478 Harai, "Signaling Extensions for Wavelength Switched 479 Optical Networks", draft-ietf-ccamp-wson-signaling-09 480 (work in progress), September 2014. 482 [I-D.kern-ccamp-rsvpte-hop-attributes] 483 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 484 intermediate hops using RSVP-TE", draft-kern-ccamp-rsvpte- 485 hop-attributes-00 (work in progress), October 2009. 487 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 488 GMPLS and Path Computation Element (PCE) Control of 489 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 490 April 2011. 492 Authors' Addresses 494 Cyril Margaria (editor) 495 Juniper 496 200 Somerset Corporate Boulevard, , Suite 4001 497 Bridgewater, NJ 08807 498 USA 500 Email: cmargaria@juniper.net 502 Giovanni Martinelli 503 Cisco 504 via Philips 12 505 Monza 20900 506 IT 508 Phone: +39 039 209 2044 509 Email: giomarti@cisco.com 510 Steve Balls 511 Metaswitch 512 100 Church Street 513 Enfield EN2 6BQ 514 UJ 516 Phone: +44 208 366 1177 517 Email: steve.balls@metaswitch.com 519 Ben Wright 520 Metaswitch 521 100 Church Street 522 Enfield EN2 6BQ 523 UJ 525 Phone: +44 208 366 1177 526 Email: Ben.Wright@metaswitch.com