idnits 2.17.1 draft-dimitri-mef-ethernet-traffic-parameters-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 418. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 50 == Missing Reference: 'MEF10' is mentioned on line 180, but not defined == Missing Reference: 'RFC1832' is mentioned on line 266, but not defined ** Obsolete undefined reference: RFC 1832 (Obsoleted by RFC 4506) == Unused Reference: 'RFC2119' is defined on line 337, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Dimitri Papadimitriou 5 Category: Informational 6 Expires: August 2006 February 2006 8 MEF Ethernet Traffic Parameters 10 draft-dimitri-mef-ethernet-traffic-parameters-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 For potential updates to the above required-text see: 36 http://www.ietf.org/ietf/1id-guidelines.txt 38 Abstract 40 This document described the Metro Ethernet Forum (MEF) - specific 41 Ethernet Traffic Parameters as described in MEF.10 when using 42 Generalized Multi-Protocol Label Switching (GMPLS) Resource 43 ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [1]. 51 Moreover, the reader is assumed to be familiar with the terminology 52 MEF.10 as well as [RFC3471] and [RFC3473]. 54 1. Introduction 56 Per [RFC3471], GMPLS allows the inclusion of technology specific 57 parameters in signaling. Ethernet SENDER_TSPEC and FLOWSPEC specific 58 objects are introduced in this document that describes Metro Ethernet 59 Forum (MEF) Ethernet traffic parameters as specified in [MEF.10]. 61 These traffic parameters MUST be used when L2SC is specified in the 62 LSP Switching Type field of a Generalized Label Request (see 63 [RFC3471]) and the LSP encoding type is Ethernet. 65 2. Overview 67 The Ethernet SENDER_TSPEC/FLOWSPEC object includes the Ethernet link 68 type (switching granularity) of the requested LSP, and the MTU value 69 for the LSP. 71 As the Bandwidth Profile defines the set of traffic parameters 72 applicable to a sequence of Service Frames, these objects MAY also 73 include several bandwidth profile parameters such as: 75 - Committed Rate: defines the rate at which traffic commits to 76 be sent to the Ethernet LSP. The Committed Rate is described in 77 terms of the CIR (Committed Information Rate) and CBS (Committed 78 Burst Size) traffic parameters. 80 CIR is defined as the average rate (in bytes per unit of time) 81 up to which the network is committed to transfer frames and 82 meets performance objectives. 84 CBS defines a limit on the maximum number of information units 85 (e.g. bytes) available for a burst of frames sent at the 86 interface speed to remain CIR-conformant. 88 - Excess Rate: defines the extent by which the traffic sent on a 89 Ethernet LSP exceeds the committed rate. The Excess Rate is 90 described in terms of the EIR (Excess Information Rate) and EBS 91 (Excess Burst Size) traffic parameters. 93 EIR is defined as the average rate (in bytes per unit of time), 94 in excess of the CIR, up to which the network may transfer 95 frames without any performance objectives. 97 EBS defines a limit on the maximum number of information units 98 (e.g. bytes) available for a burst of frames sent at the 99 interface speed to remain EIR-conformant. 101 - The color mode (CM) parameter indicates whether the "color- 102 aware" or "color-blind" property is employed by the bandwidth 103 profile. 105 - The coupling flag (CF) parameter allows the choice between two 106 modes of operations of the rate enforcement algorithm. 108 3. Ethernet SENDER_TSPEC object 110 The Ethernet SENDER_TSPEC object (Class-Num = 12, Class-Type = TBA by 111 IANA) has the following format: 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Length | Class-Num (12)| C-Type (TBA) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Switching Granularity | MTU | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | 121 ~ TLVs ~ 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Switching Granularity (SG): 16 bits 127 This field indicates the type of link that comprises the 128 requested Ethernet LSP. 130 The permitted Ethernet Link Type values: 132 Value Switching Granularity 133 ----- --------------------- 134 1 Ethernet Port 135 2 Ethernet Frame 137 Value 0 is reserved. Values 1 through 127 are assigned by IANA via 138 IETF Standards Track RFC action. 140 Values 128 through 255 are reserved for vendor specific usage. 142 MTU: 16 bits 143 This is a two-octet value indicating the MTU in octets. 145 The MTU MUST NOT take a value smaller than 46 bytes for Ethernet 146 v2 and 38 bytes for IEEE 802.3. 148 TLV: 150 The Ethernet SENDER_TSPEC object MUST include at least one TLV 151 and MAY include one or more than one optional TLV. 153 Each TLV has the following format: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 ~ Value ~ 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Length: 16 bits 167 Indicates the total length of the TLV, i.e., 4 + the length 168 of the value field in octets. A value field whose length is 169 not a multiple of four MUST be zero-padded (with trailing 170 zeros) so that the TLV is four-octet aligned. 172 Type: 16 bits 174 Defined values are: 176 Type Length Format Description 177 -------------------------------------------------- 178 128 20 Reserved Reserved 179 129 24 see below Ethernet Bandwidth 180 Profile [MEF10] 182 Value 0 is reserved. Values 1 through 127 are assigned by 183 IANA via IETF Standards Track RFC Action. 185 Values 128 through 255 are reserved for vendor specific 186 usage. 188 3.1 Ethernet Bandwidth Profile TLV 190 Type 129 TLV indicates the Ethernet Bandwidth Profile. It defines 191 an upper bound on the volume of the expected service frames belonging 192 to a particular Ethernet service instance. 194 The Type 129 TLV has the following format: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Profile | Reserved | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | CIR | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | CBS | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | EIR | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | EBS | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Profile: 8 bits (this field is to be registered by IANA) 212 This field is defined as a vector of binary flags. The following 213 flags are defined: 215 Flag 1 (bit 1): coupling flag (CF) 216 Flag 2 (bit 2): color mode (CM) 218 Where bit 1 is the low order bit. Other flags are reserved, 219 they SHOULD be set to zero when sent, and SHOULD be ignored when 220 received. 222 A flag is set to one to indicate that the corresponding metering 223 is requested. 225 The Flag 1 allows the choice between two modes of operations of 226 the rate enforcement algorithm. 228 The Flag 2 indicates whether the color-aware or color-blind 229 property is employed by the bandwidth profile. When Flag 2 is set 230 to 0 (1), the bandwidth profile algorithm is said to be in 231 color blind (color aware) mode. 233 Reserved: 24 bits 235 These bits SHOULD be set to zero when sent and MUST be ignored 236 when received. 238 CIR (Committed Information Rate): 32 bits 239 The value of the CIR is in units of bytes per second. The CIR is 240 encoded as a 32-bit IEEE single-precision floating-point number 241 (see [RFC1832]). 243 The CIR value MUST be greater than or equal to 0. 245 CBS (Committed Burst Size): 32 bits 247 The value of the CBS is in units of bytes. The CBS is encoded 248 as a 32-bit IEEE single-precision floating-point number (see 249 [RFC1832]). 251 When CIR is strictly greater than 0 (CIR > 0), the CBS MUST be 252 greater than or equal to the maximum frame size. 254 EIR (Excess Information Rate): 32 bits 256 The value of the EIR is in units of bytes per second. The EIR 257 is encoded as a 32-bit IEEE single-precision floating-point 258 number (see [RFC1832]). 260 The EIR value MUST be greater than or equal to 0. 262 EBS (Excess Burst Size): 32 bits 264 The value of the EBS is in units of bytes. The EBS is encoded 265 as a 32-bit IEEE single-precision floating-point number (see 266 [RFC1832]). 268 When EIR is strictly greater than 0 (EIR > 0), the EBS MUST be 269 greater than or equal to the maximum frame size. 271 4. Ethernet FLOWSPEC format 273 The Ethernet FLOWSPEC object (Class-Num = 12, Class-Type = TBA by 274 IANA) has the same format as the Ethernet SENDER_TSPEC object. 276 5. ADSPEC considerations 278 There is no ADSPEC associated with the Ethernet SENDER_TSPEC object. 280 Either the ADSPEC is omitted or an Int-serv ADSPEC with the Default 281 General Characterization Parameters and Guaranteed Service fragment 282 is used, see [RFC2210]. 284 6. Processing 286 The Ethernet SENDER_TSPEC object carries the traffic specification 287 generated by the RSVP session sender. The Ethernet SENDER_TSPEC 288 object SHOULD be forwarded and delivered unchanged to both 289 intermediate and egress nodes. 291 The Ethernet FLOWSPEC object carries reservation request information 292 generated by receivers. As with any FLOWSPEC object, the information 293 content of the Ethernet FLOWSPEC object flows upstream toward the 294 ingress node. 296 Intermediate and egress nodes MUST verify that the node itself and 297 the interfaces on which the LSP will be established can support the 298 requested Switching Granularity, MTU and values included in sub- 299 object TLVs. If the requested value(s) can not be supported, the 300 receiver node MUST generate a PathErr message with a "Traffic 301 Control Error/Service unsupported" indication (see [RFC2205]). 303 In addition, if the MTU field is received with a value smaller than 304 the minimum transfer unit size of the Ethernet frame (e.g. 46 bytes 305 for Ethernet v2, 38 bytes for IEEE 802.3), the node MUST generate a 306 PathErr message with a "Traffic Control Error/ Bad Tspec value" 307 indication (see [RFC2205]). 309 7. Security Considerations 311 This document introduces no new security considerations to either 312 [RFC3473]. 314 GMPLS security is described in section 11 of [RFC3471] and refers to 315 [RFC3209] for RSVP-TE. 317 8. IANA Considerations 319 Two values have been defined by IANA for this document: 321 Two RSVP C-Types in registry: 322 http://www.iana.org/assignments/rsvp-parameters 324 - An Ethernet SENDER_TSPEC object: Class = 12, C-Type = TBA (see 325 Section 3). 327 - An Ethernet FLOWSPEC object: Class = 9, C-Type = TBA (see 328 Section 4). 330 9. References 332 9.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 341 Jamin, "Resource ReSerVation Protocol (RSVP) -- 342 Version 1 Functional Specification", RFC 2205, 343 September 1997. 345 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 346 Services", RFC 2210, September 1997. 348 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 349 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 350 LSP Tunnels", RFC 3209, December 2001. 352 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 353 Switching (GMPLS) Signaling Functional Description", 354 RFC 3471, January 2003. 356 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 357 Switching (GMPLS) Signaling Resource ReserVation 358 Protocol-Traffic Engineering (RSVP-TE) Extensions", 359 RFC 3473, January 2003. 361 9.2. Informative References 363 [MEF.10] MEF Technical Specification, "Ethernet Services 364 Attributes Phase 1", MEF 10, November 2004. 366 10. Acknowledgments 368 Many thanks to Adrian Farrel for his comments. 370 11. Author's Addresses 372 Dimitri Papadimitriou 373 Alcatel 374 Francis Wellesplein 1, 375 B-2018 Antwerpen, Belgium 377 Phone: +32 3 2408491 378 EMail: dimitri.papadimitriou@alcatel.be 380 Full Copyright Statement 382 Copyright (C) The Internet Society (2006). 384 This document is subject to the rights, licenses and restrictions 385 contained in BCP 78, and except as set forth therein, the authors 386 retain all their rights. 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 391 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 392 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 393 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Intellectual Property 398 The IETF takes no position regarding the validity or scope of any 399 Intellectual Property Rights or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; nor does it represent that it has 403 made any independent effort to identify any such rights. Information 404 on the procedures with respect to rights in RFC documents can be 405 found in BCP 78 and BCP 79. 407 Copies of IPR disclosures made to the IETF Secretariat and any 408 assurances of licenses to be made available, or the result of an 409 attempt made to obtain a general license or permission for the use of 410 such proprietary rights by implementers or users of this 411 specification can be obtained from the IETF on-line IPR repository at 412 http://www.ietf.org/ipr. 414 The IETF invites any interested party to bring to its attention any 415 copyrights, patents or patent applications, or other proprietary 416 rights that may cover technology that may be required to implement 417 this standard. Please address the information to the IETF at ietf- 418 ipr@ietf.org.