idnits 2.17.1 draft-ietf-dime-qos-parameters-07.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 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 890. 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 (November 1, 2008) is 5654 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 371, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-emergency-rsvp-09 == 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: 1 error (**), 0 flaws (~~), 4 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: May 5, 2009 November 1, 2008 8 Quality of Service Parameters for Usage with the AAA Framework 9 draft-ietf-dime-qos-parameters-07.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 May 5, 2009. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 50 3. Parameter Overview . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 3 52 3.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 3 53 3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 54 3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 55 4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 59 4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 60 4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 61 4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 62 4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 63 4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 8 64 4.9. Preemption Priority amp; Defending Priority Parameters . . 9 65 4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 9 66 4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 67 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 68 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 69 4.13.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . 12 70 4.13.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 12 71 4.13.3. Case 3: Experimental or Local Use PHBs . . . . . . . 13 72 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 73 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14 74 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Intellectual Property and Copyright Statements . . . . . . . . . . 20 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 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 path PLR is defined to be the PLR added 160 by 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 path PER is defined to be the PER added by each such 165 node. 167 The parameter refers to the difference between desired 168 delay and delay obtained by using bandwidth reservation, and which is 169 used to reduce the resource reservation for a flow [RFC2212]. 171 The parameter refers to the priority of the new 172 flow compared with the of previously admitted 173 flows. Once a flow is admitted, the preemption priority becomes 174 irrelevant. The parameter is used to compare 175 with the preemption priority of new flows. For any specific flow, 176 its preemption priority MUST always be less than or equal to the 177 defending priority. and provide 178 an essential way to differentiate flows for emergency services, ETS, 179 E911, etc., and assign them a higher admission priority than normal 180 priority flows and best-effort priority flows. 182 3.3. Traffic Handling Directives 184 The parameter describes how a QoS aware node will 185 process excess traffic, that is, out-of-profile traffic. Dopping, 186 shaping or remarking are possible actions. 188 3.4. Traffic Classifiers 190 Resource reservations might refer to a packet processing with a 191 particular DiffServ per-hop behavior (PHB) [RFC2475] or to a 192 particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS 193 traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 195 4. Parameter Encoding 197 4.1. Parameter Header 199 Each QoS parameter is encoded in TLV format. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |M|r|r|r| Parameter ID |r|r|r|r| Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 M Flag: When set indicates the subsequent parameter MUST be 208 interpreted. If the M flag is set and the parameter is not 209 understood then it leads to an error. If the M flag is not 210 set and then not understood then it can be ignored. 212 The r bits are reserved. 214 Parameter ID: Assigned to each individual QoS parameter 216 Length: Indicates the length of the subsequent data in 32-bit words. 218 4.2. TMOD-1 Parameter 220 =

