idnits 2.17.1 draft-ietf-ccamp-lsp-attribute-ro-02.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 143 has weird spacing: '... Type x TBD...' == Line 159 has weird spacing: '...es TLVs as de...' == Line 247 has weird spacing: '... Type x TBD...' -- The document date (July 15, 2013) is 3931 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 (-05) exists of draft-ali-ccamp-rc-objective-function-metric-bound-02 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-wson-signaling-06 Summary: 0 errors (**), 0 flaws (~~), 6 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 Coriant GmbH 4 Intended status: Standards Track G. Martinelli 5 Expires: January 16, 2014 Cisco 6 S. Balls 7 B. Wright 8 Metaswitch 9 July 15, 2013 11 LSP Attribute in ERO 12 draft-ietf-ccamp-lsp-attribute-ro-02 14 Abstract 16 LSP attributes can be specified or recorded for whole path, but they 17 cannot be targeted to a specific hop. This document proposes 18 alternative ways to extend the semantic for RSVP ERO object to target 19 LSP attributes to a specific 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 January 16, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . 2 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. ERO Attribute . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. ERO_ATTRIBUTE subobject . . . . . . . . . . . . . . . . . 3 61 3.2. HOP Attributes TLVs . . . . . . . . . . . . . . . . . . . 4 62 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Recording Hop attribute per LSP . . . . . . . . . . . . . . . 5 64 4.1. RRO Hop Attributes 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 79 Paths (LSPs) can be route-constrained by making use of the Explicit 80 Route (ERO) object and related sub-objects as defined in [RFC3209], 81 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 82 Those route constraints are extended by a number of documents, 83 including element defined in [RFC6163], 84 [I-D.ietf-ccamp-wson-signaling], 85 [I-D.dong-ccamp-rsvp-te-mpls-tp-li-lb] or 86 [I-D.ali-ccamp-rc-objective-function-metric-bound], for example the 87 WSON_SIGNALING object, Metric and Objective Function subobjects. 89 RSVP already supports generic extension of LSP attributes in 90 [RFC5420]. In order to support current and future ERO constraint 91 extensions this document defines a mechanism to target generic 92 attributes at a specific hop. 94 1.1. Contributing Authors 95 1.2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Requirements 103 The requirement is to provide a generic mechanism to carry 104 information related to specific nodes when signaling an LSP. This 105 document does not restrict what that information can be used for. A 106 mechanism similar to LSP attribute defined [RFC5420] should be 107 expressed in ERO and SERO objects. A new ERO sub-object is defined, 108 containing a list of generic Hop attributes. The mechanism defined 109 in this document limits itself to single HOP attributes, and does not 110 address attributes valid for a LSP section [[This can be revised 111 based on feedback]] 113 3. ERO Attribute 115 The ERO Attributes subobject may be carried in the ERO or SERO object 116 if they are present. The subobject uses the standard format of an 117 ERO subobject. 119 3.1. ERO_ATTRIBUTE subobject 121 The length is variable and content MUST be the same as for the 122 LSP_ATTRIBUTE object with Attributes TLVs. The size of the ERO sub- 123 object limits the size of the LSP Attribute TLV to 250 bytes. The 124 typical size of currently defined and forthcoming LSP_ATTRIBUTE TLVs 125 applicable to a specific hop (WSON_SIGNALING, OF and Metric) is not 126 foreseen to exceed this limit. 128 The ERO attribute subobject is defined as follows: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |L| Type | Length | Reserved |R| 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 // Attributes TLVs // 137 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 See [RFC3209] for a description of L parameters. The attributes TLV 141 are encoded as defined in section Section 3.2. 143 Type x TBD by IANA. 145 Length The Length contains the total length of the subobject in 146 bytes, including the Type and Length fields. The Length MUST be 147 always divisible by 4. 149 Reserved Reserved, must be set to 0 when the subobject is inserted 150 in the ERO, MUST NOT be changed when a node process the ERO and 151 must be ignored on the node addressed by the preceding ERO 152 subobjects. 154 R This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE 155 semantic defined in [RFC5420]. When set indicates required LSP 156 attributes to be processed by the node, when cleared the LSP 157 attributes are not required as described in Section 3.3. 159 Attributes TLVs as defined in Section 3.2 . 161 3.2. HOP Attributes TLVs 163 ERO Attributes carried by the new objects defined in this document 164 are encoded within TLVs. One or more TLVs may be present in each 165 object. There are no ordering rules for TLVs, and no interpretation 166 should be placed on the order in which TLVs are received. 168 Each TLV is encoded as follows. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | | 176 // Value // 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Type The identifier of the TLV.. 182 Length Indicates the total length of the TLV in octets. That is, 183 the combined length of the Type, Length, and Value fields, i.e., 184 four plus the length of the Value field in octets. The entire TLV 185 MUST be padded with between zero and three trailing zeros to make 186 it four-octet aligned. The Length field does not count any 187 padding. 189 Value The data carried in the TLV. 191 3.3. Procedures 193 As described in [RFC3209] and [RFC3473] the ERO is managed as a list 194 where each hop information starts with a subobject identifying an 195 abstract node or link. The ERO attribute subobject must be appended 196 after the existing subobjects defined in [RFC3209], [RFC3473], 197 [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. Several 198 ERO attribute subobject MAY be present, for each hop. 200 If a node is processing an ERO attribute subobject and does not 201 support handling of the subobject it will behave as described in 202 [RFC3209] when an unrecognized ERO subobject is encountered. This 203 node will return a PathErr with error code "Routing Error" and error 204 value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object 205 included, truncated (on the left) to the offending unrecognized 206 subobject. 208 When the R bit is set a node MUST examine the attribute TLV present 209 in the subobject following the rules described in [RFC5420] section 210 5.2. When the R bit is not set a node MUST examine the attribute TLV 211 present in the subobject following the rules described in [RFC5420] 212 section 4.2. 214 A node processing an ERO attribute subobject with an HOP attribute 215 TLV longer than the ERO subobject SHOULD return a PathErr with error 216 code "Routing Error" and error value "Bad EXPLICIT_ROUTE object" with 217 the EXPLICIT_ROUTE object included, truncated (on the left) to the 218 offending malformed subobject. The processing of the Hop attribute 219 TLVs should be described in the documents defining them. 221 4. Recording Hop attribute per LSP 223 In some cases it is important to determine if an optional Hop 224 attribute has been processed by a node. 226 4.1. RRO Hop Attributes subobject 228 The RRO Hop Attributes subobject may be carried in the RECORD_ROUTE 229 object if it is present. The subobject uses the standard format of 230 an RRO subobject. 232 The RRO Hop attribute subobject is defined as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |L| Type | Length | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 // Attributes TLVs // 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 See [RFC3209] for a description of L parameters. The attributes TLV 245 are encoded as defined in section Section 3.2. 247 Type x TBD by IANA. 249 Length The Length contains the total length of the subobject in 250 bytes, including the Type and Length fields. The Length MUST be 251 always divisible by 4. 253 Reserved Reserved, must be set to 0 when the subobject is inserted 254 in the RRO, MUST NOT be changed when a node process the RRO and 255 must be ignored on the node addressed by the preceding RRO 256 subobjects. 258 Attributes TLVs The processed or addition HOP attributes, using the 259 format defined in Section 3.2 . 261 4.2. Procedures 263 4.2.1. Subobject presence rule 265 The RRO rules defined in [RFC3209] are not changed. The RRO Hop 266 attribute subobject must be pushed after the RRO attribute subobject 267 (if present) defined in in [RFC5420]. The RRO Hop attribute 268 subobject MAX be present between a pait of subobject identifying LSR 269 or links. All such subobjects MUST be forwarded unmodified by 270 transit LSRs. 272 4.2.2. Reporting Compliance with ERO Hop Attributes 274 To report that an ERO Hop attribute has been considered, or to report 275 an additional attribute, an LSR MAY add a RRO Hop Attributes 276 subobject with the HOP Attribute used. The requirement to report 277 compliance MUST be specified in the document that defines the usage 278 of an Hop attribute. [[This is not the most efficient encoding, a 279 more efficient encoding would use a bit field ala RFC5420 ]] 281 5. IANA Considerations 283 TBD once a final approach has been chosen. 285 6. Security Considerations 287 None. 289 7. Acknowledgments 291 The authors would like to thanks Lou Berger for his directions and 292 Attila Takacs for inspiring this 293 [I-D.kern-ccamp-rsvpte-hop-attributes]. The authors also thanks Dirk 294 Schroetter for his contribution to the initial versions of the 295 documents (version -00 up to -02). 297 8. References 299 8.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 305 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 306 Tunnels", RFC 3209, December 2001. 308 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 309 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 310 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 312 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 313 in Resource ReSerVation Protocol - Traffic Engineering 314 (RSVP-TE)", RFC 3477, January 2003. 316 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 317 "GMPLS Segment Recovery", RFC 4873, May 2007. 319 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 320 Extension to Resource ReserVation Protocol-Traffic 321 Engineering (RSVP-TE)", RFC 4874, April 2007. 323 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 324 Ayyangarps, "Encoding of Attributes for MPLS LSP 325 Establishment Using Resource Reservation Protocol Traffic 326 Engineering (RSVP-TE)", RFC 5420, February 2009. 328 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 329 Topology Confidentiality in Inter-Domain Path Computation 330 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 332 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 333 Reservation Protocol (RSVP) Extensions for Path Key 334 Support", RFC 5553, May 2009. 336 8.2. Informative References 338 [I-D.ali-ccamp-rc-objective-function-metric-bound] 339 Ali, Z., Swallow, G., Filsfils, C., Fang, L., Kumaki, K., 340 and R. Kunze, "Resource ReserVation Protocol-Traffic 341 Engineering (RSVP-TE) extension for signaling Objective 342 Function and Metric Bound", draft-ali-ccamp-rc-objective- 343 function-metric-bound-02 (work in progress), July 2012. 345 [I-D.dong-ccamp-rsvp-te-mpls-tp-li-lb] 346 Dong, J., Chen, M., and Z. Li, "GMPLS RSVP-TE Extensions 347 for Lock Instruct and Loopback", draft-dong-ccamp-rsvp-te- 348 mpls-tp-li-lb-05 (work in progress), December 2012. 350 [I-D.ietf-ccamp-wson-signaling] 351 Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H. 352 Harai, "Signaling Extensions for Wavelength Switched 353 Optical Networks", draft-ietf-ccamp-wson-signaling-06 354 (work in progress), July 2013. 356 [I-D.kern-ccamp-rsvpte-hop-attributes] 357 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 358 intermediate hops using RSVP-TE", draft-kern-ccamp-rsvpte- 359 hop-attributes-00 (work in progress), October 2009. 361 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 362 GMPLS and Path Computation Element (PCE) Control of 363 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 364 April 2011. 366 Authors' Addresses 368 Cyril Margaria (editor) 369 Coriant GmbH 370 St Martin Strasse 76 371 Munich 81541 372 Germany 374 Phone: +49 89 5159 16934 375 Email: cyril.margaria@coriant.com 376 Giovanni Martinelli 377 Cisco 378 via Philips 12 379 Monza 20900 380 IT 382 Phone: +39 039 209 2044 383 Email: giomarti@cisco.com 385 Steve Balls 386 Metaswitch 387 100 Church Street 388 Enfield EN2 6BQ 389 UJ 391 Phone: +44 208 366 1177 392 Email: steve.balls@metaswitch.com 394 Ben Wright 395 Metaswitch 396 100 Church Street 397 Enfield EN2 6BQ 398 UJ 400 Phone: +44 208 366 1177 401 Email: Ben.Wright@metaswitch.com