idnits 2.17.1 draft-ietf-dime-qos-parameters-01.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 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 931. 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 (September 29, 2007) is 6051 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) == Missing Reference: 'S' is mentioned on line 372, but not defined == Missing Reference: '3GPP-1' is mentioned on line 492, but not defined == Missing Reference: '3GPP-2' is mentioned on line 492, but not defined == Missing Reference: '3GPP-3' is mentioned on line 492, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 3290 ** Downref: Normative reference to an Informational RFC: RFC 3564 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-17 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: April 1, 2008 September 29, 2007 8 Quality of Service Parameters for Usage with the AAA Framework 9 draft-ietf-dime-qos-parameters-01.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 April 1, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines a number of Quality of Service (QoS) parameters 43 that can be reused for conveying QoS information within RADIUS and 44 Diameter. 46 The payloads used to carry these QoS parameters are opaque for the 47 AAA client and the AAA server itself and interpreted by the 48 respective Resource Management Function. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 54 3. Parameter Overview . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 3 56 3.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 3 57 3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 58 3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 59 4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 63 4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 64 4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 65 4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 66 4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 67 4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9 68 4.9. Preemption Priority amp; Defending Priority Parameters . . 9 69 4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10 70 4.11. RPH Priority Parameter . . . . . . . . . . . . . . . . . . 10 71 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 12 72 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 13 73 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 14 74 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14 75 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 17 78 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 85 Intellectual Property and Copyright Statements . . . . . . . . . . 21 87 1. Introduction 89 This document defines a number of Quality of Service (QoS) parameters 90 that can be reused for conveying QoS information within RADIUS and 91 Diameter. 93 The payloads used to carry these QoS parameters are opaque for the 94 AAA client and the AAA server itself and interpreted by the 95 respective Resource Management Function. 97 2. Terminology and Abbreviations 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119 [RFC2119]. 103 3. Parameter Overview 105 3.1. Traffic Model Parameter 107 The Traffic Model (TMOD) parameter is a container consisting of four 108 sub-parameters: 109 o rate (r) 110 o bucket size (b) 111 o peak rate (p) 112 o minimum policed unit (m) 114 All four sub-parameters MUST be included in the TMOD parameter. The 115 TMOD parameter is a mathematically complete way to describe the 116 traffic source. If, for example, TMOD is set to specify bandwidth 117 only, then set r = peak rate = p, b = large, m = large. As another 118 example if TMOD is set for TCP traffic, then set r = average rate, b 119 = large, p = large. 121 3.2. Constraints Parameters 123 , , , and are QoS 124 parameters describing the desired path latency, path jitter and path 125 bit error rate respectively. 127 The parameter refers to the accumulated latency of the 128 packet forwarding process associated with each QoS aware node along 129 the path, where the latency is defined to be the mean packet delay 130 added by each such node. This delay results from speed-of-light 131 propagation delay, from packet processing limitations, or both. The 132 mean delay reflects the variable queuing delay that may be present. 134 The purpose of this parameter is to provide a minimum path latency 135 for use with services which provide estimates or bounds on additional 136 path delay [RFC2212]. 138 The procedures for collecting path latency information are outside 139 the scope of this document. 141 The parameter refers to the accumulated jitter of the 142 packet forwarding process associated with each QoS aware node along 143 the path, where the jitter is defined to be the nominal jitter added 144 by each such node. IP packet jitter, or delay variation, is defined 145 in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and 146 where the selection function includes the packet with minimum delay 147 such that the distribution is equivalent to 2-point delay variation 148 in [Y.1540]. The suggested evaluation interval is 1 minute. This 149 jitter results from packet processing limitations, and includes any 150 variable queuing delay which may be present. The purpose of this 151 parameter is to provide a nominal path jitter for use with services 152 that provide estimates or bounds on additional path delay [RFC2212]. 154 The procedures for collecting path jitter information are outside the 155 scope of this document. 157 The parameter refers to the accumulated packet loss rate 158 (PLR) of the packet forwarding process associated with each QoS aware 159 node along the path where the PLR is defined to be the PLR added by 160 each such node. 162 The parameter refers to the accumulated packet error rate 163 (PER) of the packet forwarding process associated with each QoS aware 164 node, where the PER is defined to be the PER added by each such node. 166 The parameter refers to the difference between desired 167 delay and delay obtained by using bandwidth reservation, and which is 168 used to reduce the resource reservation for a flow [RFC2212]. 170 The parameter refers to the priority of the new 171 flow compared with the of previously admitted 172 flows. Once a flow is admitted, the preemption priority becomes 173 irrelevant. The parameter is used to compare 174 with the preemption priority of new flows. For any specific flow, 175 its preemption priority MUST always be less than or equal to the 176 defending priority. and provide 177 an essential way to differentiate flows for emergency services, ETS, 178 E911, etc., and assign them a higher admission priority than normal 179 priority flows and best-effort priority flows. 181 3.3. Traffic Handling Directives 183 The parameter describes how a QoS aware node will 184 process excess traffic, that is, out-of-profile traffic. Excess 185 traffic MAY be dropped, shaped and/or remarked. 187 3.4. Traffic Classifiers 189 Resource reservations might refer to a packet processing with a 190 particular DiffServ per-hop behavior (PHB) [RFC2475] or to a 191 particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS 192 traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 194 4. Parameter Encoding 196 4.1. Parameter Header 198 Each QoS parameter is encoded in TLV format. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |M|r|r|r| Parameter ID |r|r|r|r| Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 M Flag: When set indicates the subsequent parameter MUST be 207 interpreted. If the M flag is set and the parameter is not 208 understood then it leads to an error. If the M flag is not 209 set and then not understood then it can be ignored. 211 The r bits are reserved. 213 Parameter ID: Assigned to each individual QoS parameter 215 4.2. TMOD-1 Parameter 217 =

