idnits 2.17.1 draft-ietf-dime-qos-parameters-02.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 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 970. 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 (February 25, 2008) is 5902 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 376, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-emergency-rsvp-05 ** 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-18 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 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: August 28, 2008 February 25, 2008 8 Quality of Service Parameters for Usage with the AAA Framework 9 draft-ietf-dime-qos-parameters-02.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 August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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. Application-Level Resource Priority (ALRP) Parameter . . . 10 71 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 72 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 73 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 74 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13 75 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16 79 6.3. Admission Priority Parameter . . . . . . . . . . . . . . . 17 80 6.4. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17 81 6.5. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 18 82 6.6. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Intellectual Property and Copyright Statements . . . . . . . . . . 22 91 1. Introduction 93 This document defines a number of Quality of Service (QoS) parameters 94 that can be reused for conveying QoS information within RADIUS and 95 Diameter. 97 The payloads used to carry these QoS parameters are opaque for the 98 AAA client and the AAA server itself and interpreted by the 99 respective Resource Management Function. 101 2. Terminology and Abbreviations 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC2119 [RFC2119]. 107 3. Parameter Overview 109 3.1. Traffic Model Parameter 111 The Traffic Model (TMOD) parameter is a container consisting of four 112 sub-parameters: 113 o rate (r) 114 o bucket size (b) 115 o peak rate (p) 116 o minimum policed unit (m) 118 All four sub-parameters MUST be included in the TMOD parameter. The 119 TMOD parameter is a mathematically complete way to describe the 120 traffic source. If, for example, TMOD is set to specify bandwidth 121 only, then set r = peak rate = p, b = large, m = large. As another 122 example if TMOD is set for TCP traffic, then set r = average rate, b 123 = large, p = large. 125 3.2. Constraints Parameters 127 , , , and are QoS 128 parameters describing the desired path latency, path jitter and path 129 bit error rate respectively. 131 The parameter refers to the accumulated latency of the 132 packet forwarding process associated with each QoS aware node along 133 the path, where the latency is defined to be the mean packet delay 134 added by each such node. This delay results from speed-of-light 135 propagation delay, from packet processing limitations, or both. The 136 mean delay reflects the variable queuing delay that may be present. 138 The purpose of this parameter is to provide a minimum path latency 139 for use with services which provide estimates or bounds on additional 140 path delay [RFC2212]. 142 The procedures for collecting path latency information are outside 143 the scope of this document. 145 The parameter refers to the accumulated jitter of the 146 packet forwarding process associated with each QoS aware node along 147 the path, where the jitter is defined to be the nominal jitter added 148 by each such node. IP packet jitter, or delay variation, is defined 149 in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and 150 where the selection function includes the packet with minimum delay 151 such that the distribution is equivalent to 2-point delay variation 152 in [Y.1540]. The suggested evaluation interval is 1 minute. This 153 jitter results from packet processing limitations, and includes any 154 variable queuing delay which may be present. The purpose of this 155 parameter is to provide a nominal path jitter for use with services 156 that provide estimates or bounds on additional path delay [RFC2212]. 158 The procedures for collecting path jitter information are outside the 159 scope of this document. 161 The parameter refers to the accumulated packet loss rate 162 (PLR) of the packet forwarding process associated with each QoS aware 163 node along the path where the PLR is defined to be the PLR added by 164 each such node. 166 The parameter refers to the accumulated packet error rate 167 (PER) of the packet forwarding process associated with each QoS aware 168 node, where the PER is defined to be the PER added by each such node. 170 The parameter refers to the difference between desired 171 delay and delay obtained by using bandwidth reservation, and which is 172 used to reduce the resource reservation for a flow [RFC2212]. 174 The parameter refers to the priority of the new 175 flow compared with the of previously admitted 176 flows. Once a flow is admitted, the preemption priority becomes 177 irrelevant. The parameter is used to compare 178 with the preemption priority of new flows. For any specific flow, 179 its preemption priority MUST always be less than or equal to the 180 defending priority. and provide 181 an essential way to differentiate flows for emergency services, ETS, 182 E911, etc., and assign them a higher admission priority than normal 183 priority flows and best-effort priority flows. 185 3.3. Traffic Handling Directives 187 The parameter describes how a QoS aware node will 188 process excess traffic, that is, out-of-profile traffic. Excess 189 traffic MAY be dropped, shaped and/or remarked. 191 3.4. Traffic Classifiers 193 Resource reservations might refer to a packet processing with a 194 particular DiffServ per-hop behavior (PHB) [RFC2475] or to a 195 particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS 196 traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 198 4. Parameter Encoding 200 4.1. Parameter Header 202 Each QoS parameter is encoded in TLV format. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |M|r|r|r| Parameter ID |r|r|r|r| Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 M Flag: When set indicates the subsequent parameter MUST be 211 interpreted. If the M flag is set and the parameter is not 212 understood then it leads to an error. If the M flag is not 213 set and then not understood then it can be ignored. 215 The r bits are reserved. 217 Parameter ID: Assigned to each individual QoS parameter 219 4.2. TMOD-1 Parameter 221 =

