idnits 2.17.1 draft-ietf-dime-qos-attributes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 956. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (July 9, 2007) is 6130 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 482, but not defined == 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 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-17 Summary: 5 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: January 10, 2008 M. Arumaithurai 7 University of Goettingen 8 July 9, 2007 10 Quality of Service Attributes for Diameter and RADIUS 11 draft-ietf-dime-qos-attributes-01.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 January 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document extends the functionality of the Diameter Base protocol 45 and other Diameter applications with respect to their ability to 46 convey Quality of Service information. The AVPs defined in this 47 document are also available for Remote Authentication Dial In User 48 Service (RADIUS). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Commands, AVPs and Advertising Application Support . . . . . . 3 55 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 4 57 3.3. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 4 58 3.4. Credit-Control-Request (CCR) . . . . . . . . . . . . . . . 5 59 3.5. Credit-Control-Answer (CCA) . . . . . . . . . . . . . . . 6 60 3.6. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 7 61 3.7. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 8 62 4. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . . . 9 63 4.1. QoS-ID AVP . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2. QoS-Flow-State AVP . . . . . . . . . . . . . . . . . . . . 9 65 4.3. QSPEC AVP . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.4. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 10 67 4.5. QoS-Parameter AVP . . . . . . . . . . . . . . . . . . . . 10 68 4.6. Extended-QoS-Filter-Rule AVP . . . . . . . . . . . . . . . 10 69 4.7. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 10 70 4.8. QSPEC-Type AVP . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. Diameter EAP with QoS Information . . . . . . . . . . . . 11 73 5.2. QoS Authorization . . . . . . . . . . . . . . . . . . . . 12 74 5.3. Diameter NASREQ with QoS Information . . . . . . . . . . . 13 75 5.4. Diameter Server Initiated Re-authorization of QoS . . . . 14 76 5.5. Diameter Credit-Control with QoS Information . . . . . . . 15 77 5.6. Diameter Server Initiated Credit Re-authorization . . . . 16 78 5.7. QoS and Credit-Control as Part of Authentication and 79 Authorization . . . . . . . . . . . . . . . . . . . . . . 17 80 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 19 81 6.1. DER and DEA Commands AVP Table . . . . . . . . . . . . . . 19 82 6.2. CCR and CCA Commands AVP Table . . . . . . . . . . . . . . 19 83 6.3. AAR and AAA Commands AVP Table . . . . . . . . . . . . . . 19 84 7. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 Intellectual Property and Copyright Statements . . . . . . . . . . 23 94 1. Introduction 96 This document defines a number of Diameter Quality of Service (QoS) 97 related AVPs that can be used with the Diameter Base protocol, and 98 Diameter Credit Control, Diameter EAP and Diameter NASREQ 99 applications to convey Quality of Service information. The Extended- 100 QoS-Filter-Rule AVP thereby replaces the QoSFilterRule, defined in 101 RFC 3588 [RFC3588], and the QoS-Filter-Rule, defined in RFC 4005 102 [RFC4005]. 104 The AVPs defined in this document are also available for Remote 105 Authentication Dial In User Service (RADIUS). 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], and 118 Diameter Credit-Control [RFC4006], Diameter NASREQ [RFC4072] and 119 Diameter EAP [RFC4005] application commands. The following commands 120 are re-used 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 Diameter QoS specific AVPs. Figure 2 shows the DER 156 message used with the Diameter QoS 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 Diameter QoS specific AVPs. Figure 3 shows the DEA 188 message used with the Diameter QoS 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 Diameter QoS specific AVPs. Figure 4 shows the CCR 218 message used with the Diameter QoS 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 Diameter QoS specific AVPs. Figure 5 shows the CCA 252 message used with the Diameter QoS 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 Diameter QoS specific AVPs. Figure 6 shows the AAR 287 message used with the Diameter QoS 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 Diameter QoS specific AVPs. Figure 7 shows the AAA 318 message used with the Diameter QoS 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-Flow-State TBD 4.2 Enumerated | |M,P| | V | 349 |QSPEC TBD 4.3 OctetSTring| |M,P| | V | 350 |QoS-ID TBD 4.1 Unsigned32 | |M,P| | V | 351 |Extended-QoS-Filter-Rule TBD 4.6 Grouped | |M,P| | V | 352 |QoS-Resources TBD 4.4 Grouped | |M,P| | V | 353 |QoS-Parameter TBD 4.5 Grouped | |M,P| | V | 354 |QoS-Capability TBD 4.7 Grouped | |M,P| | V | 355 |QSPEC-Type TBD 4.8 Unsigned32 | |M,P| | V | 356 +-------------------------------------------------+----+---+----+----+ 358 4.1. QoS-ID AVP 360 The QoS-ID AVP (AVP Code TBD) is of type Unsigned32 and references 361 the QSPEC. 363 4.2. QoS-Flow-State AVP 365 The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It 366 gives an indication as to how the flow MUST be treated. The 367 Extended-QoS-Filter-Rule already provides an indicate whether a flow 368 is permitted or denied. This optional AVP provides additional 369 information about the treatment. Currently a single value is 370 defined; further values are available via IANA registration. 372 0 Pending: The filter rules are not installed but kept pending. 373 Subsequent signaling is necessary to active them. 375 4.3. QSPEC AVP 377 The QSPEC AVP (AVP Code TBD) is of type OctetString and contains 378 Quality of Service parameters. These parameters are defined in a 379 separate document, see [I-D.ietf-dime-qos-parameters]. 381 4.4. QoS-Resources AVP 383 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes 384 description of the resources that have been authorized or requested. 385 More than one QoS-Resources AVP MAY be included in a single message. 387 QoS-Resources ::= < AVP Header: XXX > 388 1* [ Extended-QoS-Filter-Rule ] 389 1* [ QoS-Parameter ] 390 [ QoS-Flow-State ] 391 * [ AVP ] 393 4.5. QoS-Parameter AVP 395 The QoS-Parameter AVP (AVP Code TBD) is of type Grouped and ties the 396 QoS-ID AVP together to the QSPEC AVP. All parameters followed by the 397 QSPEC-Type AVP refer to the same QoS model/profile. 399 QoS-Parameter ::= < AVP Header: XXX > 400 { QoS-ID } 401 { QSPEC-Type } 402 1* [ QSPEC ] 403 * [ AVP ] 405 4.6. Extended-QoS-Filter-Rule AVP 407 TheExtended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped. 408 The QoS filter rule associated with the QoS-ID re-uses the RADIUS 409 NAS-Traffic-Rule AVP [I-D.ietf-radext-filter-rules]. This AVP ties a 410 specific filter to a QoS-ID that in turn refers to a specific QoS- 411 Parameter. 413 Extended-QoS-Filter-Rule ::= < AVP Header: XXX > 414 { QoS-ID } 415 { NAS-Traffic-Rule } 416 * [ AVP ] 418 4.7. QoS-Capability AVP 420 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 421 a list of supported QSPEC-Types and respective AVPs. 423 The NAS SHOULD include this AVP from the NAS to the Diameter server 424 to indicate the support for this specification and for the specific 425 QoS models. 427 QoS-Capability ::= < AVP Header: XXX > 428 1* { QSPEC-Type } 429 * [ AVP ] 431 4.8. QSPEC-Type AVP 433 The QSPEC-Type AVP (AVP Code TBD) is of type Unsigned32 and contains 434 the supported QoS model or QoS profile. The value of 0 refers to the 435 QoS parameters described in [I-D.ietf-dime-qos-parameters]. The 436 values are taken from the registry defined in [I-D.ietf-nsis-qspec]. 438 5. Examples 440 This section shows a number of signaling flows where QoS negotiation 441 and authorization is part of the conventional NASREQ, EAP or Credit- 442 Control applications message exchanges. These signaling flows are 443 meant to be examples only. 445 5.1. Diameter EAP with QoS Information 447 Figure 8 shows a simple signaling flow where a NAS (Diameter Client) 448 announces its QoS awareness and capabilities included into the DER 449 message and as part of the access authentication procedure. Upon 450 completion of the EAP negotiation, the Diameter Server provides a 451 pre-provisioned QoS profile to the NAS in the final DEA message. 453 End Diameter Diameter 454 Host Client server 455 | | | 456 | (initiate EAP) | | 457 |<------------------------------>| | 458 | | Diameter-EAP-Request | 459 | | EAP-Payload(EAP Start) | 460 | | QoS-Capability | 461 | |------------------------------->| 462 | | | 463 | | Diameter-EAP-Answer | 464 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 465 | | EAP-Payload(EAP Request #1) | 466 | |<-------------------------------| 467 | EAP Request(Identity) | | 468 |<-------------------------------| | 469 : : : 470 : <<>> : 471 : : : 472 | | | 473 | EAP Response #N | | 474 |------------------------------->| | 475 | | Diameter-EAP-Request | 476 | | EAP-Payload(EAP Response #N) | 477 | |------------------------------->| 478 | | | 479 | | Diameter-EAP-Answer | 480 | | Result-Code=DIAMETER_SUCCESS | 481 | | EAP-Payload(EAP Success) | 482 | | [EAP-Master-Session-Key] | 483 | | (authorization AVPs) | 484 | | QoS-Resources | 485 | |<-------------------------------| 486 | | | 487 | EAP Success | | 488 |<-------------------------------| | 489 | | | 491 Figure 8: Example of a Diameter EAP enhanced with QoS Information 493 5.2. QoS Authorization 495 Figure 9 shows an example of authorization only QoS signaling as part 496 of the NASREQ message exchange. The NAS provides the Diameter Server 497 with the QoS profile it wishes to use in the AAR message. The 498 Diameter Server then either authorizes the proposed QoS profile or 499 reject the authorization, and then informs the NAS about the 500 authorization result in the AAA message. In this scenario the NAS 501 does not need to include the QoS-Capability AVP in the AAR message as 502 the QoS-Resources AVP implicitly does the same and also the NAS is 503 authorizing a specific QoS profile, not a pre-provisioned one. 505 End Diameter 506 Host NAS Server 507 | | | 508 | | | 509 | QoS Request | | 510 +----------------->| | 511 | | | 512 | |AA-Request | 513 | |Auth-Request-Type=AUTHORIZE_ONLY 514 | |NASREQ-Payload | 515 | |QoS-Resources | 516 | +----------------------------->| 517 | | | 518 | | AA-Answer| 519 | | NASREQ-Payload(Success)| 520 | | QoS-Resources| 521 | |<-----------------------------+ 522 | Accept | | 523 |<-----------------+ | 524 | | | 525 | | | 526 | | | 528 Figure 9: Example of an Authorization-Only Message Flow 530 5.3. Diameter NASREQ with QoS Information 532 Figure 10 shows a similar pre-provisioned QoS signaling as in 533 Figure 8 but using the NASREQ application instead of EAP application. 535 End Diameter 536 Host NAS Server 537 | | | 538 | Start Network | | 539 | Attachment | | 540 |<---------------->| | 541 | | | 542 | |AA-Request | 543 | |NASREQ-Payload | 544 | |QoS-Capability | 545 | +----------------------------->| 546 | | | 547 | | AA-Answer| 548 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 549 | NASREQ-Payload(NASREQ Request #1)| 550 | |<-----------------------------+ 551 | | | 552 | Request | | 553 |<-----------------+ | 554 | | | 555 : : : 556 : <<>> : 557 : : : 558 | Response #N | | 559 +----------------->| | 560 | | | 561 | |AA-Request | 562 | |NASREQ-Payload ( Response #N )| 563 | +----------------------------->| 564 | | | 565 | | AA-Answer| 566 | | Result-Code=DIAMETER_SUCCESS| 567 | | (authorization AVPs)| 568 | | QoS-Resources | 569 | |<-----------------------------+ 570 | | | 571 | Success | | 572 |<-----------------+ | 573 | | | 575 Figure 10: Example of a Diameter NASREQ enhanced with QoS Information 577 5.4. Diameter Server Initiated Re-authorization of QoS 579 Figure 11 shows a message exchange for a Diameter Server initiated 580 QoS profile re-authorization procedure. The Diameter Server sends 581 the NAS a RAR message requesting re-authorization for an existing 582 session and the NAS acknowledges it with a RAA message. The NAS that 583 is aware of its existing QoS profile and information for the ongoing 584 session that the Diameter Server requested for re-authorization. 585 Thus the NAS must initiate re-authorization of the existing QoS 586 profile. The re-authorization procedure is the same as in Figure 9. 588 End Diameter 589 Host NAS Server 590 | | | 591 | | | 592 : : : 593 : <<>> : 594 : : : 595 | | | 596 | | RA-Request | 597 | |<-----------------------------+ 598 | | | 599 | |RA-Answer | 600 | |Result-Code=DIAMETER_SUCCESS | 601 | +----------------------------->| 602 | | | 603 | | | 604 | |AA-Request | 605 | |NASREQ-Payload | 606 | |Auth-Request-Type=AUTHORIZE_ONLY 607 | |QoS-Capability | 608 | +----------------------------->| 609 | | | 610 | | AA-Answer| 611 | | Result-Code=DIAMETER_SUCCESS| 612 | | (authorization AVPs)| 613 | | QoS-Resources | 614 | |<-----------------------------+ 615 | | | 617 Figure 11: Example of a Server-initiated Re-Authorization Procedure 619 5.5. Diameter Credit-Control with QoS Information 621 In this case the authorization and authentication take place at the 622 beginning and then when a new service request comes in the accounting 623 is done as per the required QoS. It's a 3GPP scenario. 625 Diameter 626 End User Service Element Server CC Server 627 (CC Client) 628 | Registration | AA request/answer(accounting,cc or both)| 629 |<----------------->|<------------------>| | 630 | : | | | 631 | : | | | 632 | Service Request | | | 633 |------------------>| | | 634 | | CCR(Initial,Credit-Control AVPs, | 635 | | QoS-capability) | 636 | +|---------------------------------------->| 637 | CC stream|| | CCA(Granted-Units)| 638 | || | QoS-Resources | 639 | +|<----------------------------------------| 640 | Service Delivery | | | 641 |<----------------->| ACR(start,Accounting AVPs) | 642 | : |------------------->|+ | 643 | : | ACA || Accounting stream | 644 | |<-------------------|+ | 645 | : | | | 646 | : | | | 647 | | CCR(Update,Used-Units) | 648 | |---------------------------------------->| 649 | | | CCA(Granted-Units)| 650 | | | QoS-Resources | 651 | |<----------------------------------------| 652 | : | | | 653 | : | | | 654 | End of Service | | | 655 |------------------>| CCR(Termination, Used-Units) | 656 | |---------------------------------------->| 657 | | | CCA | 658 | |<----------------------------------------| 659 | | ACR(stop) | | 660 | |------------------->| | 661 | | ACA | | 662 | |<-------------------| | 664 Figure 12: Example with first interrogation after user's 665 authorization/authentication 667 5.6. Diameter Server Initiated Credit Re-authorization 669 This example shows a Diameter Credit Control interaction whereby the 670 server initiates a re-authorization exchange. 672 Service Element Diameter 673 End User (CC Client) Server CC Server 674 | | | | 675 | | | | 676 : : : : 677 : <<<<<< Initial Message Exchanges >>>>>> : 678 : : : : 679 | | | | 680 | | Re-Auth-Request| 681 | | Auth-Application-ID = CREDIT_CONTROL| 682 | |Re-Auth-Request-Type = AUTHORIZE_ONLY| 683 | | Session-ID| 684 | |<------------------------------------+ 685 | | | | 686 | | Re-Auth-Answer | | 687 | | Session-ID | | 688 | | Result-Code = DIAMETER_LIMITED_SUCCESS 689 | +------------------------------------>| 690 | | | | 691 | | CCR | 692 | | CC-Request-Type = UPDATE_REQUEST | 693 | | Used-Units | | 694 | |-------------------+---------------->| 695 | | CCA(Granted-Units)| 696 | | Result-Code = DIAMETER_SUCCESS| 697 | | QoS-Resources| 698 | |<------------------+-----------------| 699 | | | | 701 Figure 13: Server-Initiated Credit Re-Authorization 703 5.7. QoS and Credit-Control as Part of Authentication and Authorization 705 In this example, the Credit control is performed along with the 706 Authentication/Authorization message. This is usually the case in 707 NAS scenario. 709 Service Element Diameter 710 End User (CC Client) server CC Server 711 | (e.g. NAS) | | 712 | | | | 713 | Service Request | AA Request (CC AVPs) | 714 | | Credit-Control=CREDIT_AUTHORIZATION | 715 | | QoS-Resources | | 716 |------------------>|------------------->| | 717 | | | CCR(Initial, CC AVPs) 718 | | | QoS-Resources | 719 | | |------------------->| 720 | | | CCA(Granted-Units) | 721 | | | QoS-Resources | 722 | | |<-------------------| 723 | | AA Answer(Granted-Units) | 724 | | QoS-Resources | | 725 | Service Delivery |<-------------------| | 726 |<----------------->| | | 727 | | ACR(start,Accounting AVPs) | 728 | |------------------->|+ | 729 | | ACA || Accounting stream | 730 | |<-------------------|+ | 731 | | | | 732 | | | | 733 | | | | 734 | | | | 735 | | CCR(Update,Used-Units) | 736 | | QoS-Resources | CCR(Update,Used-Units) 737 | |------------------->| QoS-Resources | 738 | | |------------------->| 739 | | | CCA(Granted-Units) | 740 | | | QoS-Resources | 741 | | CCA(Granted-Units) |<-------------------| 742 | | QoS-Resources | | 743 | |<-------------------| | 744 | | | | 745 | | | | 746 | End of Service | | | 747 |------------------>| CCR(Termination,Used-Units) | 748 | |------------------->| CCR(Term.,Used-Units) 749 | | |------------------->| 750 | | | CCA | 751 | | CCA |<-------------------| 752 | |<-------------------| | 753 | | ACR(stop) | | 754 | |------------------->| | 755 | | ACA | | 756 | |<-------------------| | 758 Figure 14: Example with use of the authorization messages for the 759 first Diameter Credit Control interrogation 761 6. AVP Occurrence Tables 763 6.1. DER and DEA Commands AVP Table 765 The following table lists the Quality of Service specific AVPs 766 defined in this document that may be present in the DER and DEA 767 Commands, as defined in this document and in [RFC4072]. 769 +---------------+ 770 | Command-Code | 771 |-------+-------+ 772 Attribute Name | DER | DEA | 773 -------------------------------+-------+-------+ 774 QoS-Capability | 0-1 | 0 | 775 QoS-Resources | 0+ | 0+ | 776 +-------+-------+ 778 Figure 15: DER and DEA Commands AVP table 780 6.2. CCR and CCA Commands AVP Table 782 The following table lists the Quality of Service specific AVPs 783 defined in this document that may be present in the CCR and CCA 784 Commands, as defined in this document and in [RFC4006]. 786 +---------------+ 787 | Command-Code | 788 |-------+-------+ 789 Attribute Name | CCR | CCA | 790 -------------------------------+-------+-------+ 791 QoS-Capability | 0-1 | 0 | 792 QoS-Resources | 0+ | 0+ | 793 +-------+-------+ 795 Figure 16: CCR and CCA Commands AVP table 797 6.3. AAR and AAA Commands AVP Table 799 The following table lists the Quality of Service specific AVPs 800 defined in this document that may be present in the AAR and AAA 801 Commands, as defined in this document and in [RFC4005]. 803 +---------------+ 804 | Command-Code | 805 |-------+-------+ 806 Attribute Name | AAR | AAA | 807 -------------------------------+-------+-------+ 808 QoS-Capability | 0-1 | 0 | 809 QoS-Resources | 0+ | 0+ | 810 +-------+-------+ 812 Figure 17: AAR and AAA Commands AVP table 814 7. Diameter RADIUS Interoperability 816 [Editor's Note: Text will be provided in a future version of this 817 document.] 819 8. Acknowledgments 821 We would like to thank Victor Fajardo for his comments. 823 9. IANA Considerations 825 Diameter reserves the AVP Codes 0 - 255 for RADIUS functions that are 826 implemented in Diameter. AVPs new to Diameter have code values of 827 256 and greater. 829 This specification assigns the values TBD-1 to TBD-2 from the AVP 830 Code namespace defined in RFC 3588 [RFC3588]. See Section 4 for the 831 newly defined AVPs. 833 This specification also specifies the use of AVPs in the 0 - 255 834 range, which are defined in 'RADIUS Types', see 835 http://www.iana.org/assignments/radius-types. These values are 836 assigned by the policy in Section 6 of RFC 2865 [RFC2865] and are 837 amended by RFC 3575 [RFC3575]. 839 10. Security Considerations 841 This document describes the extension of Diameter for conveying 842 Quality of Service information. The security considerations of the 843 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 844 Use of the AVPs defined in this document MUST take into consideration 845 the security issues and requirements of the Diameter Base protocol. 847 11. References 849 11.1. Normative References 851 [I-D.ietf-dime-qos-parameters] 852 Korhonen, J. and H. Tschofenig, "Quality of Service 853 Parameters for Usage with the AAA Framework", 854 draft-ietf-dime-qos-parameters-00 (work in progress), 855 June 2007. 857 [I-D.ietf-radext-filter-rules] 858 Congdon, P., "RADIUS Attributes for Filtering and 859 Redirection", draft-ietf-radext-filter-rules-03 (work in 860 progress), July 2007. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 866 Authentication Dial In User Service)", RFC 3575, 867 July 2003. 869 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 870 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 872 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 873 "Diameter Network Access Server Application", RFC 4005, 874 August 2005. 876 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 877 Loughney, "Diameter Credit-Control Application", RFC 4006, 878 August 2005. 880 11.2. Informative References 882 [I-D.ietf-nsis-qspec] 883 Ash, J., "QoS NSLP QSPEC Template", 884 draft-ietf-nsis-qspec-17 (work in progress), July 2007. 886 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 887 "Remote Authentication Dial In User Service (RADIUS)", 888 RFC 2865, June 2000. 890 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 891 Authentication Protocol (EAP) Application", RFC 4072, 892 August 2005. 894 Authors' Addresses 896 Jouni Korhonen (editor) 897 TeliaSonera 898 Teollisuuskatu 13 899 Sonera FIN-00051 900 Finland 902 Email: jouni.korhonen@teliasonera.com 904 Hannes Tschofenig 905 Nokia Siemens Networks 906 Otto-Hahn-Ring 6 907 Munich, Bavaria 81739 908 Germany 910 Email: Hannes.Tschofenig@nsn.com 911 URI: http://www.tschofenig.com 913 Mayutan Arumaithurai 914 University of Goettingen 916 Email: mayutan.arumaithurai@gmail.com 918 Full Copyright Statement 920 Copyright (C) The IETF Trust (2007). 922 This document is subject to the rights, licenses and restrictions 923 contained in BCP 78, and except as set forth therein, the authors 924 retain all their rights. 926 This document and the information contained herein are provided on an 927 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 928 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 929 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 930 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 931 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 932 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 934 Intellectual Property 936 The IETF takes no position regarding the validity or scope of any 937 Intellectual Property Rights or other rights that might be claimed to 938 pertain to the implementation or use of the technology described in 939 this document or the extent to which any license under such rights 940 might or might not be available; nor does it represent that it has 941 made any independent effort to identify any such rights. Information 942 on the procedures with respect to rights in RFC documents can be 943 found in BCP 78 and BCP 79. 945 Copies of IPR disclosures made to the IETF Secretariat and any 946 assurances of licenses to be made available, or the result of an 947 attempt made to obtain a general license or permission for the use of 948 such proprietary rights by implementers or users of this 949 specification can be obtained from the IETF on-line IPR repository at 950 http://www.ietf.org/ipr. 952 The IETF invites any interested party to bring to its attention any 953 copyrights, patents or patent applications, or other proprietary 954 rights that may cover technology that may be required to implement 955 this standard. Please address the information to the IETF at 956 ietf-ipr@ietf.org. 958 Acknowledgment 960 Funding for the RFC Editor function is provided by the IETF 961 Administrative Support Activity (IASA).