idnits 2.17.00 (12 Aug 2021) /tmp/idnits29985/draft-tschofenig-radext-qos-00.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 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 719. ** 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 11, 2005) is 6158 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 394 -- Looks like a reference, but probably isn't: 'TBD' on line 521 ** 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' ** Obsolete normative reference: RFC 3588 (ref. '6') (Obsoleted by RFC 6733) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 4080 (ref. '11') == Outdated reference: A later version (-05) exists of draft-alfano-aaa-qosprot-02 == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 Summary: 11 errors (**), 0 flaws (~~), 4 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 12, 2006 A. Mankin 5 Shinkuro, Inc 6 T. Tsenov 7 Siemens 8 A. Lior 9 Bridgewater Systems 10 July 11, 2005 12 RADIUS Quality of Service Support 13 draft-tschofenig-radext-qos-00.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 12, 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. QoS Authorization for a Session . . . . . . . . . . . . . . . 6 66 4.1 Session Establishment . . . . . . . . . . . . . . . . . . 6 67 4.2 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 6 68 4.2.1 Client-side initiated Re-Authorization . . . . . . . . 6 69 4.2.2 Server-side initiated Re-Authorization . . . . . . . . 7 70 4.3 Session Termination . . . . . . . . . . . . . . . . . . . 7 71 4.3.1 Client-side initiated session termination . . . . . . 7 72 4.3.2 Server-side initiated session termination . . . . . . 7 73 5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.1 QSPEC Attribute . . . . . . . . . . . . . . . . . . . . . 9 76 6.2 Flow Identification . . . . . . . . . . . . . . . . . . . 14 77 6.3 Authorization Objects . . . . . . . . . . . . . . . . . . 15 78 7. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 16 79 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 84 11.2 Informative References . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 86 Intellectual Property and Copyright Statements . . . . . . . . 23 88 1. Introduction 90 To meet the quality-of-service needs of applications such as voice- 91 over-IP, it will often be necessary to explicitly request resources 92 from the network. This will allow the network to identify packets 93 belonging to these application flows and ensure that bandwidth, 94 delay, and error rate requirements are met. 96 This document is a complement to the ongoing work of the DIAMETER QoS 97 application described in [12]. It describes RADIUS protocol 98 extensions supporting AAA in an environment where better than best 99 effort Quality of Service is desired. The suggested extensions to 100 the RFC 2865 [1], RFC 2866 [2], RFC 2869 [3] and RFC 3576 [4] satisfy 101 the requirements defined in [13]. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC-2119 [5]. 109 3. Goals 111 This document has a few ambitious goals, namely: 113 o Decouple the QoS signaling protocol (such as NSIS, RSVP or link 114 layer QoS signaling protocols) from the AAA protocol. This goal 115 is accomplished with the help of a generic QoS description, the 116 QSPEC object. 118 o Support for different scenarios that demand authorization for QoS 119 reservations. The impact is to provide flexibility with regard to 120 the entities that trigger the QoS reservation, the QoS parameters 121 that need to be provided to the RADIUS server for authorization, 122 the granularity of the QoS reservation (e.g., for an individual 123 application flow, for an aggregate). 125 4. QoS Authorization for a Session 127 A request from a Quality of Service enabled RADIUS clietn starts a 128 RADIUS message exchange. The identity of the user, and depending on 129 the scenario, the identity of the QoS authorizing application server 130 and optional session identification information, are assembled into a 131 RADIUS Access-Request message by the AAA client responsible for 132 resource allocation and sent to a AAA server either co-located with 133 an application server, to the local AAA server or to the RADIUS 134 server in the user's home realm. 136 If the authentication procedure involves multiple Access-Requests (as 137 in EAP), the RADIUS client MUST include the QoS-attributes in at 138 least the last Access-Request of the authentication procedure. 140 The server processes the information and responds with a RADIUS 141 Access-Accept message, which contains the QoS authorization result, 142 accounting and bearer gating information. Also, the value of the 143 Session-Timeout attribute is set to the duration of the session, the 144 value of the "Termination-Action" attribute is set and the "State" 145 attribute MUST be included as stated in [1]. 147 If the authorization decision at the RADIUS server indiates that the 148 request cannot be completed successfully then an Access-Reject 149 message containing the Reply-Message attribute with the reason for 150 rejection. 152 4.1 Session Establishment 154 When the QoS authorization exchange completes successfully, an RADIUS 155 Accounting session SHOULD start for reporting accounting information 156 and loss of bearer. Accounting information is reported as described 157 in [2] and [3]. Loss of bearer information is reported using Access- 158 Request message. 160 4.2 QoS Re-Authorization 162 4.2.1 Client-side initiated Re-Authorization 164 The "Authorize-ONLY" Access-Request MUST NOT include either User 165 Password or a CHAP Password. In order to protect the RADIUS message, 166 the RADIUS client MUST include the Message-Authenticator(80) 167 attribute. The RADIUS client will compute the value for the Message- 168 Authenticator based on [3]. 170 The RADIUS server processes the information including the 171 verification of the Message-Authenticator(80) as per [3] and responds 172 with a RADIUS Access-Accept message which contains the "Service-Type" 173 (6) attribute with value "Authorize-ONLY", QoS authorization, 174 accounting, bearer gating information, and the "State" attribute with 175 new value or a Access-Reject message containing the Reply-Message 176 attribute with the reason of rejection. 178 4.2.2 Server-side initiated Re-Authorization 180 At any time during the QoS session the RAIDUS server MAY send a 181 Change-of-Authorization (CoA) message with the "Service-Type" (6) 182 attribute with the value "Authorize-ONLY". The RADIUS client MUST 183 respond with a Change-of-Authorization NACK message with the 184 "Service-Type" (6) attribute with the value "Authorize-ONLY" and the 185 Error-Cause attribute with value "Request-Initiated". The RADIUS 186 client MUST then send an Access-Request containing "Service-Type" (6) 187 attribute with value "Authorize-ONLY" and re-authorization 188 information. This approach is compatible with the DIAMETER re- 189 authorization procedure and is defined in RFC 3576 [4]. Furthermore, 190 the "State" attribute SHOULD be used as specified in RFC 3576 [4]. 192 4.3 Session Termination 194 4.3.1 Client-side initiated session termination 196 A QoS session may be terminated from the client side by sending a 197 Access-Request message with unchanged "State" attribute received from 198 the RADIUS server. This action is defined in [6]. 200 4.3.2 Server-side initiated session termination 202 At anytime during a session the Authorizing Server may send a 203 Disconnect message to terminate a session. This capability is 204 described in detail in RFC 3576 [4]. The RADIUS server sends a 205 Disconnect message that MUST contain identifiers that uniquely 206 identify the subscribers data session and the RADIUS client serving 207 that session and the "Service-Type" (6) attribute with value 208 "Authorize-ONLY". 210 If the RADIUS client receives a Disconnect message, it MUST respond 211 with the Disconnect-NACK message with "Service-Type" (6) attribute 212 with value "Authorize-ONLY" and Error-Cause attribute with the value 213 "Request-Initiated". If it is able to terminate the session it will 214 send Access-Request message with "Service-Type" (6) attribute with 215 value "Authorize-ONLY" and attributes for session termination. This 216 message flow is required for compatibility with DIAMETER protocol. 217 Also the "State" attribute SHOULD be used as specified in RFC 3576 218 [4]. 220 5. Accounting 222 Application of the RADIUS protocol for QoS Authorization presented in 223 this document use RADIUS Accounting as defined in the RFC2865, 224 RFC2866 and RFC2869. The definition of new accounting attributes may 225 be necessary but left for further study. 227 After a successful QoS authorization the RADIUS client starts the 228 corresponding accounting session by sending the Accounting-Request 229 message. This message SHOULD contain necessary attributes to bind 230 the current accounting session to the reported QoS session. "Class" 231 and "Acc-Session-ID" attributes SHOULD be used according to [1] and 232 [2].The RADIUS server responds with a Accounting-Accept message after 233 successfully processing the Accounting-Request message. The 234 Accounting-Accept message MAY contain instructions for managing the 235 accounting session, such as the Accounting-Interim-Interval AVP. 237 After every successful re-authorization procedure the RADIUS client 238 SHOULD re-initiate accounting message exchange. 240 After successful session termination the RADIUS client SHOULD 241 initiate a final exchange of accounting messages with the RADIUS 242 server. 244 6. Attributes 246 This section defines three categories of attributes: 248 o QSPEC parameters describing requested/authorized QoS 250 o Identification of the flow that should receive QoS described in 251 QSPEC 253 o AVPs required to carry authorization information (e.g., 254 authorization tokens as specified in [7]) 256 6.1 QSPEC Attribute 258 The generic QoS description is taken from QoS-NSLP QSpec Template 259 [14] which aims to support QoS parameters for all QoS reservations 260 and is independent of a specific QoS model (QOSM). The QSPEC 261 template format is organized into QoS Control information, Requested, 262 Reserved, Available and Minimun objects. Each of the objects 263 contains a number of QSPEC parameters. For QoS authorization 264 purposes only part of the parameters SHOULD be used, e.g., mainly 265 those included into the QoS Desired and some of those included into 266 QoS Control information objects. In addition information for 267 duration of the authorized QoS SHOULD be provided. 269 QSPEC parameters and QoS authorization session management parameters 270 are included as subtypes into the QSPEC attribute. Subtypes not used 271 are omitted in the message. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | QoSM ID | SUB-TYPE 2 | LENGTH | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Excess Treatment | SUB-TYPE 3 | LENGTH | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Bandwidth | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | SUB-TYPE 4 | LENGTH | Token Bucket Rate [r] | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Token Bucket Rate [r] | SUB-TYPE 5 | LENGTH | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Token Bucket Size [b] | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | SUB-TYPE 6 | LENGTH | Peak Data Rate [p] | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Peak Data Rate [p] | SUB-TYPE 7 | LENGTH | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Minimum Policed Unit [m] | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | SUB-TYPE 8 | LENGTH | Maximum Packet Size [MTU] | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Maximum Packet Size [MTU] | SUB-TYPE 9 | LENGTH | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | PHB Class | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | SUB-TYPE 10 | LENGTH |Y.1541 QoSClass| SUB-TYPE 11 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | LENGTH |DSTE Class Type| SUB-TYPE 12 | LENGTH | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Preemption Priority | SUB-TYPE 13 | LENGTH | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Defending Priority | SUB-TYPE 14 | LENGTH | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Reservation Priority | SUB-TYPE 15 | LENGTH | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Authorization lifetime | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | SUB-TYPE 16 | LENGTH | Authorized Volume | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Authorized Volume | SUB-TYPE 17 | LENGTH | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Application Server ID | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type: Value of QSPEC 323 Length: variable, greater than 8 325 String: The String value MUST be encoded as follows: 327 Sub-Type (=1): Sub-Type for QoS-Model ID attribute 329 Length : Length of QoS-Model ID attribute (= 6 octets) 331 QoS-Model ID (QoSM ID): 333 Identifier of the used QoS signaling model.[14] 335 Sub-Type (=2): Sub-Type for Excess Treatment attribute 337 Length : Length of Excess Treatment attribute (= 3 octets) 339 Excess Treatment: 341 Description of how the excess traffic to be processed (out-of- 342 profile traffic). Excess traffic MAY be dropped, shaped and/or 343 remarked. 345 Sub-Type (=3): Sub-Type for Bandwidth attribute 347 Length : Length of Bandwidth attribute (= 6 octets) 349 Bandwidth: 351 Link bandwidth needed by a flow. 353 Sub-Type (=4): Sub-Type for Token Bucket Rate attribute 355 Length : Length of Token Bucket Rate attribute (= 6 octets) 357 Token Bucket Rate: 359 Rate is a Token Bucket parameter as specified in [8]. 361 Sub-Type (=5): Sub-Type for Token Bucket Size attribute 363 Length : Length of Token Bucket Size attribute (= 6 octets) 365 Token Bucket Size: 367 Size is a Token Bucket parameter as specified in [8]. 369 Sub-Type (=6): Sub-Type for Peak Data Rate attribute 371 Length : Length of Peak Data Rate attribute (= 6 octets) 373 Token Bucket Size: 375 Peak Data Rate is a Token Bucket parameter as specified in [8]. 377 Sub-Type (=7): Sub-Type for Minimum Policed Unit attribute 379 Length : Length of Minimum Policed Unit attribute (= 6 380 octets) 382 Minimum Policed Unit: 384 Minimum Policed Unit is a Token Bucket parameter as specified in 385 [8]. 387 Sub-Type (=8): Sub-Type for Maximum Packet Size [MTU] attribute 389 Length : Length of Maximum Packet Size [MTU] attribute (= 6 390 octets) 392 Maximum Packet Size [MTU]: 394 Maximum Packet Size [MTU] is a Token Bucket parameter as specified 395 in [8]. 397 Sub-Type (=9): Sub-Type for PHB class attribute 399 Length : Length of PHB class attribute (= 6 octets) 401 PHB class: 403 Indicates the QoS class used in DiffServ per-hop behavior QoS 404 signaling [9]. 406 Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute 408 Length : Length of Y.1541 QoS class attribute (= 3 octets) 410 Y.1541 QoS class: 412 Indicates the Y.1541 QoS Class [15]. 414 Sub-Type (=11): Sub-Type for DSTE class attribute 416 Length : Length of DSTE class attribute (= 3 octets) 418 DSTE Class: 420 Indicates the QoS class used in DiffServ-enabled MPLS traffic 421 engineering.[10]. 423 Sub-Type (=12): Sub-Type for Preemption Priority attribute 425 Length : Length of Preemption Priority attribute (= 4 octets) 427 Preemption Priority: 429 Parameter used in the process of differentiation of flows. 430 Indicates the priority of the new flow compared with the defending 431 priority of previously admitted flows. 433 Sub-Type (=13): Sub-Type for Defending Priority attribute 435 Length : Length of Defending Priority attribute (= 4 octets) 437 Defending Priority: 439 Parameter used in the process of differentiation of flows. It is 440 compared with the preemption priority of new flows. 442 Sub-Type (=14): Sub-Type for Reservation Priority attribute 444 Length : Length of Reservation Priority attribute (= 4 445 octets) 447 Reservation Priority: 449 Parameter used in the process of differentiation of flows for 450 emergency services, ETS, E911, etc., and assigning them a higher 451 admission priority. 453 Sub-Type (=15): Sub-Type for Authorization lifetime attribute 455 Length : Length of Authorization lifetime attribute (= 6 456 octets) 458 Authorization lifetime: 460 The parameter indicates the duration of the authorized QoS 461 provisioning. 463 Sub-Type (=16): Sub-Type for Authorized volume attribute 465 Length : Length of Authorized volume attribute (= 6 octets) 467 Authorized volume: 469 The parameter indicates the data volume that should receive the 470 authorized QoS. 472 Sub-Type (=17): Sub-Type for Application server ID attribute 474 Length : Length of Authorized volume attribute (IPv4 = 6 475 octets, IPv6= 18 octets) 477 Application server ID: 479 Application server ID indicates the address of the authorizing 480 Application Server. 482 Provided QSPEC parameters list is not exhaustive and SHOULD be 483 updated according to [14]. 485 6.2 Flow Identification 487 Depending on the deployment and used QoS signaling protocol, 488 identification of the flow that SHOULD received authorized QoS takes 489 a different format. Signaling session Identifier (NSIS) or flow 490 identifier and explicit filter specifications are used. The 491 Attribute QoS-Flow-ID is designated to encapsulate such information. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Signaling Session ID | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Type : Value of QoS-Flow-ID 503 Length: variable, greater than 8 505 String: The String value MUST be encoded as follows: 507 Sub-Type (=1): Signaling Session ID 509 Length : Length of Signaling Session ID attribute (= 6 510 octets) 512 Signaling Session ID: 514 In NSIS framework [11], Signaling session ID is an unique 515 identifier of the signaling session that remains unchanged for the 516 duration of the session. It is locally mapped to the specific 517 flow identifiers. 519 Additional Sub-Type attributes SHOULD be added, which combined with 520 filter specifications (such as QoS-Filter-Rule [16]) provide flow 521 identification. [TBD] 523 6.3 Authorization Objects 525 TBD: 527 7. Diameter RADIUS Interoperability 529 In deployments where RADIUS clients communicate with DIAMETER servers 530 or DIAMETER clients communicate with RADIUS servers then a 531 translation agent will be deployed and operate. The DIAMETER-QoS 532 specification [12] provides a natural candidate for mapping the 533 RADIUS QoS related AVPs to DIAMETER AVPs and messages. 535 8. Examples 537 TBD: Description of the example goes in here. 539 RADIUS RADIUS 540 Client Server 541 -----------> | | 542 QoS | Access-Request/UserID, QSPEC/ | 543 reservation |----------------------------------------------->| 544 request | | 545 | Access-Accept/QSPEC/ | 546 |<-----------------------------------------------| 547 | | 548 Start |Accounting-Request/Start,QoS Acc-Session-ID.../ | 549 Accounting |----------------------------------------------->| 550 | Accounting-Accept/...Acc-Interim-Period.../ | 551 |<-----------------------------------------------| 552 | | 553 Authorization| | 554 LifeTime | | 555 Expires: | | 556 Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ | 557 Authorization|----------------------------------------------->| 558 | Access-Accept/ Auth-ONLY, QSPEC/ | 559 |<-----------------------------------------------| 560 | Accounting-Request/Interim, Acc-Session-ID./ | 561 |----------------------------------------------->| 562 | Accounting-Accept/...Acc-Interim-Period.../ | 563 |<-----------------------------------------------| 564 ..................... 565 | Session 566 | Termination 567 | initiated 568 | by 569 | server 570 | Disconnect-Request/Auth-ONLY, .../ <------ 571 |<-----------------------------------------------| 572 | Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ | 573 |----------------------------------------------->| 574 | Access-Request/Auth-ONLY,... | 575 | Acc-Terminate-Cause="Admin-Reset"/| 576 |----------------------------------------------->| 577 | Access-Accept | 578 |<-----------------------------------------------| 579 Accounting | Accounting-Request/Final,Acc-Session-ID./ | 580 end |----------------------------------------------->| 581 | Accounting-Accept /Final,.../ | 582 |<-----------------------------------------------| 584 9. Security Considerations 586 For this extension to RADIUS protocol the security considerations 587 defined in RFC2865 [1], RFC2866 [2], RFC2869 [3] and RFC3576 [4] are 588 applicable. Furthermore, the security of the QoS signaling protocol 589 and the QoS authorization framework must be considered in the 590 evaluation of the security properties. 592 [Editor's Note: A more detailed treatment will be provided in a 593 future document version.] 595 10. Acknowledgments 597 We would like to thank Pete McCann and Franck Alfano for their work 598 on the DIAMETER QoS application. 600 11. References 602 11.1 Normative References 604 [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 605 Authentication Dial In User Service (RADIUS)", RFC 2865, 606 June 2000. 608 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 610 [3] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 611 RFC 2869, June 2000. 613 [4] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 614 "Dynamic Authorization Extensions to Remote Authentication Dial 615 In User Service (RADIUS)", RFC 3576, July 2003. 617 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 618 Levels", March 1997. 620 [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 621 "Diameter Base Protocol", RFC 3588, September 2003. 623 [7] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 624 Authorization Policy Element", RFC 3520, April 2003. 626 [8] Shenker, S. and J. Wroclawski, "General Characterization 627 Parameters for Integrated Service Network Elements", RFC 2215, 628 September 1997. 630 [9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 631 Weiss, "An Architecture for Differentiated Services", RFC 2475, 632 December 1998. 634 [10] Le Faucheur, F. and W. Lai, "Requirements for Support of 635 Differentiated Services-aware MPLS Traffic Engineering", 636 RFC 3564, July 2003. 638 [11] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 639 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 640 June 2005. 642 11.2 Informative References 644 [12] Alfano, F., "Diameter Quality of Service Application", 645 draft-alfano-aaa-qosprot-02 (work in progress), February 2005. 647 [13] Alfano, F., "Requirements for a QoS AAA Protocol", 648 draft-alfano-aaa-qosreq-01 (work in progress), October 2003. 650 [14] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-04 651 (work in progress), May 2005. 653 [15] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using 654 Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in 655 progress), May 2005. 657 [16] Congdon, P., "RADIUS Extensions for IEEE 802", 658 draft-congdon-radext-ieee802-03 (work in progress), 659 February 2005. 661 Authors' Addresses 663 Hannes Tschofenig 664 Siemens 665 Otto-Hahn-Ring 6 666 Munich, Bavaria 81739 667 Germany 669 Email: Hannes.Tschofenig@siemens.com 670 URI: http://www.tschofenig.com 672 Allison Mankin 673 Shinkuro, Inc 674 1025 Vermont Avenue 675 Washington, DC 20005 676 US 678 Phone: +1 301-728-7199 (mobile) 679 Email: mankin@psg.com 681 Tseno Tsenov 682 Siemens 683 Otto-Hahn-Ring 6 684 Munich, Bayern 81739 685 Germany 687 Email: tseno.tsenov@mytum.de 688 Avi Lior 689 Bridgewater Systems Corporation 690 303 Terry Fox Drive 691 Ottawa, Ontario K2K 3J1 692 Canada 694 Phone: +1 613-591-6655 695 Email: avi@bridgewatersystems.com 697 Intellectual Property Statement 699 The IETF takes no position regarding the validity or scope of any 700 Intellectual Property Rights or other rights that might be claimed to 701 pertain to the implementation or use of the technology described in 702 this document or the extent to which any license under such rights 703 might or might not be available; nor does it represent that it has 704 made any independent effort to identify any such rights. Information 705 on the procedures with respect to rights in RFC documents can be 706 found in BCP 78 and BCP 79. 708 Copies of IPR disclosures made to the IETF Secretariat and any 709 assurances of licenses to be made available, or the result of an 710 attempt made to obtain a general license or permission for the use of 711 such proprietary rights by implementers or users of this 712 specification can be obtained from the IETF on-line IPR repository at 713 http://www.ietf.org/ipr. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights that may cover technology that may be required to implement 718 this standard. Please address the information to the IETF at 719 ietf-ipr@ietf.org. 721 Disclaimer of Validity 723 This document and the information contained herein are provided on an 724 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 725 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 726 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 727 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 728 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 729 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 731 Copyright Statement 733 Copyright (C) The Internet Society (2005). This document is subject 734 to the rights, licenses and restrictions contained in BCP 78, and 735 except as set forth therein, the authors retain all their rights. 737 Acknowledgment 739 Funding for the RFC Editor function is currently provided by the 740 Internet Society.