idnits 2.17.1 draft-ietf-dime-qos-parameters-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 826. 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 (June 9, 2007) is 6138 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 369, but not defined == Missing Reference: '3GPP-1' is mentioned on line 489, but not defined == Missing Reference: '3GPP-2' is mentioned on line 489, but not defined == Missing Reference: '3GPP-3' is mentioned on line 489, 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-16 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: December 11, 2007 June 9, 2007 8 Quality of Service Parameters for Usage with the AAA Framework 9 draft-ietf-dime-qos-parameters-00.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 December 11, 2007. 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. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . . . 19 84 1. Introduction 86 This document defines a number of Quality of Service (QoS) parameters 87 that can be reused for conveying QoS information within RADIUS and 88 Diameter. 90 The payloads used to carry these QoS parameters are opaque for the 91 AAA client and the AAA server itself and interpreted by the 92 respective Resource Management Function. 94 2. Terminology and Abbreviations 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC2119 [RFC2119]. 100 3. Parameter Overview 102 3.1. Traffic Model Parameter 104 The Traffic Model (TMOD) parameter is a container consisting of four 105 sub-parameters: 106 o rate (r) 107 o bucket size (b) 108 o peak rate (p) 109 o minimum policed unit (m) 111 All four sub-parameters MUST be included in the TMOD parameter. The 112 TMOD parameter is a mathematically complete way to describe the 113 traffic source. If, for example, TMOD is set to specify bandwidth 114 only, then set r = peak rate = p, b = large, m = large. As another 115 example if TMOD is set for TCP traffic, then set r = average rate, b 116 = large, p = large. 118 3.2. Constraints Parameters 120 , , , and are QoS 121 parameters describing the desired path latency, path jitter and path 122 bit error rate respectively. 124 The parameter refers to the accumulated latency of the 125 packet forwarding process associated with each QoS aware node along 126 the path, where the latency is defined to be the mean packet delay 127 added by each such node. This delay results from speed-of-light 128 propagation delay, from packet processing limitations, or both. The 129 mean delay reflects the variable queuing delay that may be present. 131 The purpose of this parameter is to provide a minimum path latency 132 for use with services which provide estimates or bounds on additional 133 path delay [RFC2212]. 135 The procedures for collecting path latency information are outside 136 the scope of this document. 138 The parameter refers to the accumulated jitter of the 139 packet forwarding process associated with each QoS aware node along 140 the path, where the jitter is defined to be the nominal jitter added 141 by each such node. IP packet jitter, or delay variation, is defined 142 in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and 143 where the selection function includes the packet with minimum delay 144 such that the distribution is equivalent to 2-point delay variation 145 in [Y.1540]. The suggested evaluation interval is 1 minute. This 146 jitter results from packet processing limitations, and includes any 147 variable queuing delay which may be present. The purpose of this 148 parameter is to provide a nominal path jitter for use with services 149 that provide estimates or bounds on additional path delay [RFC2212]. 151 The procedures for collecting path jitter information are outside the 152 scope of this document. 154 The parameter refers to the accumulated packet loss rate 155 (PLR) of the packet forwarding process associated with each QoS aware 156 node along the path where the PLR is defined to be the PLR added by 157 each such node. 159 The parameter refers to the accumulated packet error rate 160 (PER) of the packet forwarding process associated with each QoS aware 161 node, where the PER is defined to be the PER added by each such node. 163 The parameter refers to the difference between desired 164 delay and delay obtained by using bandwidth reservation, and which is 165 used to reduce the resource reservation for a flow [RFC2212]. 167 The parameter refers to the priority of the new 168 flow compared with the of previously admitted 169 flows. Once a flow is admitted, the preemption priority becomes 170 irrelevant. The parameter is used to compare 171 with the preemption priority of new flows. For any specific flow, 172 its preemption priority MUST always be less than or equal to the 173 defending priority. and provide 174 an essential way to differentiate flows for emergency services, ETS, 175 E911, etc., and assign them a higher admission priority than normal 176 priority flows and best-effort priority flows. 178 3.3. Traffic Handling Directives 180 The parameter describes how a QoS aware node will 181 process excess traffic, that is, out-of-profile traffic. Excess 182 traffic MAY be dropped, shaped and/or remarked. 184 3.4. Traffic Classifiers 186 Resource reservations might refer to a packet processing with a 187 particular DiffServ per-hop behavior (PHB) [RFC2475] or to a 188 particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS 189 traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 191 4. Parameter Encoding 193 4.1. Header 195 Each QoS parameter is encoded in TLV format using a similar parameter 196 header: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |M|r|r|r| Parameter ID |r|r|r|r| Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 M Flag: When set indicates the subsequent parameter MUST be 205 interpreted. Otherwise the parameter can be ignored if not 206 understood. 208 The r bits are reserved. 210 Parameter ID: Assigned to each parameter (see below) 212 4.2. TMOD-1 Parameter 214 =

