idnits 2.17.1 draft-ietf-dime-qos-parameters-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 -- 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 (May 25, 2009) is 5448 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) H. Tschofenig 4 Internet-Draft Nokia Siemens Networks 5 Intended status: Standards Track E. Davies 6 Expires: November 26, 2009 Folly Consulting 7 May 25, 2009 9 Quality of Service Parameters for Usage with Diameter 10 draft-ietf-dime-qos-parameters-11.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 26, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines a number of Quality of Service (QoS) parameters 49 that can be reused for conveying QoS information within Diameter. 51 The defined QoS information includes data traffic parameters for 52 describing a token bucket filter, a bandwidth parameter, and a per- 53 hop behavior class object. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 59 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 60 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 62 3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4 63 3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4 64 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 5 65 3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 5 66 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 68 3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5 69 3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5 70 3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 6 71 3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6 72 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 This document defines a number of Quality of Service (QoS) parameters 84 that can be reused for conveying QoS information within the Diameter 85 protocol [RFC3588]. The current set of QoS parameters defined in 86 this document are a core subset determined to be useful for a wide 87 range of applications. Additional parameters may be defined in 88 future documents as the need arises and are for future study. The 89 parameters are defined as Diameter encoded Attribute Value Pairs 90 (AVPs) described using a modified version of the Augmented Backus- 91 Naur Form (ABNF), see [RFC3588]. The datatypes are also taken from 92 [RFC3588]. 94 The traffic model (TMOD) AVPs are containers consisting of four AVPs 95 and is a way to describe the traffic source. 97 o token rate (r) 98 o bucket depth (b) 99 o peak traffic rate (p) 100 o minimum policed unit (m) 101 o maximum packet size (M) 103 The encoding of the and the AVP can be found in 104 Section 3.1 and Section 3.2. The semantics of these two AVPs are 105 described in Section 3.1 of [RFC2210] and in Section 3.6 of 106 [RFC2215]. 108 The AVP is, for example, needed by some DiffServ 109 applications. 110 It is typically assumed that DiffServ EF traffic is shaped at the 111 ingress by a single rate token bucket. Therefore, a single TMOD 112 parameter is sufficient to signal DiffServ EF traffic. However, 113 for DiffServ AF traffic two sets of token bucket parameters are 114 needed, one token bucket for the average traffic and one token 115 bucket for the burst traffic. [RFC2697] defines a Single Rate 116 Three Color Marker (srTCM), which meters a traffic stream and 117 marks its packets according to three traffic parameters, Committed 118 Information Rate (CIR), Committed Burst Size (CBS), and Excess 119 Burst Size (EBS), to be either green, yellow, or red. A packet is 120 marked green if it does not exceed the CBS, yellow if it does 121 exceed the CBS, but not the EBS, and red otherwise. [RFC2697] 122 defines specific procedures using two token buckets that run at 123 the same rate. Therefore, two TMOD AVPs are sufficient to 124 distinguish among three levels of drop precedence. An example is 125 also described in the appendix of [RFC2597]. 127 Resource reservations might refer to a packet processing with a 128 particular DiffServ per-hop behavior (PHB) (using the 129 AVP). A generic description of the DiffServ architecture can be 130 found in [RFC2475] and the Differentiated Services Field is described 131 in Section 3 of [RFC2474]. Updated terminology can be found in 132 [RFC3260]. Standardized Per-Hop Behavior is, for example, described 133 in [RFC2597] (Assured Forwarding Per-Hop Behavior) and in [RFC3246] 134 (An Expedited Forwarding Per-Hop Behavior). 136 The above-mentioned parameters are intended to support basic 137 integrated and differentiated services functionality in the network. 138 Additional parameters can be defined and standardized if required to 139 support specific services in future. 141 2. Terminology and Abbreviations 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC2119 [RFC2119]. 147 3. QoS Parameter Encoding 149 3.1. TMOD-1 AVP 151 The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The 152 structure of the AVP is as follows: 154 TMOD-1 ::= < AVP Header: TBD > 155 { Token-Rate } 156 { Bucket-Depth } 157 { Peak-Traffic-Rate } 158 { Minimum-Policed-Unit } 159 { Maximum-Packet-Size } 161 3.1.1. Token-Rate AVP 163 The Token-Rate AVP (AVP Code TBD) is of type Float32. 165 3.1.2. Bucket-Depth AVP 167 The Bucket-Depth AVP (AVP Code TBD) is of type Float32. 169 3.1.3. Peak-Traffic-Rate AVP 171 The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32. 173 3.1.4. Minimum-Policed-Unit AVP 175 The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32. 177 3.1.5. Maximum-Packet-Size AVP 179 The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32. 181 3.2. TMOD-2 AVP 183 A description of the semantic of the parameter values can be found in 184 [RFC2215]. The coding for the TMOD-2 AVP is as follows: 186 TMOD-2 ::= < AVP Header: TBD > 187 { Token-Rate } 188 { Bucket-Depth } 189 { Peak-Traffic-Rate } 190 { Minimum-Policed-Unit } 191 { Maximum-Packet-Size } 193 3.3. Bandwidth AVP 195 The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured 196 in octets of IP datagrams per second. The Bandwidth AVP represents a 197 simplified description of the following TMOD setting whereby the 198 token rate (r) = peak traffic rate (p), the bucket depth (b) = large, 199 minimum policed unit (m) = large when only bandwidth has to be 200 expressed. 202 3.4. PHB-Class AVP 204 The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. 206 A description of the semantic of the parameter values can be found in 207 [RFC3140]. The registries needed for usage with [RFC3140] already 208 exist and hence no new registry needs to be created by this document. 209 The encoding requires three cases need to be differentiated. All 210 bits indicated as "reserved" MUST be set to zero (0). 212 3.4.1. Case 1: Single PHB 214 As prescribed in [RFC3140], the encoding for a single PHB is the 215 recommended DSCP value for that PHB, left-justified in the 16 bit 216 field, with bits 6 through 15 set to zero. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 3.4.2. Case 2: Set of PHBs 226 The encoding for a set of PHBs is the numerically smallest of the set 227 of encodings for the various PHBs in the set, with bit 14 set to 1. 228 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 229 bit 14 set to 1.) 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 3.4.3. Case 3: Experimental or Local Use PHBs 239 PHBs not defined by standards action, i.e., experimental or local use 240 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 241 identification code, assigned by the IANA, is placed left-justified 242 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 243 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 245 Bits 12 and 13 are reserved either for expansion of the PHB 246 identification code, or for other use, at some point in the future. 248 In both cases, when a single PHBID is used to identify a set of PHBs 249 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 250 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 251 intra-microflow traffic reordering when different PHBs from the set 252 are applied to traffic in the same microflow). The set of AF1x PHBs 253 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 254 do not constitute a PHB Scheduling Class can be identified by using 255 more than one PHBID. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | PHD ID CODE |0 0 1 0| (Reserved) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 4. Extensibility 265 This document is designed with extensibility in mind given that 266 different organizations and groups are used to defining their own 267 Quality of Service parameters. This document provides an initial QoS 268 profile with common set of parameters. Ideally, these parameters 269 should be used whenever possible but there are cases where additional 270 parameters might be needed, or where the parameters specified in this 271 document are used with a different semantic. In that case it is 272 advisable to define a new QoS profile that may consist of new 273 parameters in addition to parameters defined in this document or an 274 entirely different set of parameters. Finally, it is also possible 275 to register a specific QoS profile that defines a specific set of QoS 276 values rather than parameters that need to be filled with values in 277 order to be used. 279 To enable the definition of new QoS profiles a 8 octet registry is 280 defined field that is represented by a 4-octet vendor and 4-octet 281 specifier field. The vendor field contains an Enterprise Number as 282 defined in [RFC2578] taken from the values maintained in the IANA 283 Enterprise Numbers registry. If the four octets of the vendor field 284 are 0x00000000 (reserved value for IANA), then the value in the 285 specifier field MUST be registered with IANA (see Section 5.2). If 286 the vendor field is other than 0x00000000, the value of the specifier 287 field represents a vendor-specific value, where allocation is the 288 responsibility of the enterprise indicated in the vendor field. 290 5. IANA Considerations 292 5.1. AVP Codes 294 IANA is requested to allocate AVP codes in the IETF IANA controlled 295 namespace registry specified in Section 11.1.1 of [RFC3588] for the 296 following AVPs that are defined in this document. 298 +------------------------------------------------------------------+ 299 | AVP Section | 300 |AVP Name Code Defined Data Type | 301 +------------------------------------------------------------------+ 302 |TMOD-1 TBD 3.1 Grouped | 303 |Token-Rate TBD 3.1.1 Float32 | 304 |Bucket-Depth TBD 3.1.2 Float32 | 305 |Peak-Traffic-Rate TBD 3.1.3 Float32 | 306 |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | 307 |Maximum-Packet-Size TBD 3.1.5 Unsigned32 | 308 |TMOD-2 TBD 3.2 Grouped | 309 |Bandwidth TBD 3.3 Float32 | 310 |PHB-Class TBD 3.7 Unsigned32 | 311 +------------------------------------------------------------------+ 313 5.2. QoS Profile 315 The QoS Profile refers to a 64 bit long field that is represented by 316 a 4-octet vendor and 4-octet specifier field. The vendor field 317 indicates the type as either standards-specified or vendor-specific. 319 If the four octets of the vendor field are 0x00000000, then the value 320 is standards-specified and a registry will be created to maintain the 321 QoS profile specifier values. The specifier field indicates the 322 actual QoS profile. Depending on the value requested, the action 323 needed to request a new value is: 324 0 to 511: Standards Action 325 512 to 32767: Specification Required 326 32768 to 4294967295: Reserved 328 Standards action is required to add, depreciate, delete, or modify 329 QoS profile values in the range of 0-511 and a specification is 330 required to add, depreciate, delete, or modify existing QoS profile 331 values in the range of 512-32767. 333 This document requests IANA to create such a registry and to allocate 334 the value zero (0) for the QoS profile defined in this document. 336 Alternative vendor-specific QoS profiles can be created and 337 identified with a Enterprise Number taken from the IANA registry 338 created by [RFC2578] in the vendor field combined with a vendor- 339 specific value in the specifier field. Allocation of the specifier 340 values is the responsibility of the vendor. 342 6. Security Considerations 344 This document does not raise any security concerns as it only defines 345 QoS parameters and does not yet describe how they are exchanged in a 346 AAA protocol. Security considerations are described in documents 347 using this specification. 349 7. Acknowledgements 351 The authors would like to thank the NSIS working group members 352 Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran, the former 353 NSIS working group chairs (John Loughney and Martin Stiemerling) and 354 the former Transport Area Directors (Allison Mankin, Jon Peterson) 355 for their help. 357 We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, 358 Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James 359 Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for 360 their feedback regarding some of the parameters in this documents. 362 Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided 363 help with the semantic of some QSPEC parameters. 365 We would like to thank Dan Romascanu for his detailed Area Director 366 review comments and Scott Bradner for his Transport Area Directorate 367 review. Chris Newman, Adrian Farrel and Pasi Eronen provided 368 feedback during the IESG review. 370 8. References 372 8.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 378 Services", RFC 2210, September 1997. 380 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 381 Parameters for Integrated Service Network Elements", 382 RFC 2215, September 1997. 384 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 385 "Definition of the Differentiated Services Field (DS 386 Field) in the IPv4 and IPv6 Headers", RFC 2474, 387 December 1998. 389 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 390 Schoenwaelder, Ed., "Structure of Management Information 391 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 393 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 394 "Per Hop Behavior Identification Codes", RFC 3140, 395 June 2001. 397 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 398 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 400 8.2. Informative References 402 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 403 and W. Weiss, "An Architecture for Differentiated 404 Services", RFC 2475, December 1998. 406 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 407 "Assured Forwarding PHB Group", RFC 2597, June 1999. 409 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 410 Marker", RFC 2697, September 1999. 412 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 413 J., Courtney, W., Davari, S., Firoiu, V., and D. 414 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 415 Behavior)", RFC 3246, March 2002. 417 [RFC3260] Grossman, D., "New Terminology and Clarifications for 418 Diffserv", RFC 3260, April 2002. 420 Authors' Addresses 422 Jouni Korhonen (editor) 423 Nokia Siemens Networks 424 Linnoitustie 6 425 Espoo 02600 426 Finland 428 Email: jouni.korhonen@nsn.com 429 Hannes Tschofenig 430 Nokia Siemens Networks 431 Linnoitustie 6 432 Espoo 02600 433 Finland 435 Phone: +358 (50) 4871445 436 Email: Hannes.Tschofenig@gmx.net 437 URI: http://www.tschofenig.priv.at 439 Elwyn Davies 440 Folly Consulting 441 Soham 442 UK 444 Phone: +44 7889 488 335 445 Email: elwynd@dial.pipex.com