[RFC2210] , [RFC2215] 223 The above notation means that the 4 sub-parameters must be 224 carried in the parameter. The coding for the 225 parameter is as follows: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |M|r|r|r| 1 |r|r|r|r| 4 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 The parameters are represented by three floating point numbers 242 in single-precision IEEE floating point format followed by one 32-bit 243 integer in network byte order. The first floating point value is the 244 rate (r), the second floating point value is the bucket size (b), the 245 third floating point is the peak rate (p), and the first unsigned 246 integer is the minimum policed unit (m). 248 When r, b, and p terms are represented as IEEE floating point values, 249 the sign bit MUST be zero (all values MUST be non-negative). 250 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 251 than 162 (i.e., positive 35) are discouraged, except for specifying a 252 peak rate of infinity. Infinity is represented with an exponent of 253 all ones (255) and a sign bit and mantissa of all zeroes. 255 4.3. TMOD-2 Parameter 257 A description of the semantic of the parameter values can be found in 258 [RFC2215]. The parameter may be needed in a DiffServ 259 environment. The coding for the parameter is as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |M|r|r|r| 2 |r|r|r|r| 4 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 When r, b, and p terms are represented as IEEE floating point values, 276 the sign bit MUST be zero (all values MUST be non-negative). 278 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 279 than 162 (i.e., positive 35) are discouraged, except for specifying a 280 peak rate of infinity. Infinity is represented with an exponent of 281 all ones (255) and a sign bit and mantissa of all zeroes. 283 4.4. Path Latency Parameter 285 A description of the semantic of the parameter values can be found in 286 [RFC2210],[RFC2215]. The coding for the parameter is 287 as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |M|r|r|r| 3 |r|r|r|r| 1 | 293 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 294 | Path Latency (32-bit integer) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The Path Latency is a single 32-bit integer in network byte order. 298 The composition rule for the parameter is summation 299 with a clamp of (2**32 - 1) on the maximum value. The latencies are 300 average values reported in units of one microsecond. A system with 301 resolution less than one microsecond MUST set unused digits to zero. 302 The total latency added across all QoS aware nodes along the path can 303 range as high as (2**32)-2. 305 4.5. Path Jitter Parameter 307 The coding for the parameter is as follows: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |M|r|r|r| 4 |r|r|r|r| 4 | 313 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 314 | Path Jitter STAT1(variance) (32-bit integer) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Path Jitter STAT4(Reserved) (32-bit integer) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 The Path Jitter is a set of four 32-bit integers in network byte 324 order. The Path Jitter parameter is the combination of four 325 statistics describing the Jitter distribution with a clamp of (2**32 326 - 1) on the maximum of each value. The jitter STATs are reported in 327 units of one microsecond. 329 4.6. Path PLR Parameter 331 The coding for the parameter is as follows: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |M|r|r|r| 5 |r|r|r|r| 1 | 337 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 338 | Path Packet Loss Ratio (32-bit floating point) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 The Path PLR is a single 32-bit single precision IEEE floating point 342 number in network byte order. The PLRs are reported in units of 343 10^-11. A system with resolution less than one microsecond MUST set 344 unused digits to zero. The total PLR added across all QoS aware 345 nodes can range as high as 10^-1. 347 4.7. Path PER Parameter 349 The coding for the parameter is as follows: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |M|r|r|r| 6 |r|r|r|r| 1 | 355 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 356 | Path Packet Error Ratio (32-bit floating point) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 The Path PER is a single 32-bit single precision IEEE floating point 360 number in network byte order. The PERs are reported in units of 361 10^-11. A system with resolution less than one microsecond MUST set 362 unused digits to zero. The total PER added across all QoS aware 363 nodes can range as high as 10^-1. 365 4.8. Slack Term Parameter 367 A description of the semantic of the parameter values can be found in 368 [RFC2212], [RFC2215]. The coding for the parameter is as 369 follows: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |M|r|r|r| 7 |r|r|r|r| 1 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Slack Term [S] (32-bit integer) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 The Slack Term parameter S is a 32-bit integer value in network byte 380 order and is measured in microseconds. S is represented as a 32-bit 381 integer. Its value can range from 0 to (2**32)-1 microseconds. 383 4.9. Preemption Priority amp; Defending Priority Parameters 385 A description of the semantic of the parameter values can be found in 386 [RFC3181]. 388 The coding for the & sub- 389 parameters is as follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |M|r|r|r| 8 |r|r|r|r| 1 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Preemption Priority | Defending Priority | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Preemption Priority: The priority of the new flow compared with the 400 defending priority of previously admitted flows. Higher values 401 represent higher priority. 403 Defending Priority: Once a flow is admitted, the preemption priority 404 becomes irrelevant. Instead, its defending priority is used to 405 compare with the preemption priority of new flows. 407 As specified in [RFC3181], & are 16-bit integer values. They are represented in network 409 byte order. 411 4.10. Admission Priority Parameter 413 A description of the semantic of the parameter values can be found in 414 [Y.1571]. The coding for the parameter is as 415 follows: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 |M|r|r|r| 9 |r|r|r|r| 1 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Admis.Priority| (Reserved) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 The 'Admis.Priority' field is a 8 bit unsigned integer in network 426 byte order. 428 High priority flows, normal priority flows, and best-effort priority 429 flows can have access to resources depending on their admission 430 priority value as follows: 432 Admission Priority: 434 0 - best-effort priority flow 435 1 - normal priority flow 436 2 - high priority flow 437 255 - not used 439 A reservation without an parameter (i.e., set to 440 255) MUST be treated as a reservation with an = 441 1. 443 4.11. Application-Level Resource Priority (ALRP) Parameter 445 A description of the semantic of the parameter values can be found in 446 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 447 parameter is as follows: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |M|r|r|r| 10 |r|r|r|r| 1 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | ALRP Namespace | ALRP Priority | (Reserved) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 The ALRP Namespace field is a 16 bits long unsigned integer in 458 network byte order and the ALRP Priority field is an 8 bit long 459 unsigned integer in network byte order containing the specific 460 priority value. 462 [RFC4412] defines a resource priority header and established the 463 initial registry; that registry was later extended by 464 [I-D.ietf-tsvwg-emergency-rsvp]. 466 4.12. Excess Treatment Parameter 468 The coding for the parameter is as follows: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |M|r|r|r| 11 |r|r|r|r| 1 | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Excess Trtmnt | Remark Value | Reserved | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Excess Treatment (8 bit unsigned integer value in network byte 479 order): Indicates how the QoS aware node should process out-of- 480 profile traffic, that is, traffic not covered by the 481 parameter. Allowed values are as follows: 483 0: drop 484 1: shape 485 2: remark 486 3: no metering or policing is permitted 488 The default excess treatment in case that none is specified is that 489 there are no guarantees to excess traffic, i.e., a QoS aware node can 490 do what it finds suitable. 492 When excess treatment is set to 'drop', all marked traffic MUST be 493 dropped by a QoS aware node. 495 When excess treatment is set to 'shape', it is expected that the QoS 496 Desired object carries a TMOD parameter. Excess traffic is to be 497 shaped to this TMOD. When the shaping causes unbounded queue growth 498 at the shaper traffic can be dropped. 500 When excess treatment is set to 'remark', the excess treatment 501 parameter MUST carry the remark value. For example, packets may be 502 remarked to drop remarked to pertain to a particular QoS class. In 503 the latter case, remarking relates to a DiffServ-type model, where 504 packets arrive marked as belonging to a certain QoS class, and when 505 they are identified as excess, they should then be remarked to a 506 different QoS Class. 508 If 'no metering or policing is permitted' is signaled, the QoS aware 509 node should accept the excess treatment parameter set by the sender 510 with special care so that excess traffic should not cause a problem. 511 To request the Null Meter [RFC3290] is especially strong, and should 512 be used with caution. 514 The Remark Value is an 8 bit unsigned integer value in network byte 515 order. 517 4.13. PHB Class Parameter 519 A description of the semantic of the parameter values can be found in 520 [RFC3140]. The coding for the parameter is as follows: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 |M|r|r|r| 12 |r|r|r|r| 1 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 528 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 530 As prescribed in [RFC3140], the encoding for a single PHB is the 531 recommended DSCP value for that PHB, left-justified in the 16 bit 532 field, with bits 6 through 15 set to zero. 534 The encoding for a set of PHBs is the numerically smallest of the set 535 of encodings for the various PHBs in the set, with bit 14 set to 1. 536 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 537 bit 14 set to 1.) 539 0 1 540 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | DSCP |0 0 0 0 0 0 0 0 X 0| 543 +---+---+---+---+---+---+---+---+ 545 PHBs not defined by standards action, i.e., experimental or local use 546 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 547 identification code, assigned by the IANA, is placed left-justified 548 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 549 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 551 0 1 552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | PHD ID CODE |0 0 X 0| 555 +---+---+---+---+---+---+---+---+ 557 Bits 12 and 13 are reserved either for expansion of the PHB 558 identification code, or for other use, at some point in the future. 560 In both cases, when a single PHBID is used to identify a set of PHBs 561 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 562 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 563 intra-microflow traffic reordering when different PHBs from the set 564 are applied to traffic in the same microflow). The set of AF1x PHBs 565 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 566 do not constitute a PHB Scheduling Class can be identified by using 567 more than one PHBID. 569 The registries needed to use [RFC3140] already exist. Hence, no new 570 registry needs to be created for this purpose. 572 4.14. DSTE Class Type Parameter 574 A description of the semantic of the parameter values can be found in 575 [RFC4124]. The coding for the parameter is as 576 follows: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 |M|r|r|r| 13 |r|r|r|r| 1 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |DSTE Cls. Type | (Reserved) | 584 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 586 DSTE Class Type: Indicates the DSTE class type. Values currently 587 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 588 that the parameter is not used. 590 4.15. Y.1541 QoS Class Parameter 592 A description of the semantic of the parameter values can be found in 593 [Y.1541]. The coding for the parameter is as 594 follows: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |M|r|r|r| 14 |r|r|r|r| 1 | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |Y.1541 QoS Cls.| (Reserved) | 602 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 604 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 605 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 606 that the parameter is not used. 608 Class 0: 610 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 611 10^-3. Real-time, highly interactive applications, sensitive to 612 jitter. Application examples include VoIP, Video Teleconference. 614 Class 1: 616 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 617 10^-3. Real-time, interactive applications, sensitive to jitter. 618 Application examples include VoIP, Video Teleconference. 620 Class 2: 622 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 623 10^-3. Highly interactive transaction data. Application examples 624 include signaling. 626 Class 3: 628 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 629 10^-3. Interactive transaction data. Application examples 630 include signaling. 632 Class 4: 634 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 635 10^-3. Low Loss Only applications. Application examples include 636 short transactions, bulk data, video streaming. 638 Class 5: 640 Mean delay unspecified, delay variation unspecified, loss ratio 641 unspecified. Unspecified applications. Application examples 642 include traditional applications of default IP networks. 644 Class 6: 646 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 647 10^-5. Applications that are highly sensitive to loss, such as 648 television transport, high-capacity TCP transfers, and TDM circuit 649 emulation. 651 Class 7: 653 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 654 10^-5. Applications that are highly sensitive to loss, such as 655 television transport, high-capacity TCP transfers, and TDM circuit 656 emulation. 658 5. Extensibility 660 This document is designed with extensibility in mind given that 661 different organizations and groups are used to define their own 662 Quality of Service parameters. This document provides an initial QoS 663 profile with common set of parameters. Ideally, these parameters 664 should be used whenever possible but there are cases where additional 665 parameters might be needed, or where the parameters specified in this 666 document are used with a different semantic. In this case it is 667 advisable to define a new QoS profile that may consist of new 668 parameters in addition to parameters defined in this document or an 669 entirely different set of parameters. 671 To enable the definition of new QoS profiles a 8 octet registry is 672 defined field that is represented by a 4-octet vendor and 4-octet 673 specifier field. The vendor field indicates the type as either 674 standards-specified or vendor-specific. If the four octets of the 675 vendor field are 0x00000000, then the value is standards-specified 676 and the registry is maintained by IANA, and any other value 677 represents a vendor-specific Object Identifier (OID). IANA created 678 registry is split into two value ranges; one range uses the 679 "Standards Action" and the second range uses "Specification Required" 680 allocation policy. The latter range is meant to be used by 681 organizations outside the IETF. 683 6. IANA Considerations 685 This section defines the registries and initial codepoint 686 assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. It also 687 defines the procedural requirements to be followed by IANA in 688 allocating new codepoints. 690 IANA is requested to create the following registries listed in the 691 subsections below. 693 6.1. QoS Profile 695 The QoS Profile refers to a 64 bit long field that is represented by 696 a 4-octet vendor and 4-octet specifier field. The vendor field 697 indicates the type as either standards-specified or vendor-specific. 698 If the four octets of the vendor field are 0x00000000, then the value 699 is standards-specified and the registry is maintained by IANA, and 700 any other value represents a vendor-specific Object Identifier (OID). 702 The specifier field indicates the actual QoS profile. The vendor 703 field 0x00000000 is reserved to indicate that the values in the 704 specifier field are maintained by IANA. This document requests IANA 705 to create such a registry and to allocate the value zero (0) for the 706 QoS profile defined in this document. 708 For any other vendor field, the specifier field is maintained by the 709 vendor. 711 For the IANA maintained QoS profiles the following allocation policy 712 is defined: 713 1 to 511: Standards Action 714 512 to 4095: Specification Required 716 Standards action is required to depreciate, delete, or modify 717 existing QoS profile values in the range of 0-511 and a specification 718 is required to depreciate, delete, or modify existing QoS profile 719 values in the range of 512-4095. 721 6.2. Parameter ID 723 The Parameter ID refers to a 12 bit long field. 725 The following values are allocated by this specification. 727 (0): 728 (1): 729 (2): 730 (3): 731 (4): 732 (5): 733 (6): 734 (7): & 735 (8): 736 (9): 737 (10): 738 (11): 739 (12): 740 (13): 742 The allocation policies for further values are as follows: 743 14-127: Standards Action 744 128-255: Private/Experimental Use 745 255-4095: Specification Required 747 A standards track document is required to depreciate, delete, or 748 modify existing Parameter IDs. 750 6.3. Admission Priority Parameter 752 The Admission Priority parameter refers to a 8 bit long field. 754 The following values are allocated by this specification: 755 Admission Priority 0: best-effort priority flow 756 Admission Priority 1: normal priority flow 757 Admission Priority 2: high priority flow 758 Admission Priority 3-63: Standards Action 759 Admission Priority 64-255: Reserved 761 6.4. Excess Treatment Parameter 763 The Excess Treatment parameter refers to an 8 bit long field. 765 The following values are allocated by this specification: 766 Excess Treatment Value 0: drop 767 Excess Treatment Value 1: shape 768 Excess Treatment Value 2: remark 769 Excess Treatment Value3: no metering or policing is permitted 770 Excess Treatment Values 4-63: Standards Action 771 Excess Treatment Value 64-255: Reserved 773 The 8 bit Remark Value allocation policies are as follows: 775 0-63: Specification Required 776 64-127: Private/Experimental Use 777 128-255: Reserved 779 6.5. DSTE Class Type Parameter 781 The DSTE Class Type parameter refers to an 8 bit long field. 783 The following values are allocated by this specification: 784 DSTE Class Type Value 0: DSTE Class Type 0 785 DSTE Class Type Value 1: DSTE Class Type 1 786 DSTE Class Type Value 2: DSTE Class Type 2 787 DSTE Class Type Value 3: DSTE Class Type 3 788 DSTE Class Type Value 4: DSTE Class Type 4 789 DSTE Class Type Value 5: DSTE Class Type 5 790 DSTE Class Type Value 6: DSTE Class Type 6 791 DSTE Class Type Value 7: DSTE Class Type 7 792 DSTE Class Type Values 8-63: Standards Action 793 DSTE Class Type Values 64-255: Reserved 795 6.6. Y.1541 QoS Class Parameter 797 The Y.1541 QoS Class parameter refers to an 8 bit long field. 799 The following values are allocated by this specification: 800 Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 801 Y.1541 QoS Class Value 1: Y.1541 QoS Class 1 802 Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 803 Y.1541 QoS Class Value 3: Y.1541 QoS Class 3 804 Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 805 Y.1541 QoS Class Value 5: Y.1541 QoS Class 5 806 Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 807 Y.1541 QoS Class Value 7: Y.1541 QoS Class 7 808 Y.1541 QoS Class Values 8-63: Standards Action 809 Y.1541 QoS Class Values 64-255: Reserved 811 The ALRP Namespace and ALRP Priority field inside the ALRP Parameter 812 take their values from the registry created by [RFC4412] and extended 813 with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are 814 required by IANA by this specification. 816 7. Security Considerations 818 This document does not raise any security concerns as it only defines 819 QoS parameters. 821 8. Acknowledgements 823 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 824 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 825 NSIS working group chairs (John Loughney and Martin Stiemerling) and 826 the former Transport Area Directors (Allison Mankin, Jon Peterson) 827 for their help. 829 9. References 831 9.1. Normative References 833 [I-D.ietf-tsvwg-emergency-rsvp] 834 Faucheur, F., "Resource ReSerVation Protovol (RSVP) 835 Extensions for Emergency Services", 836 draft-ietf-tsvwg-emergency-rsvp-05 (work in progress), 837 January 2008. 839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, March 1997. 842 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 843 Services", RFC 2210, September 1997. 845 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 846 of Guaranteed Quality of Service", RFC 2212, 847 September 1997. 849 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 850 Parameters for Integrated Service Network Elements", 851 RFC 2215, September 1997. 853 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 854 "Definition of the Differentiated Services Field (DS 855 Field) in the IPv4 and IPv6 Headers", RFC 2474, 856 December 1998. 858 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 859 and W. Weiss, "An Architecture for Differentiated 860 Services", RFC 2475, December 1998. 862 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 863 "Assured Forwarding PHB Group", RFC 2597, June 1999. 865 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 866 "Per Hop Behavior Identification Codes", RFC 3140, 867 June 2001. 869 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 870 RFC 3181, October 2001. 872 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 873 Informal Management Model for Diffserv Routers", RFC 3290, 874 May 2002. 876 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 877 Metric for IP Performance Metrics (IPPM)", RFC 3393, 878 November 2002. 880 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 881 Differentiated Services-aware MPLS Traffic Engineering", 882 RFC 3564, July 2003. 884 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 885 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 886 June 2005. 888 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 889 Priority for the Session Initiation Protocol (SIP)", 890 RFC 4412, February 2006. 892 [Y.1541] "Network Performance Objectives for IP-Based Services", , 893 2006. 895 [Y.1571] "Admission Control Priority Levels in Next Generation 896 Networks", , July 2006. 898 9.2. Informative References 900 [I-D.ietf-nsis-qspec] 901 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 902 QSPEC Template", draft-ietf-nsis-qspec-18 (work in 903 progress), October 2007. 905 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 906 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 907 October 1998. 909 [Y.1540] "Internet Protocol Data Communication Service - IP Packet 910 Transfer and Availability Performance Parameters", , 911 December 2002. 913 Authors' Addresses 915 Jouni Korhonen (editor) 916 TeliaSonera 917 Teollisuuskatu 13 918 Sonera FIN-00051 919 Finland 921 Email: jouni.korhonen@teliasonera.com 923 Hannes Tschofenig 924 Nokia Siemens Networks 925 Otto-Hahn-Ring 6 926 Munich, Bavaria 81739 927 Germany 929 Email: Hannes.Tschofenig@nsn.com 930 URI: http://www.tschofenig.com 932 Full Copyright Statement 934 Copyright (C) The IETF Trust (2008). 936 This document is subject to the rights, licenses and restrictions 937 contained in BCP 78, and except as set forth therein, the authors 938 retain all their rights. 940 This document and the information contained herein are provided on an 941 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 942 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 943 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 944 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 945 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 946 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 948 Intellectual Property 950 The IETF takes no position regarding the validity or scope of any 951 Intellectual Property Rights or other rights that might be claimed to 952 pertain to the implementation or use of the technology described in 953 this document or the extent to which any license under such rights 954 might or might not be available; nor does it represent that it has 955 made any independent effort to identify any such rights. Information 956 on the procedures with respect to rights in RFC documents can be 957 found in BCP 78 and BCP 79. 959 Copies of IPR disclosures made to the IETF Secretariat and any 960 assurances of licenses to be made available, or the result of an 961 attempt made to obtain a general license or permission for the use of 962 such proprietary rights by implementers or users of this 963 specification can be obtained from the IETF on-line IPR repository at 964 http://www.ietf.org/ipr. 966 The IETF invites any interested party to bring to its attention any 967 copyrights, patents or patent applications, or other proprietary 968 rights that may cover technology that may be required to implement 969 this standard. Please address the information to the IETF at 970 ietf-ipr@ietf.org. 972 Acknowledgment 974 Funding for the RFC Editor function is provided by the IETF 975 Administrative Support Activity (IASA).