[RFC2210] , [RFC2215] 216 The above notation means that the 4 sub-parameters must be 217 carried in the parameter. The coding for the 218 parameter is as follows: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |M|r|r|r| 1 |r|r|r|r| 4 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 The parameters are represented by three floating point numbers 235 in single-precision IEEE floating point format followed by one 32-bit 236 integer in network byte order. The first floating point value is the 237 rate (r), the second floating point value is the bucket size (b), the 238 third floating point is the peak rate (p), and the first unsigned 239 integer is the minimum policed unit (m). 241 When r, b, and p terms are represented as IEEE floating point values, 242 the sign bit MUST be zero (all values MUST be non-negative). 243 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 244 than 162 (i.e., positive 35) are discouraged, except for specifying a 245 peak rate of infinity. Infinity is represented with an exponent of 246 all ones (255) and a sign bit and mantissa of all zeroes. 248 4.3. TMOD-2 Parameter 250 A description of the semantic of the parameter values can be found in 251 [RFC2215]. The parameter may be needed in a DiffServ 252 environment. The coding for the parameter is as follows: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |M|r|r|r| 2 |r|r|r|r| 4 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 When r, b, and p terms are represented as IEEE floating point values, 269 the sign bit MUST be zero (all values MUST be non-negative). 271 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 272 than 162 (i.e., positive 35) are discouraged, except for specifying a 273 peak rate of infinity. Infinity is represented with an exponent of 274 all ones (255) and a sign bit and mantissa of all zeroes. 276 4.4. Path Latency Parameter 278 A description of the semantic of the parameter values can be found in 279 [RFC2210],[RFC2215]. The coding for the parameter is 280 as follows: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |M|r|r|r| 3 |r|r|r|r| 1 | 286 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 287 | Path Latency (32-bit integer) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 The Path Latency is a single 32-bit integer in network byte order. 291 The composition rule for the parameter is summation 292 with a clamp of (2**32 - 1) on the maximum value. The latencies are 293 average values reported in units of one microsecond. A system with 294 resolution less than one microsecond MUST set unused digits to zero. 295 The total latency added across all QoS aware nodes along the path can 296 range as high as (2**32)-2. 298 4.5. Path Jitter Parameter 300 The coding for the parameter is as follows: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |M|r|r|r| 4 |r|r|r|r| 4 | 306 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 307 | Path Jitter STAT1(variance) (32-bit integer) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Path Jitter STAT4(Reserved) (32-bit integer) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 The Path Jitter is a set of four 32-bit integers in network byte 317 order. The Path Jitter parameter is the combination of four 318 statistics describing the Jitter distribution with a clamp of (2**32 319 - 1) on the maximum of each value. The jitter STATs are reported in 320 units of one microsecond. 322 4.6. Path PLR Parameter 324 The coding for the parameter is as follows: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |M|r|r|r| 5 |r|r|r|r| 1 | 330 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 331 | Path Packet Loss Ratio (32-bit floating point) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 The Path PLR is a single 32-bit single precision IEEE floating point 335 number in network byte order. The PLRs are reported in units of 336 10^-11. A system with resolution less than one microsecond MUST set 337 unused digits to zero. The total PLR added across all QoS aware 338 nodes can range as high as 10^-1. 340 4.7. Path PER Parameter 342 The coding for the parameter is as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |M|r|r|r| 6 |r|r|r|r| 1 | 348 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 349 | Path Packet Error Ratio (32-bit floating point) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 The Path PER is a single 32-bit single precision IEEE floating point 353 number in network byte order. The PERs are reported in units of 354 10^-11. A system with resolution less than one microsecond MUST set 355 unused digits to zero. The total PER added across all QoS aware 356 nodes can range as high as 10^-1. 358 4.8. Slack Term> Parameter 360 A description of the semantic of the parameter values can be found in 361 [RFC2212], [RFC2215]. The coding for the parameter is as 362 follows: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |M|r|r|r| 7 |r|r|r|r| 1 | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Slack Term [S] (32-bit integer) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 The Slack Term parameter S is nonnegative and is measured in 373 microseconds. S is represented as a 32-bit integer. Its value can 374 range from 0 to (2**32)-1 microseconds. 376 4.9. Preemption Priority amp; Defending Priority Parameters 378 A description of the semantic of the parameter values can be found in 379 [RFC3181]. 381 The coding for the & sub- 382 parameters is as follows: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 |M|r|r|r| 8 |r|r|r|r| 1 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Preemption Priority | Defending Priority | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Preemption Priority: The priority of the new flow compared with the 393 defending priority of previously admitted flows. Higher values 394 represent higher priority. 396 Defending Priority: Once a flow is admitted, the preemption priority 397 becomes irrelevant. Instead, its defending priority is used to 398 compare with the preemption priority of new flows. 400 As specified in [RFC3181], & are 16-bit integer values. 403 4.10. Admission Priority Parameter 405 A description of the semantic of the parameter values can be found in 406 [Y.1571]. The coding for the parameter is as 407 follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |M|r|r|r| 9 |r|r|r|r| 1 | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Admis.Priority| (Reserved) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 High priority flows, normal priority flows, and best-effort priority 418 flows can have access to resources depending on their admission 419 priority value as follows: 421 Admission Priority: 423 0 - best-effort priority flow 424 1 - normal priority flow 425 2 - high priority flow 426 255 - not used 428 A reservation without an parameter (i.e., set to 429 255) MUST be treated as a reservation with an = 430 1. 432 4.11. RPH Priority Parameter 434 A description of the semantic of the parameter values can be found in 435 [RFC4412]. The coding for the parameter is as 436 follows: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |M|r|r|r| 10 |r|r|r|r| 1 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | RPH Namespace | RPH Priority | (Reserved) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 [RFC4412] defines a resource priority header (RPH) with parameters 447 "RPH Namespace" and "RPH Priority" combination, and if populated is 448 applicable only to flows with high admission priority, as follows: 450 RPH Namespace: 452 0 - dsn 453 1 - drsn 454 2 - q735 455 3 - ets 456 4 - wps 457 255 - not used 459 Each namespace has a finite list of relative priority-values. Each 460 is listed here in the order of lowest priority to highest priority. 462 RPH Priority: 464 4 - q735.4 465 3 - q735.3 466 2 - q735.2 467 1 - q735.1 468 0 - q735.0 470 4 - ets.4 471 3 - ets.3 472 2 - ets.2 473 1 - ets.1 474 0 - ets.0 476 4 - wps.4 477 3 - wps.3 478 2 - wps.2 479 1 - wps.1 480 0 - wps.0 482 For the 4 priority parameters, the following cases are permissible 483 (procedures specified in references): 485 1 parameter: [Y.1571] 486 2 parameters: , [RFC4412] 487 2 parameters: , [RFC3181] 488 3 parameters: , , 489 [3GPP-1, 3GPP-2, 3GPP-3] 490 4 parameters: , , 491 , [3GPP-1, 3GPP-2, 492 3GPP-3] 494 It is permissible to have without , but not permissible to have without 496 (alternatively is ignored in 497 instances without ). 499 4.12. Excess Treatment Parameter 501 The coding for the parameter is as follows: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |M|r|r|r| 11 |r|r|r|r| 1 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Excess Trtmnt | Remark Value | Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Excess Treatment: Indicates how the QoS aware node should process 512 out-of-profile traffic, that is, traffic not covered by the 513 parameter. Allowed values are as follows: 515 0: drop 516 1: shape 517 2: remark 518 3: no metering or policing is permitted 520 The default excess treatment in case that none is specified is that 521 there are no guarantees to excess traffic, i.e., a QoS aware node can 522 do what it finds suitable. 524 When excess treatment is set to 'drop', all marked traffic MUST be 525 dropped by a QoS aware node. 527 When excess treatment is set to 'shape', it is expected that the QoS 528 Desired object carries a TMOD parameter. Excess traffic is to be 529 shaped to this TMOD. When the shaping causes unbounded queue growth 530 at the shaper traffic can be dropped. 532 When excess treatment is set to 'remark', the excess treatment 533 parameter MUST carry the remark value. For example, packets may be 534 remarked to drop remarked to pertain to a particular QoS class. In 535 the latter case, remarking relates to a DiffServ-type model, where 536 packets arrive marked as belonging to a certain QoS class, and when 537 they are identified as excess, they should then be remarked to a 538 different QoS Class. 540 If 'no metering or policing is permitted' is signaled, the QoS aware 541 node should accept the excess treatment parameter set by the sender 542 with special care so that excess traffic should not cause a problem. 543 To request the Null Meter [RFC3290] is especially strong, and should 544 be used with caution. 546 4.13. PHB Class Parameter 548 A description of the semantic of the parameter values can be found in 549 [RFC3140]. The coding for the parameter is as follows: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |M|r|r|r| 12 |r|r|r|r| 1 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 557 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 559 As prescribed in [RFC3140], the encoding for a single PHB is the 560 recommended DSCP value for that PHB, left-justified in the 16 bit 561 field, with bits 6 through 15 set to zero. 563 The encoding for a set of PHBs is the numerically smallest of the set 564 of encodings for the various PHBs in the set, with bit 14 set to 1. 565 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 566 bit 14 set to 1.) 568 0 1 569 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | DSCP |0 0 0 0 0 0 0 0 X 0| 572 +---+---+---+---+---+---+---+---+ 574 PHBs not defined by standards action, i.e., experimental or local use 575 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 576 identification code, assigned by the IANA, is placed left-justified 577 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 578 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 580 0 1 581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | PHD ID CODE |0 0 X 0| 584 +---+---+---+---+---+---+---+---+ 586 Bits 12 and 13 are reserved either for expansion of the PHB 587 identification code, or for other use, at some point in the future. 589 In both cases, when a single PHBID is used to identify a set of PHBs 590 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 591 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 592 intra-microflow traffic reordering when different PHBs from the set 593 are applied to traffic in the same microflow). The set of AF1x PHBs 594 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 595 do not constitute a PHB Scheduling Class can be identified by using 596 more than one PHBID. 598 The registries needed to use [RFC3140] already exist. Hence, no new 599 registry needs to be created for this purpose. 601 4.14. DSTE Class Type Parameter 603 A description of the semantic of the parameter values can be found in 604 [RFC4124]. The coding for the parameter is as 605 follows: 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 |M|r|r|r| 13 |r|r|r|r| 1 | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |DSTE Cls. Type | (Reserved) | 613 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 615 DSTE Class Type: Indicates the DSTE class type. Values currently 616 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 617 that the parameter is not used. 619 4.15. Y.1541 QoS Class Parameter 621 A description of the semantic of the parameter values can be found in 622 [Y.1541]. The coding for the parameter is as 623 follows: 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |M|r|r|r| 14 |r|r|r|r| 1 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 |Y.1541 QoS Cls.| (Reserved) | 631 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 633 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 634 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 635 that the parameter is not used. 637 Class 0: 639 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 640 10^-3. Real-time, highly interactive applications, sensitive to 641 jitter. Application examples include VoIP, Video Teleconference. 642 Class 1: 644 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 645 10^-3. Real-time, interactive applications, sensitive to jitter. 646 Application examples include VoIP, Video Teleconference. 647 Class 2: 649 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 650 10^-3. Highly interactive transaction data. Application examples 651 include signaling. 652 Class 3: 654 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 655 10^-3. Interactive transaction data. Application examples 656 include signaling. 657 Class 4: 659 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 660 10^-3. Low Loss Only applications. Application examples include 661 short transactions, bulk data, video streaming. 662 Class 5: 664 Mean delay unspecified, delay variation unspecified, loss ratio 665 unspecified. Unspecified applications. Application examples 666 include traditional applications of default IP networks. 667 Class 6: 669 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 670 10^-5. Applications that are highly sensitive to loss, such as 671 television transport, high-capacity TCP transfers, and TDM circuit 672 emulation. 673 Class 7: 675 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 676 10^-5. Applications that are highly sensitive to loss, such as 677 television transport, high-capacity TCP transfers, and TDM circuit 678 emulation. 680 5. IANA Considerations 682 This document reuses the namespace created in [I-D.ietf-nsis-qspec]. 684 No actions are required by IANA. 686 6. Security Considerations 688 This document does not raise any security concerns as it only defines 689 QoS parameters. 691 7. Acknowledgements 693 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 694 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 695 NSIS working group chairs (John Loughney and Martin Stiemerling) and 696 the former Transport Area Directors (Allison Manking, Jon Peterson) 697 for their help. 699 8. References 701 8.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 707 Services", RFC 2210, September 1997. 709 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 710 of Guaranteed Quality of Service", RFC 2212, 711 September 1997. 713 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 714 Parameters for Integrated Service Network Elements", 715 RFC 2215, September 1997. 717 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 718 "Definition of the Differentiated Services Field (DS 719 Field) in the IPv4 and IPv6 Headers", RFC 2474, 720 December 1998. 722 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 723 and W. Weiss, "An Architecture for Differentiated 724 Services", RFC 2475, December 1998. 726 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 727 "Assured Forwarding PHB Group", RFC 2597, June 1999. 729 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 730 "Per Hop Behavior Identification Codes", RFC 3140, 731 June 2001. 733 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 734 RFC 3181, October 2001. 736 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 737 Informal Management Model for Diffserv Routers", RFC 3290, 738 May 2002. 740 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 741 Metric for IP Performance Metrics (IPPM)", RFC 3393, 742 November 2002. 744 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 745 Differentiated Services-aware MPLS Traffic Engineering", 746 RFC 3564, July 2003. 748 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 749 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 750 June 2005. 752 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 753 Priority for the Session Initiation Protocol (SIP)", 754 RFC 4412, February 2006. 756 [Y.1541] "Network Performance Objectives for IP-Based Services", , 757 2006. 759 8.2. Informative References 761 [I-D.ietf-nsis-qspec] 762 Ash, J., "QoS NSLP QSPEC Template", 763 draft-ietf-nsis-qspec-16 (work in progress), March 2007. 765 [Y.1540] "Internet Protocol Data Communication Service - IP Packet 766 Transfer and Availability Performance Parameters", , 767 December 2002. 769 Authors' Addresses 771 Jouni Korhonen (editor) 772 TeliaSonera 773 Teollisuuskatu 13 774 Sonera FIN-00051 775 Finland 777 Email: jouni.korhonen@teliasonera.com 779 Hannes Tschofenig 780 Nokia Siemens Networks 781 Otto-Hahn-Ring 6 782 Munich, Bavaria 81739 783 Germany 785 Email: Hannes.Tschofenig@siemens.com 786 URI: http://www.tschofenig.com 788 Full Copyright Statement 790 Copyright (C) The IETF Trust (2007). 792 This document is subject to the rights, licenses and restrictions 793 contained in BCP 78, and except as set forth therein, the authors 794 retain all their rights. 796 This document and the information contained herein are provided on an 797 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 798 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 799 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 800 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 801 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 802 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 804 Intellectual Property 806 The IETF takes no position regarding the validity or scope of any 807 Intellectual Property Rights or other rights that might be claimed to 808 pertain to the implementation or use of the technology described in 809 this document or the extent to which any license under such rights 810 might or might not be available; nor does it represent that it has 811 made any independent effort to identify any such rights. Information 812 on the procedures with respect to rights in RFC documents can be 813 found in BCP 78 and BCP 79. 815 Copies of IPR disclosures made to the IETF Secretariat and any 816 assurances of licenses to be made available, or the result of an 817 attempt made to obtain a general license or permission for the use of 818 such proprietary rights by implementers or users of this 819 specification can be obtained from the IETF on-line IPR repository at 820 http://www.ietf.org/ipr. 822 The IETF invites any interested party to bring to its attention any 823 copyrights, patents or patent applications, or other proprietary 824 rights that may cover technology that may be required to implement 825 this standard. Please address the information to the IETF at 826 ietf-ipr@ietf.org. 828 Acknowledgment 830 Funding for the RFC Editor function is provided by the IETF 831 Administrative Support Activity (IASA).