[RFC2210] , [RFC2215] 222 The above notation means that the 4 sub-parameters must be 223 carried in the parameter. The coding for the 224 parameter is as follows: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |M|r|r|r| 1 |r|r|r|r| 4 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 The parameters are represented by three floating point numbers 241 in single-precision IEEE floating point format followed by one 32-bit 242 integer in network byte order. The first floating point value is the 243 rate (r), the second floating point value is the bucket size (b), the 244 third floating point is the peak rate (p), and the first unsigned 245 integer is the minimum policed unit (m). 247 When r, b, and p terms are represented as IEEE floating point values, 248 the sign bit MUST be zero (all values MUST be non-negative). 249 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 250 than 162 (i.e., positive 35) are discouraged, except for specifying a 251 peak rate of infinity. Infinity is represented with an exponent of 252 all ones (255) and a sign bit and mantissa of all zeroes. 254 4.3. TMOD-2 Parameter 256 A description of the semantic of the parameter values can be found in 257 [RFC2215]. The parameter may be needed in a DiffServ 258 environment. The coding for the parameter is as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |M|r|r|r| 2 |r|r|r|r| 4 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 When r, b, and p terms are represented as IEEE floating point values, 275 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 4.4. Path Latency Parameter 284 A description of the semantic of the parameter values can be found in 285 [RFC2210],[RFC2215]. The coding for the parameter is 286 as follows: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |M|r|r|r| 3 |r|r|r|r| 1 | 292 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 293 | Path Latency (32-bit integer) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 The Path Latency is a single 32-bit integer in network byte order. 297 The composition rule for the parameter is summation 298 with a clamp of (2**32 - 1) on the maximum value. The latencies are 299 average values reported in units of one microsecond. A system with 300 resolution less than one microsecond MUST set unused digits to zero. 302 4.5. Path Jitter Parameter 304 The coding for the parameter is as follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |M|r|r|r| 4 |r|r|r|r| 4 | 310 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 311 | Path Jitter STAT1(variance) (32-bit integer) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Path Jitter STAT4(Reserved) (32-bit integer) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 The Path Jitter is a set of four 32-bit integers in network byte 321 order. The Path Jitter parameter is the combination of four 322 statistics describing the Jitter distribution with a clamp of (2**32 323 - 1) on the maximum of each value. The jitter STATs are reported in 324 units of one microsecond. 326 4.6. Path PLR Parameter 328 The coding for the parameter is as follows: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |M|r|r|r| 5 |r|r|r|r| 1 | 334 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 335 | Path Packet Loss Ratio (32-bit floating point) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 The Path PLR is a single 32-bit single precision IEEE floating point 339 number in network byte order. The PLRs are reported in units of 340 10^-11. A system with resolution less than one microsecond MUST set 341 unused digits to zero. 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. 360 4.8. Slack Term Parameter 362 A description of the semantic of the parameter values can be found in 363 [RFC2212], [RFC2215]. The coding for the parameter is 364 as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |M|r|r|r| 7 |r|r|r|r| 1 | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Slack Term [S] (32-bit integer) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 The Slack Term parameter S is a 32-bit integer value in network byte 375 order and is measured in microseconds. S is represented as a 32-bit 376 integer. 378 4.9. Preemption Priority amp; Defending Priority Parameters 380 A description of the semantic of the parameter values can be found in 381 [RFC3181]. 383 The coding for the & sub- 384 parameters is as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |M|r|r|r| 8 |r|r|r|r| 1 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Preemption Priority | Defending Priority | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Preemption Priority: The priority of the new flow compared with the 395 defending priority of previously admitted flows. Higher values 396 represent higher priority. 398 Defending Priority: Once a flow is admitted, the preemption priority 399 becomes irrelevant. Instead, its defending priority is used to 400 compare with the preemption priority of new flows. 402 As specified in [RFC3181], & are 16-bit integer values. They are represented in network 404 byte order. 406 4.10. Admission Priority Parameter 408 The coding for the parameter is as follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |M|r|r|r| 9 |r|r|r|r| 1 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Admis.Priority| (Reserved) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 The 'Admis.Priority' field is a 8 bit unsigned integer in network 419 byte order. 421 The admission control priority of the flow, in terms of access to 422 network bandwidth in order to provide higher probability of call 423 completion to selected flows. Higher values represent higher 424 priority. A given Admission Priority is encoded in this information 425 element using the same value as when encoded in the Admission 426 Priority parameter defined in Section 6.2.9 of [I-D.ietf-nsis-qspec], 427 or in the Admission Priority parameter defined in Section 3.1 of 428 [I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value 429 inside the Admission Priority information element defined in the 430 present document, inside the [I-D.ietf-nsis-qspec] Admission Priority 431 parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp] Admission 432 Priority parameter, refers to the same Admission Priority. 434 4.11. Application-Level Resource Priority (ALRP) Parameter 436 A description of the semantic of the parameter values can be found in 437 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 438 parameter is as follows: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |M|r|r|r| 10 |r|r|r|r| 1 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | ALRP Namespace | (Reserved) | ALRP Priority | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 The ALRP Namespace field is a 16 bits long unsigned integer in 449 network byte order and the ALRP Priority field is an 8 bit long 450 unsigned integer in network byte order containing the specific 451 priority value. 453 [RFC4412] defines a resource priority header and established the 454 initial registry; the encoding of the values in that registry was 455 later extended by [I-D.ietf-tsvwg-emergency-rsvp]. 457 4.12. Excess Treatment Parameter 459 The coding for the parameter is as follows: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |M|r|r|r| 11 |r|r|r|r| 1 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Excess Trtmnt | Remark Value | Reserved | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Excess Treatment (8 bit unsigned integer value in network byte 470 order): Indicates how the QoS aware node should process out-of- 471 profile traffic, that is, traffic not covered by the 472 parameter. Allowed values are as follows: 474 0: drop 475 1: shape 476 2: remark 477 3: no metering or policing is permitted 479 Further values can be registered as described in Section 6.3. 481 The default excess treatment in case that none is specified is that 482 there are no guarantees to excess traffic, i.e., a QoS aware node can 483 do what it finds suitable. 485 When excess treatment is set to 'drop', all marked traffic MUST be 486 dropped by a QoS aware node. 488 When excess treatment is set to 'shape', it is expected that the QoS 489 Desired object carries a TMOD parameter. Excess traffic is to be 490 shaped to this TMOD. When the shaping causes unbounded queue growth 491 at the shaper traffic can be dropped. 493 When excess treatment is set to 'remark', the excess treatment 494 parameter MUST carry the remark value. For example, packets may be 495 remarked to drop remarked to pertain to a particular QoS class. In 496 the latter case, remarking relates to a DiffServ-type model, where 497 packets arrive marked as belonging to a certain QoS class, and when 498 they are identified as excess, they should then be remarked to a 499 different QoS Class. 501 If 'no metering or policing is permitted' is signaled, the QoS aware 502 node should accept the excess treatment parameter set by the sender 503 with special care so that excess traffic should not cause a problem. 504 To request the Null Meter [RFC3290] is especially strong, and should 505 be used with caution. 507 The Remark Value is an 8 bit unsigned integer value in network byte 508 order. 510 4.13. PHB Class Parameter 512 A description of the semantic of the parameter values can be found in 513 [RFC3140]. The registries needed for usage with [RFC3140] already 514 exist and hence no new registry needs to be created by this document. 515 The coding for the parameter is as follows and three 516 different cases need to be differentiated. The header format is 517 shown in the subsequent figure below and is used by all three cases 518 defined in the subsequent sub-sections. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |M|r|r|r| 12 |r|r|r|r| 1 | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 4.13.1. Case 1: Single PHB 528 As prescribed in [RFC3140], the encoding for a single PHB is the 529 recommended DSCP value for that PHB, left-justified in the 16 bit 530 field, with bits 6 through 15 set to zero. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 536 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 538 4.13.2. Case 2: Set of PHBs 540 The encoding for a set of PHBs is the numerically smallest of the set 541 of encodings for the various PHBs in the set, with bit 14 set to 1. 542 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 543 bit 14 set to 1.) 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | 548 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 550 4.13.3. Case 3: Experimental or Local Use PHBs 552 PHBs not defined by standards action, i.e., experimental or local use 553 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 554 identification code, assigned by the IANA, is placed left-justified 555 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 556 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 558 Bits 12 and 13 are reserved either for expansion of the PHB 559 identification code, or for other use, at some point in the future. 561 In both cases, when a single PHBID is used to identify a set of PHBs 562 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 563 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 564 intra-microflow traffic reordering when different PHBs from the set 565 are applied to traffic in the same microflow). The set of AF1x PHBs 566 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 567 do not constitute a PHB Scheduling Class can be identified by using 568 more than one PHBID. 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | PHD ID CODE |0 0 1 0| (Reserved) | 574 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 576 4.14. DSTE Class Type Parameter 578 A description of the semantic of the parameter values can be found in 579 [RFC4124]. The coding for the parameter is as 580 follows: 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 |M|r|r|r| 13 |r|r|r|r| 1 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 |DSTE Cls. Type | (Reserved) | 588 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 590 DSTE Class Type: Indicates the DSTE class type. Values currently 591 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 592 that the parameter is not used. 594 4.15. Y.1541 QoS Class Parameter 596 A description of the semantic of the parameter values can be found in 597 [Y.1541]. The coding for the parameter is as 598 follows: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |M|r|r|r| 14 |r|r|r|r| 1 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |Y.1541 QoS Cls.| (Reserved) | 606 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 608 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 609 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 610 that the parameter is not used. 612 5. Extensibility 614 This document is designed with extensibility in mind given that 615 different organizations and groups are used to define their own 616 Quality of Service parameters. This document provides an initial QoS 617 profile with common set of parameters. Ideally, these parameters 618 should be used whenever possible but there are cases where additional 619 parameters might be needed, or where the parameters specified in this 620 document are used with a different semantic. In this case it is 621 advisable to define a new QoS profile that may consist of new 622 parameters in addition to parameters defined in this document or an 623 entirely different set of parameters. 625 To enable the definition of new QoS profiles a 8 octet registry is 626 defined field that is represented by a 4-octet vendor and 4-octet 627 specifier field. The vendor field indicates the type as either 628 standards-specified or vendor-specific. If the four octets of the 629 vendor field are 0x00000000, then the value is standards-specified 630 and the registry is maintained by IANA as Enterprise Numbers defined 631 in [RFC2578], and any other value represents a vendor-specific Object 632 Identifier (OID). IANA created registry is split into two value 633 ranges; one range uses the "Standards Action" and the second range 634 uses "Specification Required" allocation policy. The latter range is 635 meant to be used by organizations outside the IETF. 637 6. IANA Considerations 639 This section defines the registries and initial codepoint 640 assignments, in accordance with BCP 26 RFC 5226 [RFC5226]. It also 641 defines the procedural requirements to be followed by IANA in 642 allocating new codepoints. 644 IANA is requested to create the following registries listed in the 645 subsections below. 647 6.1. QoS Profile 649 The QoS Profile refers to a 64 bit long field that is represented by 650 a 4-octet vendor and 4-octet specifier field. The vendor field 651 indicates the type as either standards-specified or vendor-specific. 652 If the four octets of the vendor field are 0x00000000, then the value 653 is standards-specified and the registry is maintained by IANA, and 654 any other value represents a vendor-specific Object Identifier (OID). 656 The specifier field indicates the actual QoS profile. The vendor 657 field 0x00000000 is reserved to indicate that the values in the 658 specifier field are maintained by IANA. This document requests IANA 659 to create such a registry and to allocate the value zero (0) for the 660 QoS profile defined in this document. 662 For any other vendor field, the specifier field is maintained by the 663 vendor. 665 For the IANA maintained QoS profiles the following allocation policy 666 is defined: 667 1 to 511: Standards Action 668 512 to 4095: Specification Required 670 Standards action is required to depreciate, delete, or modify 671 existing QoS profile values in the range of 0-511 and a specification 672 is required to depreciate, delete, or modify existing QoS profile 673 values in the range of 512-4095. 675 6.2. Parameter ID 677 The Parameter ID refers to a 12 bit long field. 679 The following values are allocated by this specification. 681 (0): 682 (1): 683 (2): 684 (3): 685 (4): 686 (5): 687 (6): 688 (7): & 689 (8): 690 (9): 691 (10): 692 (11): 693 (12): 694 (13): 696 The allocation policies for further values are as follows: 697 14-127: Standards Action 698 128-255: Private/Experimental Use 699 255-4095: Specification Required 701 A standards track document is required to depreciate, delete, or 702 modify existing Parameter IDs. 704 6.3. Excess Treatment Parameter 706 The Excess Treatment parameter refers to an 8 bit long field. 708 The following values are allocated by this specification: 709 Excess Treatment Value 0: drop 710 Excess Treatment Value 1: shape 711 Excess Treatment Value 2: remark 712 Excess Treatment Value3: no metering or policing is permitted 713 Excess Treatment Values 4-63: Standards Action 714 Excess Treatment Value 64-255: Reserved 716 The 8 bit Remark Value allocation policies are as follows: 717 0-63: Specification Required 718 64-127: Private/Experimental Use 719 128-255: Reserved 721 The ALRP Namespace and ALRP Priority field inside the ALRP Parameter 722 take their values from the registry created by [RFC4412] and extended 723 with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are 724 required by IANA by this specification. 726 7. Security Considerations 728 This document does not raise any security concerns as it only defines 729 QoS parameters. 731 8. Acknowledgements 733 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 734 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 735 NSIS working group chairs (John Loughney and Martin Stiemerling) and 736 the former Transport Area Directors (Allison Mankin, Jon Peterson) 737 for their help. 739 We would like to thank Francois Le Faucheur, John Loughney, Martin 740 Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars 741 Eggert, and Magnus Westerlund for their help with resolving problems 742 regarding the Admission Priority and the ALRP parameter. 744 We would like to thank Dan Romascanu for his detailed Area Director 745 review comments. 747 9. References 749 9.1. Normative References 751 [I-D.ietf-tsvwg-emergency-rsvp] 752 Faucheur, F., Polk, J., and K. Carlberg, "Resource 753 ReSerVation Protovol (RSVP) Extensions for Emergency 754 Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in 755 progress), October 2008. 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, March 1997. 760 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 761 Services", RFC 2210, September 1997. 763 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 764 of Guaranteed Quality of Service", RFC 2212, 765 September 1997. 767 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 768 Parameters for Integrated Service Network Elements", 769 RFC 2215, September 1997. 771 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 772 "Definition of the Differentiated Services Field (DS 773 Field) in the IPv4 and IPv6 Headers", RFC 2474, 774 December 1998. 776 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 777 Schoenwaelder, Ed., "Structure of Management Information 778 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 780 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 781 "Assured Forwarding PHB Group", RFC 2597, June 1999. 783 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 784 "Per Hop Behavior Identification Codes", RFC 3140, 785 June 2001. 787 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 788 RFC 3181, October 2001. 790 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 791 Metric for IP Performance Metrics (IPPM)", RFC 3393, 792 November 2002. 794 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 795 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 796 June 2005. 798 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 799 Priority for the Session Initiation Protocol (SIP)", 800 RFC 4412, February 2006. 802 [Y.1541] "ITU-T Recommendation Y.1541, Network Performance 803 Objectives for IP-Based Services", , 2006. 805 9.2. Informative References 807 [I-D.ietf-nsis-qspec] 808 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 809 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 810 progress), April 2008. 812 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 813 and W. Weiss, "An Architecture for Differentiated 814 Services", RFC 2475, December 1998. 816 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 817 Informal Management Model for Diffserv Routers", RFC 3290, 818 May 2002. 820 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 821 Differentiated Services-aware MPLS Traffic Engineering", 822 RFC 3564, July 2003. 824 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 825 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 826 May 2008. 828 [Y.1540] "ITU-T Recommendation Y.1540, Internet Protocol Data 829 Communication Service - IP Packet Transfer and 830 Availability Performance Parameters", , December 2002. 832 Authors' Addresses 834 Jouni Korhonen (editor) 835 TeliaSonera 836 Teollisuuskatu 13 837 Sonera FIN-00051 838 Finland 840 Email: jouni.korhonen@teliasonera.com 842 Hannes Tschofenig 843 Nokia Siemens Networks 844 Linnoitustie 6 845 Espoo 02600 846 Finland 848 Phone: +358 (50) 4871445 849 Email: Hannes.Tschofenig@gmx.net 850 URI: http://www.tschofenig.priv.at 852 Full Copyright Statement 854 Copyright (C) The IETF Trust (2008). 856 This document is subject to the rights, licenses and restrictions 857 contained in BCP 78, and except as set forth therein, the authors 858 retain all their rights. 860 This document and the information contained herein are provided on an 861 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 862 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 863 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 864 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 865 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 866 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 868 Intellectual Property 870 The IETF takes no position regarding the validity or scope of any 871 Intellectual Property Rights or other rights that might be claimed to 872 pertain to the implementation or use of the technology described in 873 this document or the extent to which any license under such rights 874 might or might not be available; nor does it represent that it has 875 made any independent effort to identify any such rights. Information 876 on the procedures with respect to rights in RFC documents can be 877 found in BCP 78 and BCP 79. 879 Copies of IPR disclosures made to the IETF Secretariat and any 880 assurances of licenses to be made available, or the result of an 881 attempt made to obtain a general license or permission for the use of 882 such proprietary rights by implementers or users of this 883 specification can be obtained from the IETF on-line IPR repository at 884 http://www.ietf.org/ipr. 886 The IETF invites any interested party to bring to its attention any 887 copyrights, patents or patent applications, or other proprietary 888 rights that may cover technology that may be required to implement 889 this standard. Please address the information to the IETF at 890 ietf-ipr@ietf.org.