idnits 2.17.1 draft-ietf-dime-qos-parameters-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 871. 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 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 26, 2008) is 5806 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 (-15) exists of draft-ietf-tsvwg-emergency-rsvp-08 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-20 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 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) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: November 27, 2008 May 26, 2008 8 Quality of Service Parameters for Usage with the AAA Framework 9 draft-ietf-dime-qos-parameters-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 27, 2008. 36 Abstract 38 This document defines a number of Quality of Service (QoS) parameters 39 that can be reused for conveying QoS information within RADIUS and 40 Diameter. 42 The payloads used to carry these QoS parameters are opaque for the 43 AAA client and the AAA server itself and interpreted by the 44 respective Resource Management Function. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 1.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 4 50 1.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 4 51 1.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 52 1.4. Traffic Classes . . . . . . . . . . . . . . . . . . . . . 5 53 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6 54 3. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1.1. TMOD-Rate-1 AVP . . . . . . . . . . . . . . . . . . . 6 57 3.1.2. TMOD-Size-1 AVP . . . . . . . . . . . . . . . . . . . 6 58 3.1.3. Peak-Data-Rate-1 AVP . . . . . . . . . . . . . . . . . 6 59 3.1.4. Minimum-Policed-Unit-1 AVP . . . . . . . . . . . . . . 6 60 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2.1. TMOD-Rate-2 AVP . . . . . . . . . . . . . . . . . . . 7 62 3.2.2. TMOD-Size-2 AVP . . . . . . . . . . . . . . . . . . . 7 63 3.2.3. Peak-Data-Rate-2 AVP . . . . . . . . . . . . . . . . . 7 64 3.2.4. Minimum-Policed-Unit-2 AVP . . . . . . . . . . . . . . 7 65 3.3. Path-Latency AVP . . . . . . . . . . . . . . . . . . . . . 7 66 3.4. Path-Jitter AVP . . . . . . . . . . . . . . . . . . . . . 8 67 3.4.1. Path-Jitter-STAT1 AVP . . . . . . . . . . . . . . . . 8 68 3.4.2. Path-Jitter-STAT2 AVP . . . . . . . . . . . . . . . . 8 69 3.4.3. Path-Jitter-STAT3 AVP . . . . . . . . . . . . . . . . 8 70 3.4.4. Path-Jitter-STAT4 AVP . . . . . . . . . . . . . . . . 8 71 3.5. Path-PLR AVP . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.6. Path-PER AVP . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.7. Slack-Term AVP . . . . . . . . . . . . . . . . . . . . . . 9 74 3.8. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.8.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 9 76 3.8.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 9 77 3.9. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 9 78 3.10. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.10.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 10 80 3.10.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 10 81 3.11. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 10 82 3.11.1. Excess-Treatment-Value AVP . . . . . . . . . . . . . . 11 83 3.11.2. Remark-Value AVP . . . . . . . . . . . . . . . . . . . 11 84 3.11.3. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . 12 85 3.11.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . 13 86 3.11.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . 13 87 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 5.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 15 90 5.2. AVP Allocations . . . . . . . . . . . . . . . . . . . . . 16 91 5.3. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 16 92 5.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 16 93 5.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . . . 16 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 101 Intellectual Property and Copyright Statements . . . . . . . . . . 20 103 1. Introduction 105 This document defines a number of Quality of Service (QoS) parameters 106 that can be reused for conveying QoS information within RADIUS and 107 Diameter. 109 The subsequent section give an overview of the parameters defined by 110 this document. 112 1.1. Traffic Model Parameter 114 The Traffic Model (TMOD) parameter is a container consisting of four 115 sub-parameters: 116 o rate (r) 117 o bucket size (b) 118 o peak rate (p) 119 o minimum policed unit (m) 121 The TMOD parameter is a mathematically complete way to describe the 122 traffic source. If, for example, TMOD is set to specify bandwidth 123 only, then set r = peak rate = p, b = large, m = large. As another 124 example if TMOD is set for TCP traffic, then set r = average rate, b 125 = large, p = large. 127 1.2. Constraints Parameters 129 , , , and are QoS 130 parameters describing the desired path latency, path jitter and path 131 bit error rate respectively. 133 The parameter refers to the accumulated latency of the 134 packet forwarding process associated with each QoS aware node along 135 the path, where the latency is defined to be the mean packet delay 136 added by each such node. This delay results from speed-of-light 137 propagation delay, from packet processing limitations, or both. The 138 mean delay reflects the variable queuing delay that may be present. 139 The purpose of this parameter is to provide a minimum path latency 140 for use with services which provide estimates or bounds on additional 141 path delay [RFC2212]. 143 The parameter refers to the accumulated jitter of the 144 packet forwarding process associated with each QoS aware node along 145 the path, where the jitter is defined to be the nominal jitter added 146 by each such node. IP packet jitter, or delay variation, is defined 147 in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and 148 where the selection function includes the packet with minimum delay 149 such that the distribution is equivalent to 2-point delay variation 150 in [Y.1540]. The suggested evaluation interval is 1 minute. This 151 jitter results from packet processing limitations, and includes any 152 variable queuing delay which may be present. The purpose of this 153 parameter is to provide a nominal path jitter for use with services 154 that provide estimates or bounds on additional path delay [RFC2212]. 156 The procedures for collecting path jitter information are outside the 157 scope of this document. 159 The parameter refers to the accumulated packet loss rate 160 (PLR) of the packet forwarding process associated with each QoS aware 161 node along the path where the PLR is defined to be the PLR added by 162 each such node. 164 The parameter refers to the accumulated packet error rate 165 (PER) of the packet forwarding process associated with each QoS aware 166 node, where the PER is defined to be the PER added by each such node. 168 The parameter refers to the difference between desired 169 delay and delay obtained by using bandwidth reservation, and which is 170 used to reduce the resource reservation for a flow [RFC2212]. 172 The parameter refers to the priority of the new 173 flow compared with the of previously admitted 174 flows. Once a flow is admitted, the preemption priority becomes 175 irrelevant. The parameter is used to compare 176 with the preemption priority of new flows. For any specific flow, 177 its preemption priority MUST always be less than or equal to the 178 defending priority. and provide 179 an essential way to differentiate flows for emergency services, ETS, 180 E911, etc., and assign them a higher admission priority than normal 181 priority flows and best-effort priority flows. 183 1.3. Traffic Handling Directives 185 The 210 { TMOD-Rate-1 } 211 { TMOD-Size-1 } 212 { Peak-Data-Rate-1 } 213 { Minimum-Policed-Unit-1 } 215 3.1.1. TMOD-Rate-1 AVP 217 The TMOD-Rate-1 AVP (AVP Code TBD) is of type Float32 and contains 218 the rate (r). 220 3.1.2. TMOD-Size-1 AVP 222 The TMOD-Size-1 AVP (AVP Code TBD) is of type Float32 and contains 223 the bucket size (b). 225 3.1.3. Peak-Data-Rate-1 AVP 227 The Peak-Data-Rate-1 AVP (AVP Code TBD) is of type Float32 and 228 contains the peak rate (p). 230 3.1.4. Minimum-Policed-Unit-1 AVP 232 The Minimum-Policed-Unit-1 AVP (AVP Code TBD) is of type Unsigned32 233 and contains the minimum policed unit (m). 235 The values r, b, and p are represented as IEEE floating point values 236 and the sign bit MUST be zero (all values MUST be non-negative). 237 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 238 than 162 (i.e., positive 35) are discouraged, except for specifying a 239 peak rate of infinity. Infinity is represented with an exponent of 240 all ones (255) and a sign bit and mantissa of all zeroes. 242 3.2. TMOD-2 AVP 244 A description of the semantic of the parameter values can be found in 245 [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The 246 coding for the TMOD-2 AVP is as follows: 248 TMOD-2 ::= < AVP Header: TBD > 249 { TMOD-Rate-2 } 250 { TMOD-Size-2 } 251 { Peak-Data-Rate-2 } 252 { Minimum-Policed-Unit-2 } 254 3.2.1. TMOD-Rate-2 AVP 256 The TMOD-Rate-2 AVP (AVP Code TBD) is of type Float32 and contains 257 the rate (r). 259 3.2.2. TMOD-Size-2 AVP 261 The TMOD-Size-2 AVP (AVP Code TBD) is of type Float32 and contains 262 the bucket size (b). 264 3.2.3. Peak-Data-Rate-2 AVP 266 The Peak-Data-Rate-2 AVP (AVP Code TBD) is of type Float32 and 267 contains the peak rate (p). 269 3.2.4. Minimum-Policed-Unit-2 AVP 271 The Minimum-Policed-Unit-2 AVP (AVP Code TBD) is of type Unsigned32 272 and contains the minimum policed unit (m). 274 The values r, b, and p are represented as IEEE floating point values 275 and the sign bit MUST be zero (all values MUST be non-negative). 277 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 278 than 162 (i.e., positive 35) are discouraged, except for specifying a 279 peak rate of infinity. Infinity is represented with an exponent of 280 all ones (255) and a sign bit and mantissa of all zeroes. 282 3.3. Path-Latency AVP 284 The semantic of the parameter values can be found in [RFC2210] and 285 [RFC2215]. The Path-Latency AVP (AVP Code TBD) is of type Integer32. 287 The composition rule for the path latency is summation with a clamp 288 of (2**32 - 1) on the maximum value. The latencies are average 289 values reported in units of one microsecond. A system with 290 resolution less than one microsecond MUST set unused digits to zero. 291 The total latency added across all QoS aware nodes along the path can 292 range as high as (2**32)-2. 294 3.4. Path-Jitter AVP 296 The coding for the Path-Jitter AVP is as follows: 298 Path-Jitter ::= < AVP Header: TBD > 299 { Path-Jitter-STAT1 } 300 { Path-Jitter-STAT2 } 301 { Path-Jitter-STAT3 } 302 { Path-Jitter-STAT4 } 304 3.4.1. Path-Jitter-STAT1 AVP 306 The Path-Jitter-STAT1 AVP (AVP Code TBD) is of type Integer32 and 307 contains the variance. 309 3.4.2. Path-Jitter-STAT2 AVP 311 The Path-Jitter-STAT2 AVP (AVP Code TBD) is of type Integer32 and 312 contains the 99.9%-ile. 314 3.4.3. Path-Jitter-STAT3 AVP 316 The Path-Jitter-STAT3 AVP (AVP Code TBD) is of type Integer32 and 317 contains the minimum latency. 319 3.4.4. Path-Jitter-STAT4 AVP 321 The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Integer32 and is 322 reserved for future use. 324 The Path-Jitter AVP is the combination of four statistics describing 325 the jitter distribution with a clamp of (2**32 - 1) on the maximum of 326 each value. The jitter STATs are reported in units of one 327 microsecond. 329 3.5. Path-PLR AVP 331 The Path-PLR AVP (AVP Code TBD) is of type Float32 and contains the 332 path packet loss ratio. The PLRs are reported in units of 10^-11. A 333 system with resolution less than one microsecond MUST set unused 334 digits to zero. The total PLR added across all QoS aware nodes can 335 range as high as 10^-1. 337 3.6. Path-PER AVP 339 The Path-PER AVP (AVP Code TBD) is of type Float32 and contains the 340 path packet error ratio. The PERs are reported in units of 10^-11. 341 A system with resolution less than one microsecond MUST set unused 342 digits to zero. The total PER added across all QoS aware nodes can 343 range as high as 10^-1. 345 3.7. Slack-Term AVP 347 The Slack-Term AVP (AVP Code TBD) is of type Integer32 and its 348 semantic can be found in [RFC2212] and [RFC2215]. The Slack-Term AVP 349 contains values measured in microseconds and its value can range from 350 0 to (2**32)-1 microseconds. 352 3.8. Priority AVP 354 The Priority AVP is a grouped AVP consisting of two AVPs, the 355 Preemption-Priority and the Defending-Priority AVP. A description of 356 the semantic can be found in [RFC3181]. 358 Priority ::= < AVP Header: TBD > 359 { Preemption-Priority } 360 { Defending-Priority } 362 3.8.1. Preemption-Priority AVP 364 The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and 365 it indicates the priority of the new flow compared with the defending 366 priority of previously admitted flows. Higher values represent 367 higher priority. 369 3.8.2. Defending-Priority AVP 371 The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. 372 Once a flow is admitted, the preemption priority becomes irrelevant. 373 Instead, its defending priority is used to compare with the 374 preemption priority of new flows. 376 3.9. Admission-Priority AVP 378 The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. 380 The admission control priority of the flow, in terms of access to 381 network bandwidth in order to provide higher probability of call 382 completion to selected flows. Higher values represent higher 383 priority. A given admission priority is encoded in this information 384 element using the same value as when encoded in the Admission- 385 Priority AVP defined in Section 6.2.9 of [I-D.ietf-nsis-qspec], or in 386 the Admission Priority parameter defined in Section 3.1 of 387 [I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value 388 inside the Admission-Priority AVP, inside the [I-D.ietf-nsis-qspec] 389 admission priority parameter or inside the 390 [I-D.ietf-tsvwg-emergency-rsvp] admission priority parameter, refers 391 to the same admission priority. 393 3.10. ALRP AVP 395 The Application-Level Resource Priority (ALRP) AVP is a grouped AVP 396 consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. 398 A description of the semantic of the parameter values can be found in 399 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 400 parameter is as follows: 402 ALRP ::= < AVP Header: TBD > 403 { ALRP-Namespace } 404 { ALRP-Priority } 406 3.10.1. ALRP-Namespace AVP 408 The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 410 3.10.2. ALRP-Priority AVP 412 The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Unsigned32. 414 [RFC4412] defines a resource priority header and established the 415 initial registry; that registry was later extended by 416 [I-D.ietf-tsvwg-emergency-rsvp]. 418 3.11. Excess-Treatment AVP 420 The Excess-Treatment AVP is a grouped AVP consisting of two AVPs, the 421 Treatment and the Remark-Value AVP. 423 The coding for the Excess-Treatment AVP is as follows: 425 Excess-Treatment ::= < AVP Header: TBD > 426 { Excess-Treatment-Value } 427 [ Remark-Value ] 429 3.11.1. Excess-Treatment-Value AVP 431 The Excess-Treatment-Value AVP (AVP Code TBD) is of type Enumerated 432 and indicates how a QoS aware node should process out-of-profile 433 traffic. The following values are currently defined: 435 0: drop 436 1: shape 437 2: remark 438 3: no metering or policing is permitted 440 The default treatment in case that none is specified is that there 441 are no guarantees to excess traffic, i.e., a QoS aware node can do 442 what it finds suitable. 444 When the treatment is set to 'drop', all marked traffic MUST be 445 dropped by a QoS aware node. 447 When the treatment is set to 'shape', it is expected that QoS 448 parameters conveyed as part of QoS-Desired are used to reshape the 449 traffic (for example a TMOD parameter indicated as QoS desired). 450 When the shaping causes unbounded queue growth at the shaper traffic 451 can be dropped. 453 When the treatment is set to 'remark', the excess treatment parameter 454 MUST carry the remark value. For example, packets may be remarked to 455 drop remarked to pertain to a particular QoS class. In the latter 456 case, remarking relates to a DiffServ-type model, where packets 457 arrive marked as belonging to a certain QoS class, and when they are 458 identified as excess, they should then be remarked to a different QoS 459 Class. The Remark-Value AVP carries the information used for re- 460 marking. 462 If 'no metering or policing is permitted' is indicated, the QoS aware 463 node should accept the treatment set by the sender with special care 464 so that excess traffic should not cause a problem. To request the 465 Null Meter [RFC3290] is especially strong, and should be used with 466 caution. 468 3.11.2. Remark-Value AVP 470 The Remark-Value AVP (AVP Code TBD) is of type Unsigned32 and 471 contains the DSCP value the excess traffic should be remarked to. 473 3.11.3. PHB-Class AVP 475 The PHB-Class AVP (AVP Code TBD) is of type OctetString and is two 476 octets long. A description of the semantic of the parameter values 477 can be found in [RFC3140]. The coding for the values is as follows: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 483 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 485 As prescribed in [RFC3140], the encoding for a single PHB is the 486 recommended DSCP value for that PHB, left-justified in the 16 bit 487 field, with bits 6 through 15 set to zero. 489 The encoding for a set of PHBs is the numerically smallest of the set 490 of encodings for the various PHBs in the set, with bit 14 set to 1. 491 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 492 bit 14 set to 1.) 494 0 1 495 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | DSCP |0 0 0 0 0 0 0 0 X 0| 498 +---+---+---+---+---+---+---+---+ 500 PHBs not defined by standards action, i.e., experimental or local use 501 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 502 identification code, assigned by the IANA, is placed left-justified 503 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 504 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 506 0 1 507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | PHD ID CODE |0 0 X 0| 510 +---+---+---+---+---+---+---+---+ 512 Bits 12 and 13 are reserved either for expansion of the PHB 513 identification code, or for other use, at some point in the future. 515 In both cases, when a single PHBID is used to identify a set of PHBs 516 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 517 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 518 intra-microflow traffic reordering when different PHBs from the set 519 are applied to traffic in the same microflow). The set of AF1x PHBs 520 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 521 do not constitute a PHB Scheduling Class can be identified by using 522 more than one PHBID. 524 The registries needed to use [RFC3140] already exist. Hence, no new 525 registry needs to be created for this purpose. 527 3.11.4. DSTE-Class-Type AVP 529 The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A 530 description of the semantic of the parameter values can be found in 531 [RFC4124]. 533 Currently, the values of alues currently allowed are 0, 1, 2, 3, 4, 534 5, 6, 7. 536 3.11.5. Y.1541-QoS-Class AVP 538 The Y.1541-QoS-Class AVP (AVP Code TBD) is of type Unsigned32. A 539 description of the semantic of the parameter values can be found in 540 [Y.1541]. 542 Currently, the allowed values of the Y.1541 QoS class are 0, 1, 2, 3, 543 4, 5, 6, 7. 545 Class 0: 547 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 548 10^-3. Real-time, highly interactive applications, sensitive to 549 jitter. Application examples include VoIP, Video Teleconference. 551 Class 1: 553 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 554 10^-3. Real-time, interactive applications, sensitive to jitter. 555 Application examples include VoIP, Video Teleconference. 557 Class 2: 559 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 560 10^-3. Highly interactive transaction data. Application examples 561 include signaling. 563 Class 3: 565 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 566 10^-3. Interactive transaction data. Application examples 567 include signaling. 569 Class 4: 571 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 572 10^-3. Low Loss Only applications. Application examples include 573 short transactions, bulk data, video streaming. 575 Class 5: 577 Mean delay unspecified, delay variation unspecified, loss ratio 578 unspecified. Unspecified applications. Application examples 579 include traditional applications of default IP networks. 581 Class 6: 583 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 584 10^-5. Applications that are highly sensitive to loss, such as 585 television transport, high-capacity TCP transfers, and TDM circuit 586 emulation. 588 Class 7: 590 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 591 10^-5. Applications that are highly sensitive to loss, such as 592 television transport, high-capacity TCP transfers, and TDM circuit 593 emulation. 595 4. Extensibility 597 This document is designed with extensibility in mind given that 598 different organizations and groups are used to define their own 599 Quality of Service parameters. This document provides an initial QoS 600 profile with common set of QoS parameters. Ideally, these parameters 601 should be used whenever possible but there are cases where additional 602 parameters might be needed, or where the parameters specified in this 603 document are used with a different semantic. In this case it is 604 advisable to define a new QoS profile that may consist of new 605 parameters in addition to parameters defined in this document or an 606 entirely different set of parameters. 608 To enable the definition of new QoS profiles a 8 octet registry is 609 defined field that is represented by a 4-octet vendor and 4-octet 610 specifier field. A QoS profile groups together a bunch of QoS 611 parameters for usage in a specific environment. The vendor field 612 indicates the type as either standards-specified or vendor-specific. 613 If the four octets of the vendor field are 0x00000000, then the value 614 is standards-specified and the registry is maintained by IANA, and 615 any other value represents a vendor-specific Object Identifier (OID). 616 IANA created registry is split into two value ranges; one range uses 617 the "Standards Action" and the second range uses "Specification 618 Required" allocation policy. The latter range is meant to be used by 619 organizations outside the IETF. 621 5. IANA Considerations 623 This section defines the registries and initial codepoint 624 assignments, in accordance with BCP 26 RFC 2434 [RFC5226]. It also 625 defines the procedural requirements to be followed by IANA in 626 allocating new codepoints. 628 IANA is requested to create the following registries listed in the 629 subsections below. 631 5.1. QoS Profile 633 The QoS Profile refers to a 64 bit long field that is represented by 634 a 4-octet vendor and 4-octet specifier field. The vendor field 635 indicates the type as either standards-specified or vendor-specific. 636 If the four octets of the vendor field are 0x00000000, then the value 637 is standards-specified and the registry is maintained by IANA, and 638 any other value represents a vendor-specific Object Identifier (OID). 640 The specifier field indicates the actual QoS profile. The vendor 641 field 0x00000000 is reserved to indicate that the values in the 642 specifier field are maintained by IANA. This document requests IANA 643 to create such a registry and to allocate the value zero (0) for the 644 QoS profile defined in this document. 646 For any other vendor field, the specifier field is maintained by the 647 vendor. 649 For the IANA maintained QoS profiles the following allocation policy 650 is defined: 651 1 to 511: Standards Action 652 512 to 4095: Specification Required 654 Standards action is required to depreciate, delete, or modify 655 existing QoS profile values in the range of 0-511 and a specification 656 is required to depreciate, delete, or modify existing QoS profile 657 values in the range of 512-4095. 659 5.2. AVP Allocations 661 This specification assigns the values TBD1 to TBD2 from the AVP Code 662 namespace defined in [RFC3588]. See Section 3 for the assignment of 663 the namespace in this specification. 665 5.3. Excess-Treatment AVP 667 The following values are allocated by this specification: 668 Excess Treatment Value 0: drop 669 Excess Treatment Value 1: shape 670 Excess Treatment Value 2: remark 671 Excess Treatment Value 3: no metering or policing is permitted 672 Excess Treatment Values 4-63: Standards Action 673 Excess Treatment Value 64-2^32-1: Reserved 675 5.4. DSTE-Class-Type AVP 677 The following values are allocated by this specification: 678 DSTE Class Type Value 0: DSTE Class Type 0 679 DSTE Class Type Value 1: DSTE Class Type 1 680 DSTE Class Type Value 2: DSTE Class Type 2 681 DSTE Class Type Value 3: DSTE Class Type 3 682 DSTE Class Type Value 4: DSTE Class Type 4 683 DSTE Class Type Value 5: DSTE Class Type 5 684 DSTE Class Type Value 6: DSTE Class Type 6 685 DSTE Class Type Value 7: DSTE Class Type 7 686 DSTE Class Type Values 8-63: Standards Action 687 DSTE Class Type Values 64-2^32-1: Reserved 689 5.5. Y.1541-QoS-Class AVP 691 The following values are allocated by this specification: 692 Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 693 Y.1541 QoS Class Value 1: Y.1541 QoS Class 1 694 Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 695 Y.1541 QoS Class Value 3: Y.1541 QoS Class 3 696 Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 697 Y.1541 QoS Class Value 5: Y.1541 QoS Class 5 698 Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 699 Y.1541 QoS Class Value 7: Y.1541 QoS Class 7 700 Y.1541 QoS Class Values 8-63: Standards Action 701 Y.1541 QoS Class Values 64-2^32-1: Reserved 703 The values in the ALRP-Namespace and ALRP-Priority AV{ inside the 704 ALRP AVP take their values from the registry created by [RFC4412] and 705 extended with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions 706 are required by IANA by this specification. 708 6. Security Considerations 710 This document does not raise any security concerns as it only defines 711 QoS parameters. 713 7. Acknowledgements 715 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 716 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 717 NSIS working group chairs (John Loughney and Martin Stiemerling) and 718 the former Transport Area Directors (Allison Mankin, Jon Peterson) 719 for their help. 721 We would like to thank Francois Le Faucheur, John Loughney, Martin 722 Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars 723 Eggert, and Magnus Westerlund for their help with resolving problems 724 regarding the Admission Priority and the ALRP parameter. 726 8. References 728 8.1. Normative References 730 [I-D.ietf-tsvwg-emergency-rsvp] 731 Faucheur, F., Polk, J., and K. Carlberg, "Resource 732 ReSerVation Protovol (RSVP) Extensions for Emergency 733 Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in 734 progress), May 2008. 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, March 1997. 739 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 740 Services", RFC 2210, September 1997. 742 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 743 of Guaranteed Quality of Service", RFC 2212, 744 September 1997. 746 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 747 Parameters for Integrated Service Network Elements", 748 RFC 2215, September 1997. 750 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 751 "Definition of the Differentiated Services Field (DS 752 Field) in the IPv4 and IPv6 Headers", RFC 2474, 753 December 1998. 755 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 756 "Assured Forwarding PHB Group", RFC 2597, June 1999. 758 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 759 "Per Hop Behavior Identification Codes", RFC 3140, 760 June 2001. 762 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 763 RFC 3181, October 2001. 765 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 766 Metric for IP Performance Metrics (IPPM)", RFC 3393, 767 November 2002. 769 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 770 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 772 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 773 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 774 June 2005. 776 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 777 Priority for the Session Initiation Protocol (SIP)", 778 RFC 4412, February 2006. 780 [Y.1541] "Network Performance Objectives for IP-Based Services", , 781 2006. 783 [Y.1571] "Admission Control Priority Levels in Next Generation 784 Networks", , July 2006. 786 8.2. Informative References 788 [I-D.ietf-nsis-qspec] 789 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 790 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 791 progress), April 2008. 793 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 794 and W. Weiss, "An Architecture for Differentiated 795 Services", RFC 2475, December 1998. 797 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 798 Informal Management Model for Diffserv Routers", RFC 3290, 799 May 2002. 801 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 802 Differentiated Services-aware MPLS Traffic Engineering", 803 RFC 3564, July 2003. 805 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 806 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 807 May 2008. 809 [Y.1540] "Internet Protocol Data Communication Service - IP Packet 810 Transfer and Availability Performance Parameters", , 811 December 2002. 813 Authors' Addresses 815 Jouni Korhonen (editor) 816 TeliaSonera 817 Teollisuuskatu 13 818 Sonera FIN-00051 819 Finland 821 Email: jouni.korhonen@teliasonera.com 823 Hannes Tschofenig 824 Nokia Siemens Networks 825 Linnoitustie 6 826 Espoo 02600 827 Finland 829 Phone: +358 (50) 4871445 830 Email: Hannes.Tschofenig@gmx.net 831 URI: http://www.tschofenig.priv.at 833 Full Copyright Statement 835 Copyright (C) The IETF Trust (2008). 837 This document is subject to the rights, licenses and restrictions 838 contained in BCP 78, and except as set forth therein, the authors 839 retain all their rights. 841 This document and the information contained herein are provided on an 842 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 843 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 844 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 845 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 846 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 849 Intellectual Property 851 The IETF takes no position regarding the validity or scope of any 852 Intellectual Property Rights or other rights that might be claimed to 853 pertain to the implementation or use of the technology described in 854 this document or the extent to which any license under such rights 855 might or might not be available; nor does it represent that it has 856 made any independent effort to identify any such rights. Information 857 on the procedures with respect to rights in RFC documents can be 858 found in BCP 78 and BCP 79. 860 Copies of IPR disclosures made to the IETF Secretariat and any 861 assurances of licenses to be made available, or the result of an 862 attempt made to obtain a general license or permission for the use of 863 such proprietary rights by implementers or users of this 864 specification can be obtained from the IETF on-line IPR repository at 865 http://www.ietf.org/ipr. 867 The IETF invites any interested party to bring to its attention any 868 copyrights, patents or patent applications, or other proprietary 869 rights that may cover technology that may be required to implement 870 this standard. Please address the information to the IETF at 871 ietf-ipr@ietf.org.