idnits 2.17.1 draft-ietf-dime-qos-attributes-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 968. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 29, 2007) is 6046 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: 'EAP-Master-Session-Key' is mentioned on line 591, but not defined == Missing Reference: 'QoS-desired' is mentioned on line 742, but not defined == Missing Reference: 'QoS-Authorized' is mentioned on line 745, but not defined == Unused Reference: 'RFC2234' is defined on line 887, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-radext-filter-rules' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) Summary: 5 errors (**), 0 flaws (~~), 6 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: April 1, 2008 M. Arumaithurai 7 University of Goettingen 8 September 29, 2007 10 Quality of Service Attributes for Diameter 11 draft-ietf-dime-qos-attributes-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 1, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document extends the QoSFilterRule AVP functionality of the 45 Diameter Base protocol and the functionality of the QoS-Filter-Rule 46 AVP defined in RFC 4005. The ability to convey Quality of Service 47 information is made available to the Diameter Network Access Server 48 Application, the Diameter Credit Control Application and the Diameter 49 Extensible Authentication Protocol (EAP) Application. Future 50 Diameter applications can easily integrate Quality of Service support 51 in addition to packet filtering. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Commands, AVPs and Advertising Application Support . . . . . . 3 58 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 4 60 3.3. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 4 61 3.4. Credit-Control-Request (CCR) . . . . . . . . . . . . . . . 5 62 3.5. Credit-Control-Answer (CCA) . . . . . . . . . . . . . . . 6 63 3.6. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 7 64 3.7. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 8 65 4. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . . . 9 66 4.1. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 9 67 4.2. QoS-Profile AVP . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 10 69 4.4. Extended-QoS-Filter-Rule AVP . . . . . . . . . . . . . . . 10 70 4.5. QoSBlob-Group AVP . . . . . . . . . . . . . . . . . . . . 11 71 4.6. QoS-ID AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.7. QoS-ObjectType . . . . . . . . . . . . . . . . . . . . . . 11 73 4.8. QoSBlob AVP . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.9. QoS-Flow-State AVP . . . . . . . . . . . . . . . . . . . . 12 75 4.10. QoS-Flow-Direction AVP . . . . . . . . . . . . . . . . . . 12 76 5. Semantics of QoS Parameters . . . . . . . . . . . . . . . . . 12 77 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Diameter EAP with QoS Information . . . . . . . . . . . . 13 79 6.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 14 80 6.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 15 81 6.4. Diameter Server Initiated Re-authorization of QoS . . . . 16 82 6.5. Diameter Credit Control with QoS Information . . . . . . . 17 83 7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 18 84 7.1. DER and DEA Commands AVP Table . . . . . . . . . . . . . . 18 85 7.2. CCR and CCA Commands AVP Table . . . . . . . . . . . . . . 18 86 7.3. AAR and AAA Commands AVP Table . . . . . . . . . . . . . . 19 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Intellectual Property and Copyright Statements . . . . . . . . . . 23 96 1. Introduction 98 This document defines a number of Diameter Quality of Service (QoS) 99 related AVPs that can be used with the Diameter Base protocol, and 100 the Diameter Credit Control Application, the Diameter Extensible 101 Authentication Protocol (EAP) Application and the Diameter Network 102 Access Server Application to convey Quality of Service information. 103 The Extended-QoS-Filter-Rule AVP thereby replaces the QoSFilterRule, 104 defined in RFC 3588 [RFC3588], and the QoS-Filter-Rule, defined in 105 RFC 4005 [RFC4005]. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. Commands, AVPs and Advertising Application Support 115 3.1. Command Codes 117 This document re-uses the Diameter Base protocol [RFC3588], Diameter 118 Credit Control [RFC4006], Diameter NASREQ [RFC4005] and Diameter EAP 119 [RFC4072] application commands. The following commands are re-used 120 to carry QoS related AVPs: 122 Command-Name Abbrev. Code Reference 124 Diameter-EAP-Request DER 268 RFC 4072 125 Diameter-EAP-Answer DEA 268 RFC 4072 127 Credit-Control-Request CCR 272 RFC 4006 128 Credit-Control-Answer CCA 272 RFC 4006 130 AA-Request AAR 265 RFC 4005 131 AA-Answer AAA 265 RFC 4005 133 Figure 1: Command Codes 135 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 136 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 137 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 138 (ACR), and Accounting-Answer (ACA) commands are used together with 139 this specification they follow the rules in Diameter NASREQ 140 [RFC4005], Diameter EAP [RFC4072], Credit Control [RFC4006] and 141 Diameter Base Protocol [RFC3588]. The accounting commands use the 142 Application Identifier value of the respective application. 144 3.2. Diameter-EAP-Request (DER) 146 The Diameter-EAP-Request (DER) command [RFC4072], indicated by the 147 Command-Code field set to 268 and the 'R' bit set in the Command 148 Flags field, may be sent by the NAS to the Diameter server providing 149 network access authentication and authorization services. At the 150 same time as the network access authentication and authorization, the 151 NAS MAY request the Diameter server to authorize provisioning of QoS 152 resources. 154 The message format is the same as defined in [RFC4072] with an 155 addition of QoS specific AVPs. Figure 2 shows the DER message used 156 with the QoS specific AVPs: 158 ::= < Diameter Header: 268, REQ, PXY > 159 < Session-Id > 160 { Auth-Application-Id } 161 { Origin-Host } 162 { Origin-Realm } 163 { Destination-Realm } 164 { Auth-Request-Type } 166 [ Destination-Host ] 167 [ User-Name ] 169 [ QoS-Capability ] 170 * [ QoS-Resources ] 172 ... 173 * [ AVP ] 175 Figure 2: Diameter EAP Request Command 177 3.3. Diameter-EAP-Answer (DEA) 179 The Diameter-EAP-Answer (DEA) message defined in [RFC4072], indicated 180 by the Command- Code field set to 268 and 'R' bit cleared in the 181 Command Flags field is sent in response to the Diameter-EAP-Request 182 message (DER). If the QoS service is successfully authorized and the 183 Diameter server was able to fulfill the QoS Authorization request (if 184 needed) then the response MAY include the QoS-Resources AVPs. 186 The message format is the same as defined in [RFC4072] with an 187 addition of QoS specific AVPs. Figure 3 shows the DEA message used 188 with the QoS specific AVPs: 190 ::= < Diameter Header: 268, PXY > 191 < Session-Id > 192 { Auth-Application-Id } 193 { Auth-Request-Type } 194 { Result-Code } 195 { Origin-Host } 196 { Origin-Realm } 198 * [ QoS-Resources ] 200 [ Session-Timeout ] 201 [ User-Name ] 202 ... 203 * [ AVP ] 205 Figure 3: Diameter EAP Answer Command 207 3.4. Credit-Control-Request (CCR) 209 The Credit-Control-Request (CCR) command [RFC4006], indicated by the 210 Command-Code field set to 272 and the 'R' bit set in the Command 211 Flags field, may be sent by the NAS to the Diameter-QoS server to 212 request QoS credit authorization for a given QoS provisioning 213 request. In that case the CCR command MAY also carry the QoS- 214 Resources AVPs. 216 The message format is the same as defined in [RFC4006] with an 217 addition of QoS specific AVPs. Figure 4 shows the CCR message used 218 with the QoS specific AVPs: 220 ::= < Diameter Header: 272, REQ, PXY > 221 < Session-Id > 222 { Auth-Application-Id } 223 { Origin-Host } 224 { Origin-Realm } 225 { Destination-Realm } 226 { Auth-Request-Type } 227 { Service-Context-Id } 228 { CC-Request-Type } 229 { CC-Request-Number } 230 [ Destination-Host ] 231 [ User-Name ] 233 [ QoS-Capability ] 234 * [ QoS-Resources ] 236 ... 237 * [ AVP ] 239 Figure 4: Credit Control Request Command 241 3.5. Credit-Control-Answer (CCA) 243 The Credit-Control-Answer (CCA) command [RFC4006], indicated by the 244 Command-Code field set to 272 and the 'R' bit set in the Command 245 Flags field is sent in response to the CC-Request (CCR) message to 246 acknowledge a CC-Request command. If the Diameter QoS server was 247 able to fulfill the QoS request (if needed) then the response MAY 248 include the QoS-Resources AVPs. 250 The message format is the same as defined in [RFC4006] with an 251 addition of QoS specific AVPs. Figure 5 shows the CCA message used 252 with the QoS specific AVPs: 254 ::= < Diameter Header: 272, PXY > 255 < Session-Id > 256 { Result-Code } 257 { Origin-Host } 258 { Origin-Realm } 259 { Auth-Application-Id } 260 { CC-Request-Type } 261 { CC-Request-Number } 262 [ User-Name ] 263 [ CC-Session-Failover ] 264 [ CC-Sub-Session-Id ] 265 [ Acct-Multi-Session-Id ] 266 [ Origin-State-Id ] 267 [ Event-Timestamp ] 269 * [ QoS-Resources ] 271 ... 272 * [ AVP ] 274 Figure 5: Credit Control Answer Command 276 3.6. AA-Request (AAR) 278 The AA-Request (AAR) message, indicated by the Command-Code field set 279 to 265 and 'R' bit set in the Command Flags field, may be sent by the 280 NAS to the Diameter server providing network access configuration 281 services. At the same time as the network access authentication and 282 authorization, the NAS MAY request the Diameter server to authorize 283 provisioning of QoS resources. 285 The message format is the same as defined in [RFC4005] with an 286 addition of QoS specific AVPs. Figure 6 shows the AAR message used 287 with the QoS specific AVPs: 289 ::= < Diameter Header: 265, REQ, PXY > 290 < Session-Id > 291 { Auth-Application-Id } 292 { Origin-Host } 293 { Origin-Realm } 294 { Destination-Realm } 295 { Auth-Request-Type } 297 [ QoS-Capability ] 298 * [ QoS-Resources ] 300 [ Destination-Host ] 301 ... 302 * [ AVP ] 304 Figure 6: AA Request Command 306 3.7. AA-Answer (AAA) 308 The AA-Answer (AAA) message, indicated by the Command-Code field set 309 to 265 and 'R' bit cleared in the Command Flags field is sent in 310 response to the AA-Request (AAR) message for confirmation of the 311 result of QoS provisioning. If the QoS service is successfully 312 authorized and the Diameter server was able to fulfill the QoS 313 provisioning request (if needed) then the response MAY include the 314 QoS-Resources AVPs. 316 The message format is the same as defined in [RFC4005] with an 317 addition of QoS specific AVPs. Figure 7 shows the AAA message used 318 with the QoS specific AVPs: 320 ::= < Diameter Header: 265, PXY > 321 < Session-Id > 322 { Auth-Application-Id } 323 { Auth-Request-Type } 324 { Result-Code } 325 { Origin-Host } 326 { Origin-Realm } 328 * [ QoS-Resources ] 330 [ User-Name ] 331 [ Session-Timeout ] 332 ... 333 * [ AVP ] 334 Figure 7: AA Answer Command 336 4. Diameter QoS Defined AVPs 338 The following table lists the Diameter AVPs used by this document, 339 their AVP code values, types, possible flag values, and whether the 340 AVP may be encrypted. 342 +------------------+ 343 | AVP Flag Rules | 344 +-------------------------------------------------|----+---+----+----+ 345 | AVP Section |MUST|MAY|SHLD|MUST| 346 | Attribute Name Code Defined Data Type | | | NOT| NOT| 347 +-------------------------------------------------+----+---+----+----+ 348 |QoS-Capability TBD 4.1 Grouped | |M,P| | V | 349 |QoS-Profile TBD 4.2 Unsigned32 | |M,P| | V | 350 |QoS-Resources TBD 4.3 Grouped | |M,P| | V | 351 |Extended-QoS-Filter-Rule TBD 4.4 Grouped | |M,P| | V | 352 |QoSBlob-Group TBD 4.5 Grouped | |M,P| | V | 353 |QoS-ID TBD 4.6 Unsigned32 | |M,P| | V | 354 |QoS-ObjectType TBD 4.7 Enumerated | |M,P| | V | 355 |QoSBlob TBD 4.8 OctetString| |M,P| | V | 356 |QoS-Flow-State TBD 4.9 Enumerated | |M,P| | V | 357 |QoS-Flow-Direction TBD 4.10 Enumerated | |M,P| | V | 358 +-------------------------------------------------+----+---+----+----+ 360 4.1. QoS-Capability AVP 362 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 363 a list of supported Quality of Service profiles (and therefore the 364 support of respective AVPs). 366 QoS-Capability ::= < AVP Header: XXX > 367 1* { QoS-Profile } 368 * [ AVP ] 370 4.2. QoS-Profile AVP 372 The QoS-Profile AVP (AVP Code TBD) is of type Unsigned64 and contains 373 the vendor and a specifier field. The 64-bit value in the QoS- 374 Profile AVP is structured as shown below. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Vendor | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Specifier | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Vendor Field: 386 32 bits of IANA SMI Network Management Private Enterprise Code. 387 The Vendor-ID 0x00000000 is reserved for IANA registered QoS 388 profiles. 390 Specifier Field: 392 32-bit unsigned integer, representing the defined profile value. 394 An initial QoS profile is defined with vendor field set to 0x00000000 395 and the specifier field set to 0, as described in 396 [I-D.ietf-dime-qos-parameters]. The registry for the QoS profiles is 397 created with the same document. 399 4.3. QoS-Resources AVP 401 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes 402 description of the Quality of Service resources. 404 QoS-Resources ::= < AVP Header: XXX > 405 0* [ Extended-QoS-Filter-Rule ] 406 0* [ QoSBlob-Group ] 407 [ QoS-Flow-State ] 408 * [ AVP ] 410 4.4. Extended-QoS-Filter-Rule AVP 412 TheExtended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped. 413 The QoS filter rule associated with the QoS-ID re-uses the RADIUS 414 NAS-Traffic-Rule AVP [I-D.ietf-radext-filter-rules]. This AVP ties a 415 specific filter to a QoS-ID that in turn refers to a specific 416 QoSBlob-Group. At least either one of the NAS-Traffic-Rule or the 417 QoS-Flow-Direction AVPs SHOULD be included. 419 Extended-QoS-Filter-Rule ::= < AVP Header: XXX > 420 { QoS-ID } 421 [ NAS-Traffic-Rule ] 422 [ QoS-Flow-Direction ] 423 * [ AVP ] 425 4.5. QoSBlob-Group AVP 427 The QoSBlob-Group AVP (AVP Code TBD) is of type Grouped and ties the 428 QoS-ID AVP together to the QoSBlob AVP. All parameters followed by 429 the QoSBlob-Type AVP refer to the same QoS model/profile. 431 QoSBlob-Group ::= < AVP Header: XXX > 432 { QoS-ID } 433 { QoS-ObjectType } 434 { QoS-Profile } 435 0* [ QoSBlob ] 436 * [ AVP ] 438 It is possible to have predefined QoS profiles that contains very 439 specific QoS values and refer to it only using a specifically 440 assigned QoS-Profile AVP value. In this case including QoSBlob AVP 441 is not needed. 443 4.6. QoS-ID AVP 445 The QoS-ID AVP (AVP Code TBD) is of type Unsigned32 and references 446 the QoSBlob. 448 4.7. QoS-ObjectType 450 The QoS-ObjectType AVP (AVP Code TBD) is of type Enumerated and 451 provides the semantic for the content of the QoSBlob AVP. 453 This document defines the following values: 455 (0): QoS-Desired 456 (1): QoS-Available 457 (2): QoS-Reserved 458 (3): Minimum-QoS 459 (4): QoS-Authorized 461 4.8. QoSBlob AVP 463 The QoSBlob AVP (AVP Code TBD) is of type OctetString and contains 464 Quality of Service parameters. These parameters are defined in a 465 separate document, see [I-D.ietf-dime-qos-parameters]. 467 4.9. QoS-Flow-State AVP 469 The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It 470 gives an indication as to how the flow has to be treated. The 471 Extended-QoS-Filter-Rule already provides an indicate whether a flow 472 is permitted or denied. This optional AVP provides additional 473 information about the treatment. Currently, a single value is 474 defined; further values are available via IANA registration. 476 Value | Name and Semantic 477 ------+------------------------------------------------------------ 478 0 | QOS_FLOW_STATE_PENDING - The QoS reservation is kept 479 | pending. The QoS resources are not installed and subsequent 480 | QoS signaling is necessary to active them. 482 4.10. QoS-Flow-Direction AVP 484 The QoS-Flow-Direction AVP (AVP Code TBD) is of type Enumerated. It 485 gives an indication of the direction the provided QoS information 486 should be applied to. The QoS information can be applied to downlink 487 flows or to uplink flows. The QoS-Flow-Direction AVP may be used in 488 conjunction with the NAS-Traffic-Rule AVP. In a case conflicting 489 definitions between the QoS-Flow-Direction and the NAS-Traffic-Rule, 490 the QoS-Flow-Direction has precedence meaning the filter rules are 491 applied only to the flows going to the direction indicated by the 492 QoS-Flow-Direction AVP. In the absence of the QoS-Flow-Direction the 493 default treatment is to both directions. Currently, three values are 494 defined; further values are available via IANA registration. 496 Value | Name and Semantic 497 ------+------------------------------------------------------------ 498 0 | QOS_FLOW_DIRECTION_BOTH - The QoS information in applied to 499 | both downlink and uplink flows. This is also the default. 500 1 | QOS_FLOW_DIRECTION_DL - The QoS information in applied to 501 | downlink flows only. 502 2 | QOS_FLOW_DIRECTION_UL - The QoS information in applied to 503 | uplink flows only. 505 5. Semantics of QoS Parameters 507 The QoS parameters carried in the QoS-Resources AVP may appear in 508 different messages. The semantic of the QoS parameters depend on the 509 information provided in the Object Type defined in 510 [I-D.ietf-dime-qos-parameters]. The Object Type currently lists 5 511 values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved (2), 512 Minimum-QoS (3), and QoS-Authorized (4). 514 The semantics of the different Object Types are as follows: 516 Object Type Direction Semantic 517 ---------------------------------------------------------------------- 518 QoS-Desired C->S Please authorize the indicated QoS 519 QoS-Desired C<-S NA 520 QoS-Available C->S Adminission Control at router indicates 521 that this QoS is available. (note 1) 522 QoS-Available C<-S Indicated QoS is available. (note 2) 523 QoS-Reserved C->S Used for reporting during accounting. 524 QoS-Reserved C<-S NA 525 Minimum-QoS C->S Indicates that the client is not interested 526 interested in authorizing QoS that is 527 lower than Min. QoS 528 Minimum-QoS C<-S The client must not provide QoS guarantees 529 lower than Min. QoS 530 QoS-Authorized C->S NA 531 QoS-Authorized C<-S Indicated QoS authorized 533 Legend: 535 C: Diameter client 536 S: Diameter server 537 NA: Not applicable to this document; 538 no semantic defined in this specification 540 Notes: 542 (1) QoS-Available is only useful in relationship with QoS-Desired 543 (and optionally with Minimum-QoS). 544 (2) QoS-Available is only useful when the AAA server performs 545 admission control and knows about the resources in the network. 547 6. Examples 549 This section shows a number of signaling flows where QoS negotiation 550 and authorization is part of the conventional NASREQ, EAP or Credit 551 Control applications message exchanges. 553 6.1. Diameter EAP with QoS Information 555 Figure 18 shows a simple signaling flow where a NAS (Diameter Client) 556 announces its QoS awareness and capabilities included into the DER 557 message and as part of the access authentication procedure. Upon 558 completion of the EAP exchange, the Diameter Server provides a pre- 559 provisioned QoS profile with the QoS-ObjectType in the QoSBlob-Group 560 AVP set to "QoS-Authorized", to the NAS in the final DEA message. 562 End Diameter Diameter 563 Host Client server 564 | | | 565 | (initiate EAP) | | 566 |<------------------------------>| | 567 | | Diameter-EAP-Request | 568 | | EAP-Payload(EAP Start) | 569 | | QoS-Capability | 570 | |------------------------------->| 571 | | | 572 | | Diameter-EAP-Answer | 573 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 574 | | EAP-Payload(EAP Request #1) | 575 | |<-------------------------------| 576 | EAP Request(Identity) | | 577 |<-------------------------------| | 578 : : : 579 : <<>> : 580 : : : 581 | | | 582 | EAP Response #N | | 583 |------------------------------->| | 584 | | Diameter-EAP-Request | 585 | | EAP-Payload(EAP Response #N) | 586 | |------------------------------->| 587 | | | 588 | | Diameter-EAP-Answer | 589 | | Result-Code=DIAMETER_SUCCESS | 590 | | EAP-Payload(EAP Success) | 591 | | [EAP-Master-Session-Key] | 592 | | (authorization AVPs) | 593 | | QoS-Resources(QoS-Authorized) | 594 | |<-------------------------------| 595 | | | 596 | EAP Success | | 597 |<-------------------------------| | 598 | | | 600 Figure 18: Example of a Diameter EAP enhanced with QoS Information 602 6.2. Diameter NASREQ with QoS Information 604 Figure 19 shows a similar pre-provisioned QoS signaling as in 605 Figure 18 but using the NASREQ application instead of EAP 606 application. 608 End Diameter 609 Host NAS Server 610 | | | 611 | Start Network | | 612 | Attachment | | 613 |<---------------->| | 614 | | | 615 | |AA-Request | 616 | |NASREQ-Payload | 617 | |QoS-Capability | 618 | +----------------------------->| 619 | | | 620 | | AA-Answer| 621 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 622 | NASREQ-Payload(NASREQ Request #1)| 623 | |<-----------------------------+ 624 | | | 625 | Request | | 626 |<-----------------+ | 627 | | | 628 : : : 629 : <<>> : 630 : : : 631 | Response #N | | 632 +----------------->| | 633 | | | 634 | |AA-Request | 635 | |NASREQ-Payload ( Response #N )| 636 | +----------------------------->| 637 | | | 638 | | AA-Answer| 639 | | Result-Code=DIAMETER_SUCCESS| 640 | | (authorization AVPs)| 641 | |QoS-Resources(QoS-Authorized) | 642 | |<-----------------------------+ 643 | | | 644 | Success | | 645 |<-----------------+ | 646 | | | 648 Figure 19: Example of a Diameter NASREQ enhanced with QoS Information 650 6.3. QoS Authorization 652 Figure 20 shows an example of authorization only QoS signaling as 653 part of the NASREQ message exchange. The NAS provides the Diameter 654 server with the "QoS-Desired" QoS-ObjectType AVP included in the QoS- 655 Resources AVP. The Diameter server then either authorizes the 656 indicated QoS or rejects the request and informs the NAS about the 657 result. In this scenario the NAS does not need to include the QoS- 658 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 659 does the same and also the NAS is authorizing a specific QoS profile, 660 not a pre-provisioned one. 662 End Diameter 663 Host NAS Server 664 | | | 665 | | | 666 | QoS Request | | 667 +----------------->| | 668 | | | 669 | |AA-Request | 670 | |Auth-Request-Type=AUTHORIZE_ONLY 671 | |NASREQ-Payload | 672 | |QoS-Resources(QoS-Desired) | 673 | +----------------------------->| 674 | | | 675 | | AA-Answer| 676 | | NASREQ-Payload(Success)| 677 | | QoS-Resources(QoS-Authorized)| 678 | |<-----------------------------+ 679 | Accept | | 680 |<-----------------+ | 681 | | | 682 | | | 683 | | | 685 Figure 20: Example of an Authorization-Only Message Flow 687 6.4. Diameter Server Initiated Re-authorization of QoS 689 Figure 21 shows a message exchange for a Diameter server initiated 690 QoS re-authorization procedure. The Diameter server sends the NAS a 691 RAR message requesting re-authorization for an existing session and 692 the NAS acknowledges it with a RAA message. The NAS is aware of its 693 existing QoS profile and information for the ongoing session that the 694 Diameter server requested for re-authorization. Thus, the NAS must 695 initiate re-authorization of the existing QoS profile. The re- 696 authorization procedure is the same as in Figure 20. 698 End Diameter 699 Host NAS Server 700 | | | 701 | | | 702 : : : 703 : <<>> : 704 : : : 705 | | | 706 | | RA-Request | 707 | |<-----------------------------+ 708 | | | 709 | |RA-Answer | 710 | |Result-Code=DIAMETER_SUCCESS | 711 | +----------------------------->| 712 | | | 713 | | | 714 | |AA-Request | 715 | |NASREQ-Payload | 716 | |Auth-Request-Type=AUTHORIZE_ONLY 717 | |QoS-Resources(QoS-Desired) | 718 | +----------------------------->| 719 | | | 720 | | AA-Answer| 721 | | Result-Code=DIAMETER_SUCCESS| 722 | | (authorization AVPs)| 723 | | QoS-Resources(QoS-Authorized)| 724 | |<-----------------------------+ 725 | | | 727 Figure 21: Example of a Server-initiated Re-Authorization Procedure 729 6.5. Diameter Credit Control with QoS Information 731 In this case the User is charged as soon as the Service Element (CC 732 client) receives the service request. In this case the client uses 733 the "QoS-Desired" QoS-ObjectType parameter in the QoS-Resources AVP 734 that it sends to the Accounitng server. The server responds with a 735 "QoS-Available" QoS-ObjectType parameter in the QoS-Resources AVP 736 Service Element 737 End User (CC Client) B CC Server 738 | | | | 739 |(1) Service Request | | | 740 |-------------------->| | | 741 | |(2) CCR (event, DIRECT_DEBITING,| 742 | | QoS-Resources[QoS-desired]) | 743 | |-------------------------------->| 744 | |(3) CCA (Granted-Units, QoS- | 745 | | Resources[QoS-Authorized]) | 746 | |<--------------------------------| 747 |(4) Service Delivery | | | 748 |<--------------------| | | 749 |(5) Begin service | | | 750 |<------------------------------------>| | 751 | | | | 752 . . . . 753 . . . . 755 Figure 22: Example for a One-Time Diameter Credit Control Charging 756 Event 758 7. AVP Occurrence Tables 760 7.1. DER and DEA Commands AVP Table 762 The following table lists the Quality of Service specific AVPs 763 defined in this document that may be present in the DER and DEA 764 Commands, as defined in this document and in [RFC4072]. 766 +---------------+ 767 | Command-Code | 768 |-------+-------+ 769 Attribute Name | DER | DEA | 770 -------------------------------+-------+-------+ 771 QoS-Capability | 0-1 | 0 | 772 QoS-Resources | 0+ | 0+ | 773 +-------+-------+ 775 Figure 23: DER and DEA Commands AVP table 777 7.2. CCR and CCA Commands AVP Table 779 The following table lists the Quality of Service specific AVPs 780 defined in this document that may be present in the CCR and CCA 781 Commands, as defined in this document and in [RFC4006]. 783 +---------------+ 784 | Command-Code | 785 |-------+-------+ 786 Attribute Name | CCR | CCA | 787 -------------------------------+-------+-------+ 788 QoS-Capability | 0-1 | 0 | 789 QoS-Resources | 0+ | 0+ | 790 +-------+-------+ 792 Figure 24: CCR and CCA Commands AVP table 794 7.3. AAR and AAA Commands AVP Table 796 The following table lists the Quality of Service specific AVPs 797 defined in this document that may be present in the AAR and AAA 798 Commands, as defined in this document and in [RFC4005]. 800 +---------------+ 801 | Command-Code | 802 |-------+-------+ 803 Attribute Name | AAR | AAA | 804 -------------------------------+-------+-------+ 805 QoS-Capability | 0-1 | 0 | 806 QoS-Resources | 0+ | 0+ | 807 +-------+-------+ 809 Figure 25: AAR and AAA Commands AVP table 811 8. Acknowledgments 813 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 814 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Avi Lior, 815 Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina 816 Tsou, Pete McCann, Georgios Karagiannis and Elwyn Davies for their 817 comments. 819 9. IANA Considerations 821 This specification requests IANA to assignment of new AVPs from the 822 AVP Code namespace defined in RFC 3588 [RFC3588]. Section 4 lists 823 the newly defined AVPs. 825 IANA is requested to allocate a registry for the QoS-ObjectType. The 826 following values are allocated by this specification. 828 (0): QoS-Desired 829 (1): QoS-Available 830 (2): QoS-Reserved 831 (3): Minimum-QoS 832 (4): QoS-Authorized 834 A specification is required to add a new value to the registry. A 835 standards track document is required to depreciate, delete, or modify 836 existing values. 838 IANA is requested to allocate a registry for the QoS-Flow-State. The 839 following values are allocated by this specification. 841 Value | Name 842 ------+------------------------------------------------------------ 843 0 | QOS_FLOW_STATE_PENDING 845 A specification is required to add a new value to the registry. A 846 standards track document is required to depreciate, delete, or modify 847 existing values. 849 IANA is requested to allocate a registry for the QoS-Flow-Direction. 850 The following values are allocated by this specification. 852 Value | Name 853 ------+------------------------------------------------------------ 854 0 | QOS_FLOW_DIRECTION_BOTH 855 1 | QOS_FLOW_DIRECTION_DL 856 2 | QOS_FLOW_DIRECTION_UL 858 A specification is required to add a new value to the registry. A 859 standards track document is required to depreciate, delete, or modify 860 existing values. 862 10. Security Considerations 864 This document describes the extension of Diameter for conveying 865 Quality of Service information. The security considerations of the 866 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 867 Use of the AVPs defined in this document MUST take into consideration 868 the security issues and requirements of the Diameter Base protocol. 870 11. References 871 11.1. Normative References 873 [I-D.ietf-dime-qos-parameters] 874 Korhonen, J. and H. Tschofenig, "Quality of Service 875 Parameters for Usage with the AAA Framework", 876 draft-ietf-dime-qos-parameters-00 (work in progress), 877 June 2007. 879 [I-D.ietf-radext-filter-rules] 880 Congdon, P., "RADIUS Attributes for Filtering and 881 Redirection", draft-ietf-radext-filter-rules-03 (work in 882 progress), July 2007. 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, March 1997. 887 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 888 Specifications: ABNF", RFC 2234, November 1997. 890 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 891 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 893 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 894 "Diameter Network Access Server Application", RFC 4005, 895 August 2005. 897 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 898 Loughney, "Diameter Credit-Control Application", RFC 4006, 899 August 2005. 901 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 902 Authentication Protocol (EAP) Application", RFC 4072, 903 August 2005. 905 11.2. Informative References 907 Authors' Addresses 909 Jouni Korhonen (editor) 910 TeliaSonera 911 Teollisuuskatu 13 912 Sonera FIN-00051 913 Finland 915 Email: jouni.korhonen@teliasonera.com 916 Hannes Tschofenig 917 Nokia Siemens Networks 918 Otto-Hahn-Ring 6 919 Munich, Bavaria 81739 920 Germany 922 Email: Hannes.Tschofenig@nsn.com 923 URI: http://www.tschofenig.com 925 Mayutan Arumaithurai 926 University of Goettingen 928 Email: mayutan.arumaithurai@gmail.com 930 Full Copyright Statement 932 Copyright (C) The IETF Trust (2007). 934 This document is subject to the rights, licenses and restrictions 935 contained in BCP 78, and except as set forth therein, the authors 936 retain all their rights. 938 This document and the information contained herein are provided on an 939 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 940 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 941 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 942 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 943 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 944 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 946 Intellectual Property 948 The IETF takes no position regarding the validity or scope of any 949 Intellectual Property Rights or other rights that might be claimed to 950 pertain to the implementation or use of the technology described in 951 this document or the extent to which any license under such rights 952 might or might not be available; nor does it represent that it has 953 made any independent effort to identify any such rights. Information 954 on the procedures with respect to rights in RFC documents can be 955 found in BCP 78 and BCP 79. 957 Copies of IPR disclosures made to the IETF Secretariat and any 958 assurances of licenses to be made available, or the result of an 959 attempt made to obtain a general license or permission for the use of 960 such proprietary rights by implementers or users of this 961 specification can be obtained from the IETF on-line IPR repository at 962 http://www.ietf.org/ipr. 964 The IETF invites any interested party to bring to its attention any 965 copyrights, patents or patent applications, or other proprietary 966 rights that may cover technology that may be required to implement 967 this standard. Please address the information to the IETF at 968 ietf-ipr@ietf.org. 970 Acknowledgment 972 Funding for the RFC Editor function is provided by the IETF 973 Administrative Support Activity (IASA).