idnits 2.17.00 (12 Aug 2021) /tmp/idnits27640/draft-tschofenig-radext-qos-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 945. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 18, 2005) is 6150 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) -- Looks like a reference, but probably isn't: 'MTU' on line 467 -- Looks like a reference, but probably isn't: 'TBD' on line 594 == Unused Reference: '11' is defined on line 861, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '3') ** Obsolete normative reference: RFC 3576 (ref. '4') (Obsoleted by RFC 5176) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 4080 (ref. '10') ** Obsolete normative reference: RFC 3588 (ref. '11') (Obsoleted by RFC 6733) == Outdated reference: A later version (-05) exists of draft-alfano-aaa-qosprot-02 == Outdated reference: A later version (-22) exists of draft-lior-radius-prepaid-extensions-07 == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS EXTensions (radext) H. Tschofenig 3 Internet-Draft Siemens 4 Expires: January 19, 2006 A. Mankin 5 Shinkuro, Inc 6 T. Tsenov 7 Siemens 8 A. Lior 9 Bridgewater Systems 10 July 18, 2005 12 RADIUS Quality of Service Support 13 draft-tschofenig-radext-qos-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 19, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document describes an extension to the RADIUS protocol that 47 performs authentication, authorization, and accounting for Quality- 48 of-Service reservations. 50 The described extensions allow network elements to authenticate the 51 initiator of a reservation request (if desired), to ensure that the 52 reservation is authorized, and to account for established QoS 53 resources. 55 Flexibility is provided by offering support for different 56 authorization models and by decoupling specific QoS attributes 57 carried in the QoS signaling protocol from the AAA protocol. This 58 document is the RADIUS complement to the DIAMETER QoS application. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. RADIUS functional considerations . . . . . . . . . . . . . . . 6 66 5. Authorization and QoS parameter provision . . . . . . . . . . 7 67 5.1 QoS enabled initial access authentication and 68 authorization . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2 Mid-Session QoS authorization . . . . . . . . . . . . . . 8 70 5.2.1 Client-side initiated QoS 71 authorization/re-authorization . . . . . . . . . . . . 8 72 5.2.2 Server-side initiated Re-Authorization . . . . . . . . 8 73 5.3 Session Termination . . . . . . . . . . . . . . . . . . . 9 74 5.3.1 Client-side initiated session termination . . . . . . 9 75 5.3.2 Server-side initiated session termination . . . . . . 9 76 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1 QSPEC Attribute . . . . . . . . . . . . . . . . . . . . . 11 79 7.2 Flow Identification . . . . . . . . . . . . . . . . . . . 16 80 7.3 Authorization Objects . . . . . . . . . . . . . . . . . . 17 81 8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 18 82 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.1 RADIUS authorization of a QoS signaling reservation 84 request . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.2 RADIUS authentication, authorization and management of 86 a QoS-enabled access session . . . . . . . . . . . . . . . 21 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 88 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 12.1 Normative References . . . . . . . . . . . . . . . . . . . 26 91 12.2 Informative References . . . . . . . . . . . . . . . . . . 26 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 93 Intellectual Property and Copyright Statements . . . . . . . . 29 95 1. Introduction 97 To meet the quality-of-service needs of applications such as voice- 98 over-IP, it will often be necessary to explicitly request resources 99 from the network. This will allow the network to identify packets 100 belonging to these application flows and ensure that bandwidth, 101 delay, and error rate requirements are met. 103 This document is a complement to the ongoing work of the DIAMETER QoS 104 application described in [12]. It describes RADIUS protocol 105 extensions supporting AAA in an environment where better than best 106 effort Quality of Service is desired. The suggested extensions to 107 the RFC 2865 [1], RFC 2866 [2], RFC 2869 [3] and RFC 3576 [4] satisfy 108 the requirements defined in [13]. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC-2119 [5]. 116 3. Goals 118 This document has a few ambitious, namely: 120 o Decouple the QoS signaling protocol (such as NSIS, RSVP or link 121 layer QoS signaling protocols) from the AAA protocol. This goal 122 is accomplished with the help of a generic QoS description, the 123 QSPEC object. 125 o Support for different scenarios that demand authorization for QoS 126 reservations. The impact is to provide flexibility with regard to 127 the entities that trigger the QoS reservation, the QoS parameters 128 that need to be provided to the RADIUS server for authorization, 129 the granularity of the QoS reservation (e.g., for an individual 130 application flow, for an aggregate). 132 4. RADIUS functional considerations 134 Being a value-added service, QoS provisioning SHOULD go along with 135 explicit authorization, accounting and control over the QoS-featured 136 user session. Specifically, the management of the authorized session 137 with Session-Timeout(27) and Termination-Action(29) attributes raises 138 a number of issues, identified in [14]. The solution presented in 139 this document aims to allow explicit control by the RADIUS server 140 (Authorizing entity) over the authorization session and its 141 parameters. In addition, it aims to support flexible deployment 142 scenarios of QoS authorization and parameter provisioning by 143 Authorization entities, which know the user and its subscription 144 profile (Home AAA server) or can provide authorization for a session 145 requested by the user (Application server). QoS authorization and 146 parameter provisioning MAY be incorporated into initial 147 authentication and authorization RADIUS exchange or MAY be triggered 148 at a later moment by a reception of a QoS signalling message. 150 5. Authorization and QoS parameter provision 152 5.1 QoS enabled initial access authentication and authorization 154 QoS enabled RADIUS client (NAS) initiates the authentication and 155 authorization process by sending a RADIUS Access-Request to the 156 user's Home AAA server. In addition to authentication related 157 attributes, it includes the QSPEC(TBD) attribute, which MAY specify 158 the QoS-Model [15] supported by the NAS and description of the 159 currently available QoS resources or description of the QoS 160 explicitly requested by the user. In the second case, additional 161 session and flow identification information MIGHT be included 162 together with the identity of the QoS authorizing application server. 164 If the authentication process involves multiple Access-Requests (as 165 in EAP), the RADIUS client MUST include the QSPEC(TBD) attribute and 166 any additional QoS-authorization related information in at least the 167 last Access-Request of the authentication process. 169 The Home AAA server receives the Access-Request message and 170 authenticates the user. Based on the user profile it determines the 171 subscription QoS parameters and includes them into the QSPEC(TBD) 172 attribute of the Access-Accept message. 174 In case that the QoS authorization MUST be done by an Application 175 server, which identity is included into the Access-Request message, 176 the Home server forwards the Access-Request to the Application 177 server. The Access-Request will contain the QSPEC(TBD) attribute and 178 session identification information. Upon successful authorization, 179 the Application server generates an Access-Accept containing the 180 QSPEC(TBD) attribute, flow identification information and optionally 181 bearer gating information. 183 The QSPEC attribute returned to the client SHOULD contain the 184 duration of the QoS enabled session. 186 If the authentication or authorization of the user is not successful, 187 the Home AAA server or the application server sends back an Access- 188 Reject message containing Reply-Message(18) attribute with the reason 189 for rejection. 191 When the QoS authorization exchange completes successfully, a RADIUS 192 Accounting session SHOULD start for reporting accounting information. 193 Accounting information is reported as described in [2] and [3]. Loss 194 of bearer information is reported using Access-Request message as 195 specified in the following section. 197 5.2 Mid-Session QoS authorization 199 5.2.1 Client-side initiated QoS authorization/re-authorization 201 Two types of QoS-related events MIGHT initiate Authorize-Only Access- 202 Request messages - reception of a QoS signaling message or expiration 203 of authorization lifetime of ongoing QoS-enabled session. In both 204 cases, the RADIUS client sends an Access-Request with Service-Type(6) 205 attribute set to a value of "Authorize-Only", QSPEC(TBD) attribute 206 and session and flow identification information. The QSPEC(TBD) 207 attribute includes description of new QoS parameters explicitly 208 required by the user or the QoS parameters that SHOULD be re- 209 authorized. Session and flow (only in the re-authorization case) 210 identification information SHOULD be the same as those used during 211 the initial Access-Request. For example, if the User-Name(1) 212 attribute was used in the initial Access-Request it MUST be included, 213 especially if the User-Name(1) attribute is used to route the Access- 214 Request to the Home RADIUS server. 216 The "Authorize-ONLY" Access-Request MUST NOT include either User 217 Password(2) or a CHAP Password(3). In order to protect the RADIUS 218 message, the RADIUS client MUST include the Message-Authenticator(80) 219 attribute. The RADIUS client will compute the value for the Message- 220 Authenticator(80) based on [3]. 222 The RADIUS server processes the information, including the 223 verification of the Message-Authenticator(80) as per [3], and upon 224 successful authorization it responds with a RADIUS Access-Accept 225 message. It contains the Service-Type(6) attribute with value 226 "Authorize-ONLY", the QSPEC(TBD) attribute, flow identification 227 information and optionally bearer gating information. The QSPEC(TBD) 228 attribute returned to the client SHOULD contain the new duration of 229 the QoS enabled session. In case of unsuccessful authorization an 230 Access-Reject message is sent, containing the Reply-Message(18) 231 attribute with the reason of rejection. 233 In case that an Application server MUST be contacted for the QoS 234 authorization, the Home server forwards the Access-Request to the 235 indicated Application server, which processes the QoS authorization 236 request. 238 5.2.2 Server-side initiated Re-Authorization 240 In order to take advantage of the dynamic authorization capabilities 241 of RADIUS as defined in [4], the Authorization entity (Home or 242 Application server) MUST be sure that the RADIUS client supports them 243 too. An advertising approach proposed in [14] MIGHT be used.(TBD) 244 At any time during the QoS session the RADIUS server MAY send a 245 Change-of-Authorization (CoA) message with Service-Type(6) attribute 246 set to value "Authorize-ONLY" and session and flow identification 247 information. The RADIUS client MUST respond with a Change-of- 248 Authorization NACK message with Service-Type(6) attribute with value 249 "Authorize-ONLY" and Error-Cause(101) attribute set to value 250 "Request-Initiated". The RADIUS client MUST then send an Access- 251 Request containing Service-Type(6) attribute with value "Authorize- 252 ONLY", QSPEC(TBD) attribute, session and flow identification 253 information. This approach is compatible with the DIAMETER re- 254 authorization procedure and is defined in RFC 3576 [4]. Furthermore, 255 the "State" attribute SHOULD be used as specified in RFC 3576 [4]. 257 5.3 Session Termination 259 5.3.1 Client-side initiated session termination 261 Service session MAY be related to a particular authorized QoS- 262 provisioned data flow. In this case, session termination MAY be 263 caused by a QoS signaling tear down message or loss of bearer report. 264 In another scenario the service session is a QoS enabled access 265 session, which can handle authorization of several QoS-provisioned 266 user's data flows. In this case session termination MAY be caused by 267 user log-off. 269 A RADIUS client indicates session termination by sending an 270 Accounting-Request message with Acc-Status-Type(40) attribute set to 271 "Stop" value and final QoS related accounting records(TBD). 273 5.3.2 Server-side initiated session termination 275 At anytime during a session the Authorizing Server may send a 276 Disconnect message to terminate the session. This capability is 277 described in detail in RFC 3576 [4]. The RADIUS server sends a 278 Disconnect message that MUST contain identifiers that uniquely 279 determine the subscriber's session and the RADIUS client serving that 280 session and Service-Type(6) attribute with value "Authorize-ONLY". 282 If the RADIUS client receives a Disconnect message, it MUST respond 283 with the Disconnect-NACK message with Service-Type(6) attribute with 284 value "Authorize-ONLY" and Error-Cause(101) attribute with value 285 "Request-Initiated". If it is able to terminate the session it will 286 send Access-Request message with Service-Type(6) attribute with value 287 "Authorize-ONLY" and attributes for session termination. This 288 message flow is required for compatibility with DIAMETER protocol. 289 Also the State(24) attribute SHOULD be used as specified in RFC 3576 290 [4]. 292 6. Accounting 294 Application of the RADIUS protocol for QoS authorization presented in 295 this document use RADIUS Accounting as defined in the RFC2865 [1], 296 RFC2866 [2] and RFC2869 [3]. The definition of new accounting 297 attributes may be necessary but left for further study. 299 After a successful QoS authorization the RADIUS client starts the 300 corresponding accounting session by sending the Accounting-Request 301 message. This message SHOULD contain necessary attributes to bind 302 the current accounting session to the reported QoS session. 303 Class(25) and Acc-Session-ID(44) attributes SHOULD be used according 304 to [1] and [2]. The RADIUS server responds with an Accounting- 305 Response message after successfully processing the Accounting-Request 306 message. The Accounting-Response message MAY contain instructions 307 for managing the accounting session, such as the Acct-Interim- 308 Interval(85) attribute. 310 After every successful re-authorization procedure the RADIUS client 311 SHOULD re-initiate accounting message exchange. 313 For indication of session termination the RADIUS client SHOULD 314 initiate a final exchange of accounting messages with the RADIUS 315 server. 317 7. Attributes 319 This section defines three categories of attributes: 321 o QSPEC parameters describing requested/authorized QoS 323 o Identification of the flow that should receive QoS described in 324 QSPEC 326 o Attributes required to carry authorization information (e.g., 327 authorization tokens as specified in [6]) 329 7.1 QSPEC Attribute 331 The generic QoS description is taken from QoS-NSLP QSpec Template 332 [15] which aims to support QoS parameters for all QoS reservations 333 and is independent of a specific QoS model (QOSM). The QSPEC 334 template format is organized into QoS Control information, Requested, 335 Reserved, Available and Minimun objects. Each of the objects 336 contains a number of QSPEC parameters. For QoS authorization 337 purposes only part of the parameters SHOULD be used, e.g., mainly 338 those included into the QoS Desired and some of those included into 339 QoS Control information objects. In addition information for 340 duration of the authorized QoS SHOULD be provided. 342 QSPEC parameters and QoS authorization session management parameters 343 are included as subtypes into the QSPEC attribute. Subtypes not used 344 are omitted in the message. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | QoSM ID | SUB-TYPE 2 | LENGTH | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Excess Treatment | SUB-TYPE 3 | LENGTH | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Bandwidth | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | SUB-TYPE 4 | LENGTH | Token Bucket Rate [r] | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Token Bucket Rate [r] | SUB-TYPE 5 | LENGTH | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Token Bucket Size [b] | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | SUB-TYPE 6 | LENGTH | Peak Data Rate [p] | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Peak Data Rate [p] | SUB-TYPE 7 | LENGTH | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Minimum Policed Unit [m] | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | SUB-TYPE 8 | LENGTH | Maximum Packet Size [MTU] | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Maximum Packet Size [MTU] | SUB-TYPE 9 | LENGTH | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | PHB Class | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | SUB-TYPE 10 | LENGTH |Y.1541 QoSClass| SUB-TYPE 11 | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | LENGTH |DSTE Class Type| SUB-TYPE 12 | LENGTH | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Preemption Priority | SUB-TYPE 13 | LENGTH | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Defending Priority | SUB-TYPE 14 | LENGTH | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Reservation Priority | SUB-TYPE 15 | LENGTH | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Authorization lifetime | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | SUB-TYPE 16 | LENGTH | Authorized Volume | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Authorized Volume | SUB-TYPE 17 | LENGTH | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Application Server ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Type: Value of QSPEC 396 Length: variable, greater than 8 398 String: The String value MUST be encoded as follows: 400 Sub-Type (=1): Sub-Type for QoS-Model ID attribute 402 Length : Length of QoS-Model ID attribute (= 6 octets) 404 QoS-Model ID (QoSM ID): 406 Identifier of the used QoS signaling model.[15] 408 Sub-Type (=2): Sub-Type for Excess Treatment attribute 410 Length : Length of Excess Treatment attribute (= 3 octets) 412 Excess Treatment: 414 Description of how the excess traffic to be processed (out-of- 415 profile traffic). Excess traffic MAY be dropped, shaped and/or 416 remarked. 418 Sub-Type (=3): Sub-Type for Bandwidth attribute 420 Length : Length of Bandwidth attribute (= 6 octets) 422 Bandwidth: 424 Link bandwidth needed by a flow. 426 Sub-Type (=4): Sub-Type for Token Bucket Rate attribute 428 Length : Length of Token Bucket Rate attribute (= 6 octets) 430 Token Bucket Rate: 432 Rate is a Token Bucket parameter as specified in [7]. 434 Sub-Type (=5): Sub-Type for Token Bucket Size attribute 436 Length : Length of Token Bucket Size attribute (= 6 octets) 438 Token Bucket Size: 440 Size is a Token Bucket parameter as specified in [7]. 442 Sub-Type (=6): Sub-Type for Peak Data Rate attribute 444 Length : Length of Peak Data Rate attribute (= 6 octets) 446 Token Bucket Size: 448 Peak Data Rate is a Token Bucket parameter as specified in [7]. 450 Sub-Type (=7): Sub-Type for Minimum Policed Unit attribute 452 Length : Length of Minimum Policed Unit attribute (= 6 453 octets) 455 Minimum Policed Unit: 457 Minimum Policed Unit is a Token Bucket parameter as specified in 458 [7]. 460 Sub-Type (=8): Sub-Type for Maximum Packet Size [MTU] attribute 462 Length : Length of Maximum Packet Size [MTU] attribute (= 6 463 octets) 465 Maximum Packet Size [MTU]: 467 Maximum Packet Size [MTU] is a Token Bucket parameter as specified 468 in [7]. 470 Sub-Type (=9): Sub-Type for PHB class attribute 472 Length : Length of PHB class attribute (= 6 octets) 474 PHB class: 476 Indicates the QoS class used in DiffServ per-hop behavior QoS 477 signaling [8]. 479 Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute 481 Length : Length of Y.1541 QoS class attribute (= 3 octets) 483 Y.1541 QoS class: 485 Indicates the Y.1541 QoS Class [16]. 487 Sub-Type (=11): Sub-Type for DSTE class attribute 489 Length : Length of DSTE class attribute (= 3 octets) 491 DSTE Class: 493 Indicates the QoS class used in DiffServ-enabled MPLS traffic 494 engineering.[9]. 496 Sub-Type (=12): Sub-Type for Preemption Priority attribute 498 Length : Length of Preemption Priority attribute (= 4 octets) 500 Preemption Priority: 502 Parameter used in the process of differentiation of flows. 503 Indicates the priority of the new flow compared with the defending 504 priority of previously admitted flows. 506 Sub-Type (=13): Sub-Type for Defending Priority attribute 508 Length : Length of Defending Priority attribute (= 4 octets) 510 Defending Priority: 512 Parameter used in the process of differentiation of flows. It is 513 compared with the preemption priority of new flows. 515 Sub-Type (=14): Sub-Type for Reservation Priority attribute 517 Length : Length of Reservation Priority attribute (= 4 518 octets) 520 Reservation Priority: 522 Parameter used in the process of differentiation of flows for 523 emergency services, ETS, E911, etc., and assigning them a higher 524 admission priority. [Editor's Note: Reference to be included 525 here.] 527 Sub-Type (=15): Sub-Type for Authorization lifetime attribute 529 Length : Length of Authorization lifetime attribute (= 6 530 octets) 531 Authorization lifetime: 533 The parameter indicates the duration of the authorized QoS 534 provisioning. 536 Sub-Type (=16): Sub-Type for Authorized volume attribute 538 Length : Length of Authorized volume attribute (= 6 octets) 540 Authorized volume: 542 The parameter indicates the data volume that should receive the 543 authorized QoS. 545 Sub-Type (=17): Sub-Type for Application server ID attribute 547 Length : Length of Authorized volume attribute (IPv4 = 6 548 octets, IPv6= 18 octets) 550 Application server ID: 552 Application server ID indicates the address of the authorizing 553 Application Server. 555 Provided QSPEC parameters list is not exhaustive and SHOULD be 556 updated according to [15]. 558 7.2 Flow Identification 560 Depending on the deployment and used QoS signaling protocol, 561 identification of the flow that SHOULD received authorized QoS takes 562 a different format. Signaling session Identifier (NSIS) or flow 563 identifier and explicit filter specifications are used. The 564 Attribute QoS-Flow-ID is designated to encapsulate such information. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Signaling Session ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Type : Value of QoS-Flow-ID 576 Length: variable, greater than 8 578 String: The String value MUST be encoded as follows: 580 Sub-Type (=1): Signaling Session ID 582 Length : Length of Signaling Session ID attribute (= 6 583 octets) 585 Signaling Session ID: 587 In NSIS framework [10], Signaling session ID is an unique 588 identifier of the signaling session that remains unchanged for the 589 duration of the session. It is locally mapped to the specific 590 flow identifiers. 592 Additional Sub-Type attributes SHOULD be added, which combined with 593 filter specifications (such as QoS-Filter-Rule [17]) provide flow 594 identification. [TBD] 596 7.3 Authorization Objects 598 TBD: 600 8. Diameter RADIUS Interoperability 602 In deployments where RADIUS clients communicate with DIAMETER servers 603 or DIAMETER clients communicate with RADIUS servers then a 604 translation agent will be deployed and operate. The DIAMETER-QoS 605 specification [12] provides a natural candidate for mapping the 606 RADIUS QoS related AVPs to DIAMETER AVPs and messages. 608 9. Examples 610 The following diagrams show RADIUS protocol interactions for 611 different scenarios and deployment architectures. 613 9.1 RADIUS authorization of a QoS signaling reservation request 614 RADIUS RADIUS 615 Client Server 616 -----------> | | 617 QoS | Access-Request/UserID, QSPEC/ | 618 reservation |----------------------------------------------->| 619 request | | 620 | Access-Accept/QSPEC/ | 621 |<-----------------------------------------------| 622 | | 623 Start |Accounting-Request/Start, Acc-Session-ID.../ | 624 Accounting |----------------------------------------------->| 625 | Accounting-Response/...Acc-Interim-Period.../ | 626 |<-----------------------------------------------| 627 | | 628 Authorization| | 629 LifeTime | | 630 Expires: | | 631 Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ | 632 Authorization|----------------------------------------------->| 633 | Access-Accept/ Auth-ONLY, QSPEC/ | 634 |<-----------------------------------------------| 635 | Accounting-Request/Interim, Acc-Session-ID./ | 636 |----------------------------------------------->| 637 | Accounting-Response/...Acc-Interim-Period.../ | 638 |<-----------------------------------------------| 639 ..................... 640 | Session 641 | Termination 642 | initiated 643 | by 644 | server 645 | Disconnect-Request/Auth-ONLY, .../ <------ 646 |<-----------------------------------------------| 647 | Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ | 648 |----------------------------------------------->| 649 | Access-Request/Auth-ONLY,... | 650 | Acc-Terminate-Cause="Admin-Reset"/| 651 |----------------------------------------------->| 652 | Access-Accept | 653 |<-----------------------------------------------| 654 Accounting | Accounting-Request/Final,Acc-Session-ID./ | 655 end |----------------------------------------------->| 656 | Accounting-Response /Final,.../ | 657 |<-----------------------------------------------| 659 This example shows the protocol exchange between the RADIUS client 660 and the RADIUS server. An incoming QoS reservation request received 661 at the QoS policy aware node (i.e., RADIUS client) invokes the 662 transmission of a Access-Request message (AR) to the RADIUS server. 663 This message contains the requested QoS resources in a QSPEC 664 attribute along with user identification and authentication 665 information. After the request is successfully authenticated and 666 authorizated, the RADIUS server replies with a Access-Accept message 667 (AA), which grants a reservation for a certain amount of resources 668 (as included in the QSPEC attribute). After the successful exchange 669 of the AR/AA messages, the RADIUS client starts an accounting session 670 by sending an Accounting-Request message. The server replies with an 671 Accounting-Response message that MAY include instructions for further 672 handling of the accounting session, such as the Acc-Interim-Period 673 attribute. 675 The client-side re-authorization caused by expiration of the 676 authorization lifetime initiates an Authorize-ONLY Access-Request / 677 Access-Accept message exchange. After a successful re-authorization 678 an Accounting-Request message SHOULD be sent to indicate the new 679 authorization parameters. The server replies with an Accounting- 680 Response message. 682 In this example, the RADIUS server initiates a session termination. 683 It therefore sends a Disconnect-Request message. The client responds 684 with a Disconnect-NACK message and sends an AR message indicating the 685 termination cause. The server replies to the AR message with an AA 686 message. After receiving the AA message sent by the server, the 687 client sends remaining accounting information with the Accounting- 688 Request message. The server replies with the Accounting-Response 689 message. 691 9.2 RADIUS authentication, authorization and management of a QoS- 692 enabled access session 694 QoS enabled NAS Home 695 RADIUS client RADIUS server 696 | | 697 | Access-Request/....QSPEC(QoS Available) .../ | 698 v----------------------------------------------->| 699 * | 700 * Multiple | 701 Authentication *<==============================================>| 702 process * Access-Request/Access-Challenge Exchange | 703 * | 704 * | 705 Access granted; * Access-Accept/...QSPEC(user-profile QoS).../| 706 install QoS v<-----------------------------------------------| 707 | | 708 | Accounting-Request/...QSPEC(installed QoS)../ | 709 |----------------------------------------------->| 710 | Accounting-Response/.../ | 711 |<-----------------------------------------------| 712 | | 713 | | 714 QoS-Request | Access-Request/Auth-ONLY, QSPEC, QoS-Flow-ID/ | 715 --------------->|----------------------------------------------->| 716 | Access-Response/Auth-ONLY, QSPEC, QoS-Flow-ID/| 717 QoS authorized; *<-----------------------------------------------| 718 install QoS for | | 719 QoS-Flow-ID | | 720 | Accounting-Request/Interim,.../ | 721 |----------------------------------------------->| 722 | Accounting-Response/.../ | 723 |<-----------------------------------------------| 724 .............................................................. 725 | | 726 * | 727 QoS-Flow-ID authz.lifetime expires | 728 Delete QoS for QoS-Flow-ID | 729 | | 730 | Accounting-Request/Interim,.../ | 731 |----------------------------------------------->| 732 | Accounting-Response/.../ | 733 |<-----------------------------------------------| 734 .............................................................. 735 | | 736 | CoA-Request /Auth-ONLY,QSPEC.../ | 737 |<-----------------------------------------------| 738 | CoA-NACK/Auth-ONLY,"Request-Initiated"/ | 739 |----------------------------------------------->| 740 | Access-Request/Auth-ONLY,QSPEC.../ | 741 |----------------------------------------------->| 742 | Access-Accept/Auth-ONLY,QSPEC(New QoS).../ | 743 Install QoS *<-----------------------------------------------| 744 | | 745 | Accounting-Request/...QSPEC(installed QoS)../ | 746 |----------------------------------------------->| 747 | Accounting-Response/.../ | 748 |<-----------------------------------------------| 750 This example shows the interaction between a QoS enabled NAS and a 751 Home AAA server. This example aims to show a QoS-enabled access 752 session. The NAS performs authorization of the QoS-provisioned flows 753 as part of the user's access session. 755 The NAS performs initial authentication and authorization of the end 756 user for an access session. This process MAY take several Access- 757 Request / Access-Challenge message exchanges. By including the QSPEC 758 attribute, the RADIUS server provides a description of the QoS 759 parameters of the user access session. The NAS allocates certain QoS 760 resources according to the QoS parameters provided by the RADIUS 761 server and currently available QoS resources. The NAS initiates an 762 accounting session by sending the Accounting-Request message in which 763 it reports the actually allocated QoS resources for the access 764 session. The server replies with an Accounting-Response message that 765 MAY include instructions for further handling of the accounting 766 session, such as the Acc-Interim-Period attribute. 768 Later, when the NAS intercepts a QoS signaling message sent from the 769 end host an Authorize-ONLY Access-Request message is triggered and 770 sent to the RADIUS server. It includes the description of the 771 requested QoS resources in the QSPEC attribute. Optionally, an 772 identifier of the flow that should receive the requested QoS 773 treatment is included into the Access-Request message. The RADIUS 774 server (in the user's home domain) validates the QoS request and 775 replies with Authorize-ONLY Access-Accept message. The message 776 includes a QSPEC attribute with description of the authorized QoS 777 parameters and the duration of authorization. An identifier of the 778 flow that should receive the requested QoS is also provided. The 779 RADIUS client will install a QoS reservation based on the provided 780 QoS parameters for that flow and sends an Accounting-Request message 781 reporting the new QoS session. The server replies with an 782 Accounting-Response message. 784 In this example, the authorization lifetime of the QoS-provisioned 785 flow expires. The NAS releases the reserved QoS resources allocated 786 for the flow when the authorization has expired. In addition, the 787 NAS sends an Accounting-Request message to the RADIUS server, 788 indicating the stop of QoS provisioning for the flow. 790 If the Home AAA server decides to change QoS parameters for the 791 user's access session it sends an Authorize-ONLY Change-of- 792 Authorization-Request message to the RADIUS client, identifying the 793 affected access session. The NAS replies with a CoA-NACK message 794 indicating that an Access-Request has to be generated. The 795 Authorize-ONLY Access-Request message contains the QSPEC attribute 796 with the QoS resources currently available at the NAS. The RADIUS 797 server replies with the Authorize-ONLY Access-Accept message with a 798 QSPEC attribute containing the new QoS parameters that should be 799 provided to the user's session. The NAS allocates certain QoS 800 resources according to the QoS parameters provided by the RADIUS 801 server and the currently available QoS resources. It sends an 802 Accounting-Request message in which it reports the actual allocated 803 QoS resources for the access session. The server replies with an 804 Accounting-Response message. 806 10. Security Considerations 808 For this extension to RADIUS protocol the security considerations 809 defined in RFC2865 [1], RFC2866 [2], RFC2869 [3] and RFC3576 [4] are 810 applicable. Furthermore, the security of the QoS signaling protocol 811 and the QoS authorization framework must be considered in the 812 evaluation of the security properties. 814 [Editor's Note: A more detailed treatment will be provided in a 815 future document version.] 817 11. Acknowledgments 819 We would like to thank Pete McCann and Franck Alfano for their work 820 on the DIAMETER QoS application. 822 12. References 824 12.1 Normative References 826 [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 827 Authentication Dial In User Service (RADIUS)", RFC 2865, 828 June 2000. 830 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 832 [3] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 833 RFC 2869, June 2000. 835 [4] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 836 "Dynamic Authorization Extensions to Remote Authentication Dial 837 In User Service (RADIUS)", RFC 3576, July 2003. 839 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 840 Levels", March 1997. 842 [6] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 843 Authorization Policy Element", RFC 3520, April 2003. 845 [7] Shenker, S. and J. Wroclawski, "General Characterization 846 Parameters for Integrated Service Network Elements", RFC 2215, 847 September 1997. 849 [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 850 Weiss, "An Architecture for Differentiated Services", RFC 2475, 851 December 1998. 853 [9] Le Faucheur, F. and W. Lai, "Requirements for Support of 854 Differentiated Services-aware MPLS Traffic Engineering", 855 RFC 3564, July 2003. 857 [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 858 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 859 June 2005. 861 [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 862 "Diameter Base Protocol", RFC 3588, September 2003. 864 12.2 Informative References 866 [12] Alfano, F., "Diameter Quality of Service Application", 867 draft-alfano-aaa-qosprot-02 (work in progress), February 2005. 869 [13] Alfano, F., "Requirements for a QoS AAA Protocol", 870 draft-alfano-aaa-qosreq-01 (work in progress), October 2003. 872 [14] Lior, A., "Prepaid Extensions to Remote Authentication Dial-In 873 User Service (RADIUS)", draft-lior-radius-prepaid-extensions-07 874 (work in progress), February 2005. 876 [15] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05 877 (work in progress), July 2005. 879 [16] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using 880 Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in 881 progress), May 2005. 883 [17] Congdon, P., "RADIUS Extensions for IEEE 802", 884 draft-congdon-radext-ieee802-03 (work in progress), 885 February 2005. 887 Authors' Addresses 889 Hannes Tschofenig 890 Siemens 891 Otto-Hahn-Ring 6 892 Munich, Bavaria 81739 893 Germany 895 Email: Hannes.Tschofenig@siemens.com 896 URI: http://www.tschofenig.com 898 Allison Mankin 899 Shinkuro, Inc 900 1025 Vermont Avenue 901 Washington, DC 20005 902 US 904 Phone: +1 301-728-7199 (mobile) 905 Email: mankin@psg.com 907 Tseno Tsenov 908 Siemens 909 Otto-Hahn-Ring 6 910 Munich, Bayern 81739 911 Germany 913 Email: tseno.tsenov@mytum.de 914 Avi Lior 915 Bridgewater Systems Corporation 916 303 Terry Fox Drive 917 Ottawa, Ontario K2K 3J1 918 Canada 920 Phone: +1 613-591-6655 921 Email: avi@bridgewatersystems.com 923 Intellectual Property Statement 925 The IETF takes no position regarding the validity or scope of any 926 Intellectual Property Rights or other rights that might be claimed to 927 pertain to the implementation or use of the technology described in 928 this document or the extent to which any license under such rights 929 might or might not be available; nor does it represent that it has 930 made any independent effort to identify any such rights. Information 931 on the procedures with respect to rights in RFC documents can be 932 found in BCP 78 and BCP 79. 934 Copies of IPR disclosures made to the IETF Secretariat and any 935 assurances of licenses to be made available, or the result of an 936 attempt made to obtain a general license or permission for the use of 937 such proprietary rights by implementers or users of this 938 specification can be obtained from the IETF on-line IPR repository at 939 http://www.ietf.org/ipr. 941 The IETF invites any interested party to bring to its attention any 942 copyrights, patents or patent applications, or other proprietary 943 rights that may cover technology that may be required to implement 944 this standard. Please address the information to the IETF at 945 ietf-ipr@ietf.org. 947 Disclaimer of Validity 949 This document and the information contained herein are provided on an 950 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 951 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 952 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 953 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 954 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 955 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 957 Copyright Statement 959 Copyright (C) The Internet Society (2005). This document is subject 960 to the rights, licenses and restrictions contained in BCP 78, and 961 except as set forth therein, the authors retain all their rights. 963 Acknowledgment 965 Funding for the RFC Editor function is currently provided by the 966 Internet Society.