[RFC2210] , [RFC2215] 219 The above notation means that the 4 sub-parameters must be 220 carried in the parameter. The coding for the 221 parameter is as follows: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 |M|r|r|r| 1 |r|r|r|r| 4 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 The parameters are represented by three floating point numbers 238 in single-precision IEEE floating point format followed by one 32-bit 239 integer in network byte order. The first floating point value is the 240 rate (r), the second floating point value is the bucket size (b), the 241 third floating point is the peak rate (p), and the first unsigned 242 integer is the minimum policed unit (m). 244 When r, b, and p terms are represented as IEEE floating point values, 245 the sign bit MUST be zero (all values MUST be non-negative). 246 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 247 than 162 (i.e., positive 35) are discouraged, except for specifying a 248 peak rate of infinity. Infinity is represented with an exponent of 249 all ones (255) and a sign bit and mantissa of all zeroes. 251 4.3. TMOD-2 Parameter 253 A description of the semantic of the parameter values can be found in 254 [RFC2215]. The parameter may be needed in a DiffServ 255 environment. The coding for the parameter is as follows: 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 |M|r|r|r| 2 |r|r|r|r| 4 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 When r, b, and p terms are represented as IEEE floating point values, 272 the sign bit MUST be zero (all values MUST be non-negative). 274 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 275 than 162 (i.e., positive 35) are discouraged, except for specifying a 276 peak rate of infinity. Infinity is represented with an exponent of 277 all ones (255) and a sign bit and mantissa of all zeroes. 279 4.4. Path Latency Parameter 281 A description of the semantic of the parameter values can be found in 282 [RFC2210],[RFC2215]. The coding for the parameter is 283 as follows: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |M|r|r|r| 3 |r|r|r|r| 1 | 289 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 290 | Path Latency (32-bit integer) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The Path Latency is a single 32-bit integer in network byte order. 294 The composition rule for the parameter is summation 295 with a clamp of (2**32 - 1) on the maximum value. The latencies are 296 average values reported in units of one microsecond. A system with 297 resolution less than one microsecond MUST set unused digits to zero. 298 The total latency added across all QoS aware nodes along the path can 299 range as high as (2**32)-2. 301 4.5. Path Jitter Parameter 303 The coding for the parameter is as follows: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |M|r|r|r| 4 |r|r|r|r| 4 | 309 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 310 | Path Jitter STAT1(variance) (32-bit integer) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Path Jitter STAT4(Reserved) (32-bit integer) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 The Path Jitter is a set of four 32-bit integers in network byte 320 order. The Path Jitter parameter is the combination of four 321 statistics describing the Jitter distribution with a clamp of (2**32 322 - 1) on the maximum of each value. The jitter STATs are reported in 323 units of one microsecond. 325 4.6. Path PLR Parameter 327 The coding for the parameter is as follows: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |M|r|r|r| 5 |r|r|r|r| 1 | 333 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 334 | Path Packet Loss Ratio (32-bit floating point) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 The Path PLR is a single 32-bit single precision IEEE floating point 338 number in network byte order. The PLRs are reported in units of 339 10^-11. A system with resolution less than one microsecond MUST set 340 unused digits to zero. The total PLR added across all QoS aware 341 nodes can range as high as 10^-1. 343 4.7. Path PER Parameter 345 The coding for the parameter is as follows: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |M|r|r|r| 6 |r|r|r|r| 1 | 351 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 352 | Path Packet Error Ratio (32-bit floating point) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 The Path PER is a single 32-bit single precision IEEE floating point 356 number in network byte order. The PERs are reported in units of 357 10^-11. A system with resolution less than one microsecond MUST set 358 unused digits to zero. The total PER added across all QoS aware 359 nodes can range as high as 10^-1. 361 4.8. Slack Term Parameter 363 A description of the semantic of the parameter values can be found in 364 [RFC2212], [RFC2215]. The coding for the parameter is as 365 follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |M|r|r|r| 7 |r|r|r|r| 1 | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Slack Term [S] (32-bit integer) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 The Slack Term parameter S is nonnegative and is measured in 376 microseconds. S is represented as a 32-bit integer. Its value can 377 range from 0 to (2**32)-1 microseconds. 379 4.9. Preemption Priority amp; Defending Priority Parameters 381 A description of the semantic of the parameter values can be found in 382 [RFC3181]. 384 The coding for the & sub- 385 parameters is as follows: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |M|r|r|r| 8 |r|r|r|r| 1 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Preemption Priority | Defending Priority | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Preemption Priority: The priority of the new flow compared with the 396 defending priority of previously admitted flows. Higher values 397 represent higher priority. 399 Defending Priority: Once a flow is admitted, the preemption priority 400 becomes irrelevant. Instead, its defending priority is used to 401 compare with the preemption priority of new flows. 403 As specified in [RFC3181], & are 16-bit integer values. 406 4.10. Admission Priority Parameter 408 A description of the semantic of the parameter values can be found in 409 [Y.1571]. The coding for the parameter is as 410 follows: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |M|r|r|r| 9 |r|r|r|r| 1 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Admis.Priority| (Reserved) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 High priority flows, normal priority flows, and best-effort priority 421 flows can have access to resources depending on their admission 422 priority value as follows: 424 Admission Priority: 426 0 - best-effort priority flow 427 1 - normal priority flow 428 2 - high priority flow 429 255 - not used 431 A reservation without an parameter (i.e., set to 432 255) MUST be treated as a reservation with an = 433 1. 435 4.11. RPH Priority Parameter 437 A description of the semantic of the parameter values can be found in 438 [RFC4412]. The coding for the parameter is as 439 follows: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |M|r|r|r| 10 |r|r|r|r| 1 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | RPH Namespace | RPH Priority | (Reserved) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 [RFC4412] defines a resource priority header (RPH) with parameters 450 "RPH Namespace" and "RPH Priority" combination, and if populated is 451 applicable only to flows with high admission priority, as follows: 453 RPH Namespace: 455 0 - dsn 456 1 - drsn 457 2 - q735 458 3 - ets 459 4 - wps 460 255 - not used 462 Each namespace has a finite list of relative priority-values. Each 463 is listed here in the order of lowest priority to highest priority. 465 RPH Priority: 467 4 - q735.4 468 3 - q735.3 469 2 - q735.2 470 1 - q735.1 471 0 - q735.0 473 4 - ets.4 474 3 - ets.3 475 2 - ets.2 476 1 - ets.1 477 0 - ets.0 479 4 - wps.4 480 3 - wps.3 481 2 - wps.2 482 1 - wps.1 483 0 - wps.0 485 For the 4 priority parameters, the following cases are permissible 486 (procedures specified in references): 488 1 parameter: [Y.1571] 489 2 parameters: , [RFC4412] 490 2 parameters: , [RFC3181] 491 3 parameters: , , 492 [3GPP-1, 3GPP-2, 3GPP-3] 493 4 parameters: , , 494 , [3GPP-1, 3GPP-2, 495 3GPP-3] 497 It is permissible to have without , but not permissible to have without 499 (alternatively is ignored in 500 instances without ). 502 4.12. Excess Treatment Parameter 504 The coding for the parameter is as follows: 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |M|r|r|r| 11 |r|r|r|r| 1 | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Excess Trtmnt | Remark Value | Reserved | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Excess Treatment: Indicates how the QoS aware node should process 515 out-of-profile traffic, that is, traffic not covered by the 516 parameter. Allowed values are as follows: 518 0: drop 519 1: shape 520 2: remark 521 3: no metering or policing is permitted 523 The default excess treatment in case that none is specified is that 524 there are no guarantees to excess traffic, i.e., a QoS aware node can 525 do what it finds suitable. 527 When excess treatment is set to 'drop', all marked traffic MUST be 528 dropped by a QoS aware node. 530 When excess treatment is set to 'shape', it is expected that the QoS 531 Desired object carries a TMOD parameter. Excess traffic is to be 532 shaped to this TMOD. When the shaping causes unbounded queue growth 533 at the shaper traffic can be dropped. 535 When excess treatment is set to 'remark', the excess treatment 536 parameter MUST carry the remark value. For example, packets may be 537 remarked to drop remarked to pertain to a particular QoS class. In 538 the latter case, remarking relates to a DiffServ-type model, where 539 packets arrive marked as belonging to a certain QoS class, and when 540 they are identified as excess, they should then be remarked to a 541 different QoS Class. 543 If 'no metering or policing is permitted' is signaled, the QoS aware 544 node should accept the excess treatment parameter set by the sender 545 with special care so that excess traffic should not cause a problem. 546 To request the Null Meter [RFC3290] is especially strong, and should 547 be used with caution. 549 4.13. PHB Class Parameter 551 A description of the semantic of the parameter values can be found in 552 [RFC3140]. The coding for the parameter is as follows: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |M|r|r|r| 12 |r|r|r|r| 1 | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 560 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 562 As prescribed in [RFC3140], the encoding for a single PHB is the 563 recommended DSCP value for that PHB, left-justified in the 16 bit 564 field, with bits 6 through 15 set to zero. 566 The encoding for a set of PHBs is the numerically smallest of the set 567 of encodings for the various PHBs in the set, with bit 14 set to 1. 568 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 569 bit 14 set to 1.) 571 0 1 572 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | DSCP |0 0 0 0 0 0 0 0 X 0| 575 +---+---+---+---+---+---+---+---+ 577 PHBs not defined by standards action, i.e., experimental or local use 578 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 579 identification code, assigned by the IANA, is placed left-justified 580 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 581 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 583 0 1 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | PHD ID CODE |0 0 X 0| 587 +---+---+---+---+---+---+---+---+ 589 Bits 12 and 13 are reserved either for expansion of the PHB 590 identification code, or for other use, at some point in the future. 592 In both cases, when a single PHBID is used to identify a set of PHBs 593 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 594 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 595 intra-microflow traffic reordering when different PHBs from the set 596 are applied to traffic in the same microflow). The set of AF1x PHBs 597 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 598 do not constitute a PHB Scheduling Class can be identified by using 599 more than one PHBID. 601 The registries needed to use [RFC3140] already exist. Hence, no new 602 registry needs to be created for this purpose. 604 4.14. DSTE Class Type Parameter 606 A description of the semantic of the parameter values can be found in 607 [RFC4124]. The coding for the parameter is as 608 follows: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |M|r|r|r| 13 |r|r|r|r| 1 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |DSTE Cls. Type | (Reserved) | 616 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 618 DSTE Class Type: Indicates the DSTE class type. Values currently 619 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 620 that the parameter is not used. 622 4.15. Y.1541 QoS Class Parameter 624 A description of the semantic of the parameter values can be found in 625 [Y.1541]. The coding for the parameter is as 626 follows: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 |M|r|r|r| 14 |r|r|r|r| 1 | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 |Y.1541 QoS Cls.| (Reserved) | 634 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 636 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 637 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 638 that the parameter is not used. 640 Class 0: 642 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 643 10^-3. Real-time, highly interactive applications, sensitive to 644 jitter. Application examples include VoIP, Video Teleconference. 646 Class 1: 648 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 649 10^-3. Real-time, interactive applications, sensitive to jitter. 650 Application examples include VoIP, Video Teleconference. 652 Class 2: 654 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 655 10^-3. Highly interactive transaction data. Application examples 656 include signaling. 658 Class 3: 660 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 661 10^-3. Interactive transaction data. Application examples 662 include signaling. 664 Class 4: 666 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 667 10^-3. Low Loss Only applications. Application examples include 668 short transactions, bulk data, video streaming. 670 Class 5: 672 Mean delay unspecified, delay variation unspecified, loss ratio 673 unspecified. Unspecified applications. Application examples 674 include traditional applications of default IP networks. 676 Class 6: 678 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 679 10^-5. Applications that are highly sensitive to loss, such as 680 television transport, high-capacity TCP transfers, and TDM circuit 681 emulation. 683 Class 7: 685 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 686 10^-5. Applications that are highly sensitive to loss, such as 687 television transport, high-capacity TCP transfers, and TDM circuit 688 emulation. 690 5. Extensibility 692 This document is designed with extensibility in mind given that 693 different organizations and groups are used to define their own 694 Quality of Service parameters. This document provides an initial QoS 695 profile with common set of parameters. Ideally, these parameters 696 should be used whenever possible but there are cases where additional 697 parameters might be needed, or where the parameters specified in this 698 document are used with a different semantic. In this case it is 699 advisable to define a new QoS profile that may consist of new 700 parameters in addition to parameters defined in this document or an 701 entirely different set of parameters. 703 To enable the definition of new QoS profiles a 8 octet registry is 704 defined field that is represented by a 4-octet vendor and 4-octet 705 specifier field. The vendor field indicates the type as either 706 standards-specified or vendor-specific. If the four octets of the 707 vendor field are 0x00000000, then the value is standards-specified 708 and the registry is maintained by IANA, and any other value 709 represents a vendor-specific Object Identifier (OID). IANA created 710 registry is split into two value ranges; one range uses the 711 "Standards Action" and the second range uses "Specification Required" 712 allocation policy. The latter range is meant to be used by 713 organizations outside the IETF. 715 6. IANA Considerations 717 This document reuses the namespace created in [I-D.ietf-nsis-qspec] 718 for 719 1. Admission Priority Parameter 720 2. RPH Namespace Parameter 721 3. RPH Priority Parameter 722 4. Excess Treatment Parameter 723 5. DSTE Class Type Parameter 724 6. Y.1541 QoS Class Parameter 726 IANA is requested to create the following registries: QoS Profile (32 727 bits), and Parameter ID (12 bits) 729 6.1. QoS Profile 731 The QoS Profile refers to a 64 bit long field that is represented by 732 a 4-octet vendor and 4-octet specifier field. The vendor field 733 indicates the type as either standards-specified or vendor-specific. 734 If the four octets of the vendor field are 0x00000000, then the value 735 is standards-specified and the registry is maintained by IANA, and 736 any other value represents a vendor-specific Object Identifier (OID). 738 The specifier field indicates the actual QoS profile. The vendor 739 field 0x00000000 is reserved to indicate that the values in the 740 specifier field are maintained by IANA. This document requests IANA 741 to create such a registry and to allocate the value zero (0) for the 742 QoS profile defined in this document. 744 For any other vendor field, the specifier field is maintained by the 745 vendor. 747 For the IANA maintained QoS profiles the following allocation policy 748 is defined: 750 1 to 511: Standards Action 752 512 to 4095: Specification Required 754 Standards action is required to depreciate, delete, or modify 755 existing QoS profile values in the range of 0-511 and a specification 756 is required to depreciate, delete, or modify existing QoS profile 757 values in the range of 512-4095. 759 6.2. Parameter ID 761 The Parameter ID refers to a 12 bit long field. 763 The following values are allocated by this specification. 765 (0): 766 (1): 767 (2): 768 (3): 769 (4): 770 (5): 771 (6): 772 (7): & 773 (8): 774 (9): 775 (10): 776 (11): 777 (12): 778 (13): 780 The allocation policies for further values are as follows: 782 14-127: Standards Action 784 128-255: Private/Experimental Use 786 255-4095: Specification Required 788 A standards track document is required to depreciate, delete, or 789 modify existing Parameter IDs. 791 7. Security Considerations 793 This document does not raise any security concerns as it only defines 794 QoS parameters. 796 8. Acknowledgements 798 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 799 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 800 NSIS working group chairs (John Loughney and Martin Stiemerling) and 801 the former Transport Area Directors (Allison Manking, Jon Peterson) 802 for their help. 804 9. References 806 9.1. Normative References 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 812 Services", RFC 2210, September 1997. 814 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 815 of Guaranteed Quality of Service", RFC 2212, 816 September 1997. 818 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 819 Parameters for Integrated Service Network Elements", 820 RFC 2215, September 1997. 822 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 823 "Definition of the Differentiated Services Field (DS 824 Field) in the IPv4 and IPv6 Headers", RFC 2474, 825 December 1998. 827 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 828 and W. Weiss, "An Architecture for Differentiated 829 Services", RFC 2475, December 1998. 831 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 832 "Assured Forwarding PHB Group", RFC 2597, June 1999. 834 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 835 "Per Hop Behavior Identification Codes", RFC 3140, 836 June 2001. 838 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 839 RFC 3181, October 2001. 841 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 842 Informal Management Model for Diffserv Routers", RFC 3290, 843 May 2002. 845 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 846 Metric for IP Performance Metrics (IPPM)", RFC 3393, 847 November 2002. 849 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 850 Differentiated Services-aware MPLS Traffic Engineering", 851 RFC 3564, July 2003. 853 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 854 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 855 June 2005. 857 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 858 Priority for the Session Initiation Protocol (SIP)", 859 RFC 4412, February 2006. 861 [Y.1541] "Network Performance Objectives for IP-Based Services", , 862 2006. 864 9.2. Informative References 866 [I-D.ietf-nsis-qspec] 867 Ash, J., "QoS NSLP QSPEC Template", 868 draft-ietf-nsis-qspec-17 (work in progress), July 2007. 870 [Y.1540] "Internet Protocol Data Communication Service - IP Packet 871 Transfer and Availability Performance Parameters", , 872 December 2002. 874 Authors' Addresses 876 Jouni Korhonen (editor) 877 TeliaSonera 878 Teollisuuskatu 13 879 Sonera FIN-00051 880 Finland 882 Email: jouni.korhonen@teliasonera.com 884 Hannes Tschofenig 885 Nokia Siemens Networks 886 Otto-Hahn-Ring 6 887 Munich, Bavaria 81739 888 Germany 890 Email: Hannes.Tschofenig@nsn.com 891 URI: http://www.tschofenig.com 893 Full Copyright Statement 895 Copyright (C) The IETF Trust (2007). 897 This document is subject to the rights, licenses and restrictions 898 contained in BCP 78, and except as set forth therein, the authors 899 retain all their rights. 901 This document and the information contained herein are provided on an 902 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 903 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 904 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 905 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 906 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 907 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 909 Intellectual Property 911 The IETF takes no position regarding the validity or scope of any 912 Intellectual Property Rights or other rights that might be claimed to 913 pertain to the implementation or use of the technology described in 914 this document or the extent to which any license under such rights 915 might or might not be available; nor does it represent that it has 916 made any independent effort to identify any such rights. Information 917 on the procedures with respect to rights in RFC documents can be 918 found in BCP 78 and BCP 79. 920 Copies of IPR disclosures made to the IETF Secretariat and any 921 assurances of licenses to be made available, or the result of an 922 attempt made to obtain a general license or permission for the use of 923 such proprietary rights by implementers or users of this 924 specification can be obtained from the IETF on-line IPR repository at 925 http://www.ietf.org/ipr. 927 The IETF invites any interested party to bring to its attention any 928 copyrights, patents or patent applications, or other proprietary 929 rights that may cover technology that may be required to implement 930 this standard. Please address the information to the IETF at 931 ietf-ipr@ietf.org. 933 Acknowledgment 935 Funding for the RFC Editor function is provided by the IETF 936 Administrative Support Activity (IASA).