idnits 2.17.1 draft-margaria-ccamp-lsp-attribute-ero-03.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 255 has weird spacing: '... Type x TBD...' -- The document date (February 06, 2013) is 4096 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 (~~), 2 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 Nokia Siemens Networks 4 Intended status: Standards Track G. Martinelli 5 Expires: August 10, 2013 Cisco 6 S. Balls 7 B. Wright 8 Metaswitch 9 February 06, 2013 11 LSP Attribute in ERO 12 draft-margaria-ccamp-lsp-attribute-ero-03 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 August 10, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Non solution . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Extended ERO Object . . . . . . . . . . . . . . . . . . . 5 62 3.2.1. Semantic of the Extended ERO object . . . . . . . . . 5 63 3.2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2.3. Subobjects . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.4. Processing . . . . . . . . . . . . . . . . . . . . . . 9 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 77 Paths (LSPs) can be route-constrained by making use of the Explicit 78 Route (ERO) object and related sub-objects as defined in [RFC3209], 79 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 80 This document proposes mechanisms to target LSP attributes at a 81 specific hop. This document presents several solutions for 82 discussion, final document will contains only one document after WG 83 consensus. 85 1.1. Contributing Authors 87 1.2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Requirements 95 The requirement is to provide a generic mechanism to carry 96 information related to specific nodes when signaling an LSP. This 97 document does not restrict what that information can be used for. 98 LSP attribute defined [RFC5420] should be expressed in ERO and SERO 99 objects. 101 3. Solutions 103 3.1. Non solution 105 A solution using a specific ERO or SERO subobject is not used because 106 the subobject length is limited to 8 bit, versus 16 bit for LSP 107 ATTRIBUTES. This does not allow to put LSP ATTRIBUTE subobjects in 108 ERO subobjects. 110 3.2. Extended ERO Object 112 The logic of the EXTENDED_EXPLICIT_ROUTE follows the one of SERO.The 113 class of the EXTENDED_EXPLICIT_ROUTE object is xxx (of the form 114 11bbbbbb). The EXTENDED_EXPLICIT_ROUTE object has the following 115 format: Class = xxx, C_Type = 1 The EXTENDED_EXPLICIT_ROUTE object 116 may be used if some node along the explicit route support this 117 object. The EXTENDED_EXPLICIT_ROUTE object is assigned a class value 118 of the form 11bbbbbb, so it is forwarded by nodes not supporting it. 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | | 124 // (Subobjects) // 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Subobjects The contents of an EXTENDED_EXPLICIT_ROUTE object are a 129 series of variable- length data items called subobjects. The 130 subobjects are defined in section Section 3.2.3 below. 132 3.2.1. Semantic of the Extended ERO object 134 Extended ERO object is carried in Path messages and carries a list of 135 hops extended with hop-specific information. It is structured as a 136 sequence of hop identifier subobjects (to indicate the hop who should 137 process the subsequent attributes) and a series of hop attributes 138 (which may be mandatory or optional) for the specified hop to 139 process. 141 3.2.2. Procedures 143 If a Path message contains multiple EXTENDED_EXPLICIT_ROUTE objects, 144 only the first object is meaningful. Subsequent 145 EXTENDED_EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be 146 propagated. An EXTENDED_EXPLICIT_ROUTE SHOULD contain at least 2 147 subobjects. The first subobject MUST indicate a node or link that 148 identifies a hop that should process the next subobject(s). The 149 address used to identify the hop SHOULD also be listed in the ERO or 150 an SERO. This ensures that the extended attribute is for a node or 151 link along the LSP path. The second subobject SHOULD contains an 152 extended node or link information. In this document this SHOULD be a 153 LSP Attribute subobject. 155 3.2.3. Subobjects 157 The content of an EXTENDED_EXPLICIT_ROUTE are a series of variable 158 length subobjects. Each subobject has the following form 160 0 1 2 161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------//-----------+ 163 | Type | Length | (Subobject contents)| 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------//-----------+ 166 The Type indicates the type of contents of the subobject. Currently 167 defined values are: 169 1 Hop identifier subobject containing an ERO subobject: 171 IPv4 prefix 173 IPv6 prefix 175 Unnumbered Interface ID 177 Autonomous system number 179 Path Key with 32-bit PCE ID 181 Path Key with 128-bit PCE ID 183 Per-hop attributes: 185 XX LSP Attribute 187 Length The Length contains the total length of the subobject in 188 bytes, including the Type and Length . The Length MUST be at least 189 4, and MUST be a multiple of 4. 191 3.2.3.1. Hop identifier 193 The Hop identifier subobject contains exactly one ERO subobject 194 identifying a hop. The value of the subobject is a copy of the ERO 195 subobject definition. The format of the subobject is as follow: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length |L| sub Type | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Sub Length | (Subobject contents) ... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Type 0x01 Hop Identifier 207 Length The Length contains the total length of the subobject in 208 bytes, including the Type and Length fields. 210 Sub type The ERO subobject type, the same as the ERO subobject type. 211 the ERO type defined are : 213 1 IPv4 prefix 215 2 IPv6 prefix 217 3 Reserved 219 4 Unnumbered Interface ID 221 32 Autonomous system number 223 33 Reserved 225 37 Reserved 227 64 Path Key with 32-bit PCE ID 229 65 Path Key with 128-bit PCE ID 231 Sub length The ERO subobject type, the same as the ERO subobject 232 length. It its unchanged compared to the ERO subobject 233 definition. 235 Subobject contents The ERO subobject content, it its unchanged 236 compared to the ERO subobject definition. 238 3.2.3.2. Hop LSP Attribute 240 The LSP attribute subobject contains information targeted at the hop 241 identified by the preceding hop identifier subobject. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Reserved |R| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 // Attributes TLVs // 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 The attributes TLV are encoded as defined in [RFC5420] section 3. 255 Type x TBD by IANA. 257 Length The Length contains the total length of the subobject in 258 bytes, including the Type and Length fields. The Length MUST be 259 always divisible by 4. 261 Reserved Reserved, must be set to 0 when the subobject is inserted 262 in the ERO, MUST NOT be changed when a node process the ERO and 263 must be ignored on the node addressed by the preceding ERO 264 subobjects 266 R This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE 267 semantic. When set indicates required LSP attributes to be 268 processed by the node, when cleared the LSP attributes are not 269 required as described in Section 3.2.3.3. 271 3.2.3.3. Processing 273 Following [RFC3209] and [RFC3473] the Extended ERO is managed as a 274 list where each hop information starts with a subobject identifying 275 an abstract node or link. The LSP attribute subobject must be 276 appended after the hop identifier subobject (which follows the 277 formatting of the objects defined in [RFC3209], [RFC3473], [RFC3477], 278 [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. Several LSP attribute 279 subobject MAY be present for each hop identification object. 281 When the R bit is set a node MUST examine the attribute TLV present 282 in the subobject following the rules described in [RFC5420] section 283 5.2. When the R bit is not set a node MUST examine the attribute TLV 284 present in the subobject following the rules described in [RFC5420] 285 section 4.2. If more than one ERO LSP attribute subobject having the 286 R bit set is present, the first one MUST be processed and the others 287 SHOULD be ignored. If more than one ERO LSP attribute subject having 288 the R bit cleared is present for the same hop identification object, 289 then the first one MUST be processed and the others SHOULD be 290 ignored. 292 3.2.4. Processing 294 A node receiving a Path message containing an EXTENDED_EXPLICIT_ROUTE 295 object must determine if the extended hop information is applicable 296 for this node. The node performs the following steps: 298 1. The node receiving the RSVP message MUST first evaluate if the 299 ERO object is present. If the ERO object is not present it has 300 received the message in error and SHOULD return a pathError 301 message. 303 2. Second the node MUST read the first subobject. If the node is 304 not part of the abstract node described by the first subobject, 305 the processing stops. 307 3. If there is no second subobject this indicates the end of the 308 extended ERO. The extended ERO SHOULD be removed from the Path 309 message. A new extended ERO MAY be added to the Path message. 311 4. Next the node evaluates the second subobject. 313 A. If the subobject identified an abstract node and the node is 314 also part of the abstract node, then the node deletes the 315 first subobject and continue processing with step 3. 317 B. If the subobject identified an abstract node and the node is 318 not part of the abstract node, then the extended ERO is 319 invalid and the node SHOULD return a PathErr with error code 320 "Routing Error" and error value "Bad EXTENDED_EXPLICIT_ROUTE 321 object" with the EXTENDED_EXPLICIT_ROUTE object included, 322 truncated (on the left) to the offending unrecognized 323 subobject 325 C. If the subobject is an LSP Attribute subobject it processes 326 it according to the rules for that subobject and removes it 327 from the extended ERO. If the extended ERO does not contain 328 further subject it SHOULD be removed from the Path message. 329 A new extended ERO MAY be added to the Path message. 331 If a node finds a hop identification object which matches the local 332 router handling of the subobject it will behave as described in 334 [RFC3209] when an unrecognized ERO subobject is encountered. This 335 node will return a PathErr with error code "Routing Error" and error 336 value "Bad EXTENDED_EXPLICIT_ROUTE object" with the 337 EXTENDED_EXPLICIT_ROUTE object included, truncated (on the left) to 338 the offending unrecognized subobject. 340 4. IANA Considerations 342 TBD once a final approach has been chosen. 344 5. Security Considerations 346 None. 348 6. Acknowledgments 350 The authors would like to thanks Lou Berger for his directions and 351 Attila Takacs for inspiring this 352 [I-D.kern-ccamp-rsvpte-hop-attributes]. The authors also thanks Dirk 353 Schroetter for his contribution to the initial versions of the 354 documents (version -00 up to -02). 356 7. References 358 7.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 364 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 365 Tunnels", RFC 3209, December 2001. 367 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 368 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 369 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 371 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 372 in Resource ReSerVation Protocol - Traffic Engineering 373 (RSVP-TE)", RFC 3477, January 2003. 375 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 376 "GMPLS Segment Recovery", RFC 4873, May 2007. 378 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 379 Extension to Resource ReserVation Protocol-Traffic 380 Engineering (RSVP-TE)", RFC 4874, April 2007. 382 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 383 Ayyangarps, "Encoding of Attributes for MPLS LSP 384 Establishment Using Resource Reservation Protocol Traffic 385 Engineering (RSVP-TE)", RFC 5420, February 2009. 387 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 388 Topology Confidentiality in Inter-Domain Path Computation 389 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 391 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 392 Reservation Protocol (RSVP) Extensions for Path Key 393 Support", RFC 5553, May 2009. 395 7.2. Informative References 397 [I-D.kern-ccamp-rsvpte-hop-attributes] 398 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 399 intermediate hops using RSVP-TE", 400 draft-kern-ccamp-rsvpte-hop-attributes-00 (work in 401 progress), October 2009. 403 Authors' Addresses 405 Cyril Margaria (editor) 406 Nokia Siemens Networks 407 St Martin Strasse 76 408 Munich, 81541 409 Germany 411 Phone: +49 89 5159 16934 412 Email: cyril.margaria@nsn.com 414 Giovanni Martinelli 415 Cisco 416 via Philips 12 417 Monza 20900 418 IT 420 Phone: +39 039 209 2044 421 Email: giomarti@cisco.com 423 Steve Balls 424 Metaswitch 425 100 Church Street 426 Enfield EN2 6BQ 427 UJ 429 Phone: +44 208 366 1177 430 Email: steve.balls@metaswitch.com 432 Ben Wright 433 Metaswitch 434 100 Church Street 435 Enfield EN2 6BQ 436 UJ 438 Phone: +44 208 366 1177 439 Email: Ben.Wright@metaswitch.com