idnits 2.17.00 (12 Aug 2021) /tmp/idnits28049/draft-tschofenig-radext-qos-03.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 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1037. ** 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 (June 25, 2006) is 5808 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 476 == Unused Reference: '11' is defined on line 946, 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 (-01) exists of draft-tschofenig-dime-diameter-qos-00 == Outdated reference: draft-ietf-radext-filter has been published as RFC 4849 == Outdated reference: A later version (-22) exists of draft-lior-radius-prepaid-extensions-10 == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 == Outdated reference: draft-ietf-sipping-trait-authz has been published as RFC 4484 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-00 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 9 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: December 27, 2006 A. Mankin 6 T. Tsenov 8 A. Lior 9 Bridgewater Systems 10 June 25, 2006 12 RADIUS Quality of Service Support 13 draft-tschofenig-radext-qos-03.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 December 27, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . 18 81 8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20 82 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 9.1. RADIUS authorization of a QoS signaling reservation 84 request . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 9.2. RADIUS authentication, authorization and management of 86 a QoS-enabled access session . . . . . . . . . . . . . . . 23 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 93 Intellectual Property and Copyright Statements . . . . . . . . . . 31 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 Disclaimer: The content of this document will be aligned with the 111 ongoing QoS work in the DIME working group. Additionally, the 112 description of the data traffic that is experiencing the QoS 113 treatment will be aligned with the [14]. Hence, the content of the 114 attributes presented in this document are subject to change. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC-2119 [5]. 122 3. Goals 124 This document has a few ambitious goals, namely: 126 o Decouple the QoS signaling protocol (such as NSIS, RSVP or link 127 layer QoS signaling protocols) from the AAA protocol. This goal 128 is accomplished with the help of a generic QoS description, the 129 QSPEC object. 131 o Support for different scenarios that demand authorization for QoS 132 reservations. The impact is to provide flexibility with regard to 133 the entities that trigger the QoS reservation, the QoS parameters 134 that need to be provided to the RADIUS server for authorization, 135 the granularity of the QoS reservation (e.g., for an individual 136 application flow, for an aggregate). 138 4. RADIUS functional considerations 140 Being a value-added service, QoS provisioning SHOULD go along with 141 explicit authorization, accounting and control over the QoS-featured 142 user session. Specifically, the management of the authorized session 143 with Session-Timeout(27) and Termination-Action(29) attributes raises 144 a number of issues, identified in [15]. The solution presented in 145 this document aims to allow explicit control by the RADIUS server 146 (Authorizing entity) over the authorization session and its 147 parameters. In addition, it aims to support flexible deployment 148 scenarios of QoS authorization and parameter provisioning by 149 Authorization entities, which know the user and its subscription 150 profile (Home AAA server) or can provide authorization for a session 151 requested by the user (Application server). QoS authorization and 152 parameter provisioning MAY be incorporated into initial 153 authentication and authorization RADIUS exchange or MAY be triggered 154 at a later moment by a reception of a QoS signalling message. 156 5. Authorization and QoS parameter provision 158 5.1. QoS enabled initial access authentication and authorization 160 QoS enabled RADIUS client (NAS) initiates the authentication and 161 authorization process by sending a RADIUS Access-Request to the 162 user's Home AAA server. In addition to authentication related 163 attributes, it includes the QSPEC(TBD) attribute, which MAY specify 164 the QoS-Model [16] supported by the NAS and description of the 165 currently available QoS resources or description of the QoS 166 explicitly requested by the user. In the second case, additional 167 session and flow identification information MIGHT be included 168 together with the identity of the QoS authorizing application server. 170 If the authentication process involves multiple Access-Requests (as 171 in EAP), the RADIUS client MUST include the QSPEC(TBD) attribute and 172 any additional QoS-authorization related information in at least the 173 last Access-Request of the authentication process. 175 The Home AAA server receives the Access-Request message and 176 authenticates the user. Based on the user profile it determines the 177 subscription QoS parameters and includes them into the QSPEC(TBD) 178 attribute of the Access-Accept message. 180 In case that the QoS authorization MUST be done by an Application 181 server, which identity is included into the Access-Request message, 182 the Home server forwards the Access-Request to the Application 183 server. The Access-Request will contain the QSPEC(TBD) attribute and 184 session identification information. Upon successful authorization, 185 the Application server generates an Access-Accept containing the 186 QSPEC(TBD) attribute, flow identification information and optionally 187 bearer gating information. 189 The QSPEC attribute returned to the client SHOULD contain the 190 duration of the QoS enabled session. 192 If the authentication or authorization of the user is not successful, 193 the Home AAA server or the application server sends back an Access- 194 Reject message containing Reply-Message(18) attribute with the reason 195 for rejection. 197 When the QoS authorization exchange completes successfully, a RADIUS 198 Accounting session SHOULD start for reporting accounting information. 199 Accounting information is reported as described in [2] and [3]. Loss 200 of bearer information is reported using Access-Request message as 201 specified in the following section. 203 5.2. Mid-Session QoS authorization 205 5.2.1. Client-side initiated QoS authorization/re-authorization 207 Two types of QoS-related events MIGHT initiate Authorize-Only Access- 208 Request messages - reception of a QoS signaling message or expiration 209 of authorization lifetime of ongoing QoS-enabled session. In both 210 cases, the RADIUS client sends an Access-Request with Service-Type(6) 211 attribute set to a value of "Authorize-Only", QSPEC(TBD) attribute 212 and session and flow identification information. The QSPEC(TBD) 213 attribute includes description of new QoS parameters explicitly 214 required by the user or the QoS parameters that SHOULD be re- 215 authorized. Session and flow (only in the re-authorization case) 216 identification information SHOULD be the same as those used during 217 the initial Access-Request. For example, if the User-Name(1) 218 attribute was used in the initial Access-Request it MUST be included, 219 especially if the User-Name(1) attribute is used to route the Access- 220 Request to the Home RADIUS server. 222 The "Authorize-ONLY" Access-Request MUST NOT include either User 223 Password(2) or a CHAP Password(3). In order to protect the RADIUS 224 message, the RADIUS client MUST include the Message-Authenticator(80) 225 attribute. The RADIUS client will compute the value for the Message- 226 Authenticator(80) based on [3]. 228 The RADIUS server processes the information, including the 229 verification of the Message-Authenticator(80) as per [3], and upon 230 successful authorization it responds with a RADIUS Access-Accept 231 message. It contains the Service-Type(6) attribute with value 232 "Authorize-ONLY", the QSPEC(TBD) attribute, flow identification 233 information and optionally bearer gating information. The QSPEC(TBD) 234 attribute returned to the client SHOULD contain the new duration of 235 the QoS enabled session. In case of unsuccessful authorization an 236 Access-Reject message is sent, containing the Reply-Message(18) 237 attribute with the reason of rejection. 239 In case that an Application server MUST be contacted for the QoS 240 authorization, the Home server forwards the Access-Request to the 241 indicated Application server, which processes the QoS authorization 242 request. 244 5.2.2. Server-side initiated Re-Authorization 246 In order to take advantage of the dynamic authorization capabilities 247 of RADIUS as defined in [4], the Authorization entity (Home or 248 Application server) MUST be sure that the RADIUS client supports them 249 too. An advertising approach proposed in [15] MIGHT be used.(TBD) 250 At any time during the QoS session the RADIUS server MAY send a 251 Change-of-Authorization (CoA) message with Service-Type(6) attribute 252 set to value "Authorize-ONLY" and session and flow identification 253 information. The RADIUS client MUST respond with a Change-of- 254 Authorization NACK message with Service-Type(6) attribute with value 255 "Authorize-ONLY" and Error-Cause(101) attribute set to value 256 "Request-Initiated". The RADIUS client MUST then send an Access- 257 Request containing Service-Type(6) attribute with value "Authorize- 258 ONLY", QSPEC(TBD) attribute, session and flow identification 259 information. This approach is compatible with the DIAMETER re- 260 authorization procedure and is defined in RFC 3576 [4]. Furthermore, 261 the "State" attribute SHOULD be used as specified in RFC 3576 [4]. 263 5.3. Session Termination 265 5.3.1. Client-side initiated session termination 267 Service session MAY be related to a particular authorized QoS- 268 provisioned data flow. In this case, session termination MAY be 269 caused by a QoS signaling tear down message or loss of bearer report. 270 In another scenario the service session is a QoS enabled access 271 session, which can handle authorization of several QoS-provisioned 272 user's data flows. In this case session termination MAY be caused by 273 user log-off. 275 A RADIUS client indicates session termination by sending an 276 Accounting-Request message with Acc-Status-Type(40) attribute set to 277 "Stop" value and final QoS related accounting records(TBD). 279 5.3.2. Server-side initiated session termination 281 At anytime during a session the Authorizing Server may send a 282 Disconnect message to terminate the session. This capability is 283 described in detail in RFC 3576 [4]. The RADIUS server sends a 284 Disconnect message that MUST contain identifiers that uniquely 285 determine the subscriber's session and the RADIUS client serving that 286 session and Service-Type(6) attribute with value "Authorize-ONLY". 288 If the RADIUS client receives a Disconnect message, it MUST respond 289 with the Disconnect-NACK message with Service-Type(6) attribute with 290 value "Authorize-ONLY" and Error-Cause(101) attribute with value 291 "Request-Initiated". If it is able to terminate the session it will 292 send Access-Request message with Service-Type(6) attribute with value 293 "Authorize-ONLY" and attributes for session termination. This 294 message flow is required for compatibility with DIAMETER protocol. 295 Also the State(24) attribute SHOULD be used as specified in RFC 3576 296 [4]. 298 6. Accounting 300 Application of the RADIUS protocol for QoS authorization presented in 301 this document use RADIUS Accounting as defined in the RFC2865 [1], 302 RFC2866 [2] and RFC2869 [3]. The attributes containing a QoS 303 description and flow identification (see Section 7) are used in the 304 accounting session for reporting the status and parameters of the 305 provided QoS. The definition of new accounting attributes may be 306 necessary. This aspect is for further study. 308 After a successful QoS authorization the RADIUS client starts the 309 corresponding accounting session by sending the Accounting-Request 310 message. This message SHOULD contain necessary attributes to bind 311 the current accounting session to the reported QoS session. 312 Class(25) and Acc-Session-ID(44) attributes SHOULD be used according 313 to [1] and [2]. The RADIUS server responds with an Accounting- 314 Response message after successfully processing the Accounting-Request 315 message. The Accounting-Response message MAY contain instructions 316 for managing the accounting session, such as the Acct-Interim- 317 Interval(85) attribute. 319 After every successful re-authorization procedure the RADIUS client 320 SHOULD re-initiate accounting message exchange. 322 For indication of session termination the RADIUS client SHOULD 323 initiate a final exchange of accounting messages with the RADIUS 324 server. 326 7. Attributes 328 This section defines three categories of attributes: 330 o QSPEC parameters describing requested/authorized QoS 332 o Identification of the flow that should receive QoS described in 333 QSPEC 335 o Attributes required to carry authorization information (e.g., 336 authorization tokens as specified in [6]) 338 7.1. QSPEC Attribute 340 The generic QoS description is taken from QoS-NSLP QSpec Template 341 [16] which aims to support QoS parameters for all QoS reservations 342 and is independent of a specific QoS model (QOSM). The QSPEC 343 template format is organized into QoS Control information, Requested, 344 Reserved, Available and Minimum objects. Each of the objects 345 contains a number of QSPEC parameters. For QoS authorization 346 purposes only part of the parameters SHOULD be used, e.g., mainly 347 those included into the QoS Desired and some of those included into 348 QoS Control information objects. In addition information for 349 duration of the authorized QoS SHOULD be provided. 351 QSPEC parameters and QoS authorization session management parameters 352 are included as subtypes into the QSPEC attribute. Subtypes not used 353 are omitted in the message. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | QoSM ID | SUB-TYPE 2 | LENGTH | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Excess Treatment | SUB-TYPE 3 | LENGTH | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Bandwidth | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | SUB-TYPE 4 | LENGTH | Token Bucket Rate [r] | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Token Bucket Rate [r] | SUB-TYPE 5 | LENGTH | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Token Bucket Size [b] | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | SUB-TYPE 6 | LENGTH | Peak Data Rate [p] | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Peak Data Rate [p] | SUB-TYPE 7 | LENGTH | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Minimum Policed Unit [m] | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | SUB-TYPE 8 | LENGTH | Maximum Packet Size [MTU] | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Maximum Packet Size [MTU] | SUB-TYPE 9 | LENGTH | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | PHB Class | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | SUB-TYPE 10 | LENGTH |Y.1541 QoSClass| SUB-TYPE 11 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | LENGTH |DSTE Class Type| SUB-TYPE 12 | LENGTH | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Preemption Priority | SUB-TYPE 13 | LENGTH | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Defending Priority | SUB-TYPE 14 | LENGTH | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Reservation Priority | SUB-TYPE 15 | LENGTH | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Authorization lifetime | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | SUB-TYPE 16 | LENGTH | Authorized Volume | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Authorized Volume | SUB-TYPE 17 | LENGTH | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Application Server ID | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Type: Value of QSPEC 405 Length: variable, greater than 8 407 String: The String value MUST be encoded as follows: 409 Sub-Type (=1): Sub-Type for QoS-Model ID attribute 411 Length : Length of QoS-Model ID attribute (= 6 octets) 413 QoS-Model ID (QoSM ID): 415 Identifier of the used QoS signaling model.[16] 417 Sub-Type (=2): Sub-Type for Excess Treatment attribute 419 Length : Length of Excess Treatment attribute (= 3 octets) 421 Excess Treatment: 423 Description of how the excess traffic to be processed (out-of- 424 profile traffic). Excess traffic MAY be dropped, shaped and/or 425 remarked. 427 Sub-Type (=3): Sub-Type for Bandwidth attribute 429 Length : Length of Bandwidth attribute (= 6 octets) 431 Bandwidth: 433 Link bandwidth needed by a flow. 435 Sub-Type (=4): Sub-Type for Token Bucket Rate attribute 437 Length : Length of Token Bucket Rate attribute (= 6 octets) 439 Token Bucket Rate: 441 Rate is a Token Bucket parameter as specified in [7]. 443 Sub-Type (=5): Sub-Type for Token Bucket Size attribute 445 Length : Length of Token Bucket Size attribute (= 6 octets) 447 Token Bucket Size: 449 Size is a Token Bucket parameter as specified in [7]. 451 Sub-Type (=6): Sub-Type for Peak Data Rate attribute 453 Length : Length of Peak Data Rate attribute (= 6 octets) 455 Token Bucket Size: 457 Peak Data Rate is a Token Bucket parameter as specified in [7]. 459 Sub-Type (=7): Sub-Type for Minimum Policed Unit attribute 461 Length : Length of Minimum Policed Unit attribute (= 6 462 octets) 464 Minimum Policed Unit: 466 Minimum Policed Unit is a Token Bucket parameter as specified in 467 [7]. 469 Sub-Type (=8): Sub-Type for Maximum Packet Size [MTU] attribute 471 Length : Length of Maximum Packet Size [MTU] attribute (= 6 472 octets) 474 Maximum Packet Size [MTU]: 476 Maximum Packet Size [MTU] is a Token Bucket parameter as specified 477 in [7]. 479 Sub-Type (=9): Sub-Type for PHB class attribute 481 Length : Length of PHB class attribute (= 6 octets) 483 PHB class: 485 Indicates the QoS class used in DiffServ per-hop behavior QoS 486 signaling [8]. 488 Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute 490 Length : Length of Y.1541 QoS class attribute (= 3 octets) 492 Y.1541 QoS class: 494 Indicates the Y.1541 QoS Class [17]. 496 Sub-Type (=11): Sub-Type for DSTE class attribute 498 Length : Length of DSTE class attribute (= 3 octets) 500 DSTE Class: 502 Indicates the QoS class used in DiffServ-enabled MPLS traffic 503 engineering.[9]. 505 Sub-Type (=12): Sub-Type for Preemption Priority attribute 507 Length : Length of Preemption Priority attribute (= 4 octets) 509 Preemption Priority: 511 Parameter used in the process of differentiation of flows. 512 Indicates the priority of the new flow compared with the defending 513 priority of previously admitted flows. 515 Sub-Type (=13): Sub-Type for Defending Priority attribute 517 Length : Length of Defending Priority attribute (= 4 octets) 519 Defending Priority: 521 Parameter used in the process of differentiation of flows. It is 522 compared with the preemption priority of new flows. 524 Sub-Type (=14): Sub-Type for Reservation Priority attribute 526 Length : Length of Reservation Priority attribute (= 4 527 octets) 529 Reservation Priority: 531 Parameter used in the process of differentiation of flows for 532 emergency services, ETS, E911, etc., and assigning them a higher 533 admission priority. [Editor's Note: Reference to be included 534 here.] 536 Sub-Type (=15): Sub-Type for Authorization lifetime attribute 538 Length : Length of Authorization lifetime attribute (= 6 539 octets) 540 Authorization lifetime: 542 The parameter indicates the duration of the authorized QoS 543 provisioning. 545 Sub-Type (=16): Sub-Type for Authorized volume attribute 547 Length : Length of Authorized volume attribute (= 6 octets) 549 Authorized volume: 551 The parameter indicates the data volume that should receive the 552 authorized QoS. 554 Sub-Type (=17): Sub-Type for Application server ID attribute 556 Length : Length of Authorized volume attribute (IPv4 = 6 557 octets, IPv6= 18 octets) 559 Application server ID: 561 Application server ID indicates the address of the authorizing 562 Application Server. 564 Provided QSPEC parameters list is not exhaustive and SHOULD be 565 updated according to [16]. 567 7.2. Flow Identification 569 Depending on the deployment and used QoS signaling protocol, 570 identification of the flow that SHOULD receive authorized QoS takes a 571 different format. Signaling session Identifier (NSIS) or flow 572 identifier and explicit filter specifications are used. The 573 Attribute QoS-Flow-ID is designated to encapsulate such information. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Signaling Session ID | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | SUB-TYPE 2 | LENGTH | Flow-ID | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | SUB-TYPE 3 | LENGTH | Flow-Status | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Type : Value of QoS-Flow-ID 589 Length: variable, greater than 8 591 String: The String value MUST be encoded as follows: 593 Sub-Type (=1): Signaling Session ID 595 Length : Length of Signaling Session ID attribute (= 6 596 octets) 598 Signaling Session ID: 600 With the NSIS framework [10], a signaling session ID is a unique 601 identifier of the signaling session that remains unchanged for the 602 entire lifetime of the session. It is locally mapped to the 603 specific flow identifiers. 605 Sub-Type (=2): Flow-ID 607 Length : Length of Flow-ID attribute 609 Flow-ID: 611 The Flow-ID attribute is an application assigned identifier for an 612 IP flow that identifies the IP flow in an application layer 613 session (e.g., SIP/SDP). It might be used in conjunction with a 614 QoS-Filter-Rule attribute for provision of flow description and 615 identification. Note that more than one Flow-ID sub-attributes 616 MAY be present in the QoS-Flow-Id attribute. 618 Sub-Type (=3): Flow-State 620 Length : Length of Flow-State attribute 622 Flow-State: 624 The Flow-State attribute indicates the action that MUST be 625 performed on the flow(s) to which QoS authorization message 626 exchange applies as identified by the QoS-Flow-Id. The flow could 627 be enabled (i.e., it is allowed to trespass the QoS element) and 628 it is treated according to the QoS described in the QSPEC 629 attribute. The flow could be disabled, i.e., the QoS described in 630 the QSPEC could be reserved but additional authorization approval 631 by the Authorizing entity is required in order for the flow to 632 receive this QoS treatment and to trespass the QoS element. 634 In the current approach, there is a one to one binding between a 635 QSPEC and a QoS-Flow-Id attribute in a RADIUS message. It is for 636 further study whether different QoS authorization information (i.e., 637 multiple QSPEC attributes) for different groups of flows (i.e., 638 multiple QoS-Flow-Id attributes) might need to be carried in a single 639 RADIUS message. 641 7.3. Authorization Objects 643 Depending on the deployment, different attributes MAY be used as an 644 input for computing the QoS authorization decision by the Authorizing 645 entity. In addition to the credentials of the end host, requesting 646 QoS reservation (e.g., User-Name(1) attribute), an authorization 647 token MAY be used. This occurs in a deployment scenario, where the 648 QoS parameters are negotiated as part of an application layer 649 signaling exchange and where the authorization decision at this 650 application layer exchange needs to be associated with the 651 authorization of the QoS reservation of the QoS signaling exchange. 652 The QoS-Authorization-Data attribute is designated to encapsulate 653 such information. 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Authorization-Token | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Type : Value of QoS-Authorization-Data 665 Length: variable, greater than 8 667 String: The String value MUST be encoded as follows: 669 Sub-Type (=1): Authorization-Token 671 Length : Length of Authorization-Token attribute 673 Authorization-Token: 675 The Authorization-Token sub-attribute is a container that 676 encapsulates an authorization token received via the QoS signaling 677 message typically sent by the end host. The token is generated by 678 the Authorizing entity during the application layer signaling 679 exchange and identifies the application service session, for which 680 the QoS reservation request applies. A possible structure for the 681 authorization token is proposed in context of RSVP [6] or using 682 SAML as outlined in [18] and [19]. The structure of the token is 683 considered to be out of the scope for this document. 685 8. Diameter RADIUS Interoperability 687 In deployments where RADIUS clients communicate with DIAMETER servers 688 or DIAMETER clients communicate with RADIUS servers then a 689 translation agent will be deployed and operate. The DIAMETER-QoS 690 specification [12] provides a natural candidate for mapping the 691 RADIUS QoS related AVPs to DIAMETER AVPs and messages. 693 9. Examples 695 The following diagrams show RADIUS protocol interactions for 696 different scenarios and deployment architectures. 698 9.1. RADIUS authorization of a QoS signaling reservation request 699 RADIUS RADIUS 700 Client Server 701 -----------> | | 702 QoS | Access-Request/UserID, QSPEC/ | 703 reservation |----------------------------------------------->| 704 request | | 705 | Access-Accept/QSPEC/ | 706 |<-----------------------------------------------| 707 | | 708 Start |Accounting-Request/Start, Acc-Session-ID.../ | 709 Accounting |----------------------------------------------->| 710 | Accounting-Response/...Acc-Interim-Period.../ | 711 |<-----------------------------------------------| 712 | | 713 Authorization| | 714 LifeTime | | 715 Expires: | | 716 Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ | 717 Authorization|----------------------------------------------->| 718 | Access-Accept/ Auth-ONLY, QSPEC/ | 719 |<-----------------------------------------------| 720 | Accounting-Request/Interim, Acc-Session-ID./ | 721 |----------------------------------------------->| 722 | Accounting-Response/...Acc-Interim-Period.../ | 723 |<-----------------------------------------------| 724 ..................... 725 | Session 726 | Termination 727 | initiated 728 | by 729 | server 730 | Disconnect-Request/Auth-ONLY, .../ <------ 731 |<-----------------------------------------------| 732 | Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ | 733 |----------------------------------------------->| 734 | Access-Request/Auth-ONLY,... | 735 | Acc-Terminate-Cause="Admin-Reset"/| 736 |----------------------------------------------->| 737 | Access-Accept | 738 |<-----------------------------------------------| 739 Accounting | Accounting-Request/Final,Acc-Session-ID./ | 740 end |----------------------------------------------->| 741 | Accounting-Response /Final,.../ | 742 |<-----------------------------------------------| 744 This example shows the protocol exchange between the RADIUS client 745 and the RADIUS server. An incoming QoS reservation request received 746 at the QoS policy aware node (i.e., RADIUS client) invokes the 747 transmission of a Access-Request message (AR) to the RADIUS server. 748 This message contains the requested QoS resources in a QSPEC 749 attribute along with user identification and authentication 750 information. After the request is successfully authenticated and 751 authorized, the RADIUS server replies with a Access-Accept message 752 (AA), which grants a reservation for a certain amount of resources 753 (as included in the QSPEC attribute). After the successful exchange 754 of the AR/AA messages, the RADIUS client starts an accounting session 755 by sending an Accounting-Request message. The server replies with an 756 Accounting-Response message that MAY include instructions for further 757 handling of the accounting session, such as the Acc-Interim-Period 758 attribute. 760 The client-side re-authorization caused by expiration of the 761 authorization lifetime initiates an Authorize-ONLY Access-Request / 762 Access-Accept message exchange. After a successful re-authorization 763 an Accounting-Request message SHOULD be sent to indicate the new 764 authorization parameters. The server replies with an Accounting- 765 Response message. 767 In this example, the RADIUS server initiates a session termination. 768 It therefore sends a Disconnect-Request message. The client responds 769 with a Disconnect-NACK message and sends an AR message indicating the 770 termination cause. The server replies to the AR message with an AA 771 message. After receiving the AA message sent by the server, the 772 client sends remaining accounting information with the Accounting- 773 Request message. The server replies with the Accounting-Response 774 message. 776 9.2. RADIUS authentication, authorization and management of a QoS- 777 enabled access session 779 QoS enabled NAS Home 780 RADIUS client RADIUS server 781 | | 782 | Access-Request/....QSPEC(QoS Available) .../ | 783 v----------------------------------------------->| 784 * | 785 * Multiple | 786 Authentication *<==============================================>| 787 process * Access-Request/Access-Challenge Exchange | 788 * | 789 * | 790 Access granted; * Access-Accept/...QSPEC(user-profile QoS).../| 791 install QoS v<-----------------------------------------------| 792 | | 793 | Accounting-Request/...QSPEC(installed QoS)../ | 794 |----------------------------------------------->| 795 | Accounting-Response/.../ | 796 |<-----------------------------------------------| 797 | | 798 | | 799 QoS-Request | Access-Request/Auth-ONLY, QSPEC, QoS-Flow-ID/ | 800 --------------->|----------------------------------------------->| 801 | Access-Response/Auth-ONLY, QSPEC, QoS-Flow-ID/| 802 QoS authorized; *<-----------------------------------------------| 803 install QoS for | | 804 QoS-Flow-ID | | 805 | Accounting-Request/Interim,.../ | 806 |----------------------------------------------->| 807 | Accounting-Response/.../ | 808 |<-----------------------------------------------| 809 .............................................................. 810 | | 811 * | 812 QoS-Flow-ID authz.lifetime expires | 813 Delete QoS for QoS-Flow-ID | 814 | | 815 | Accounting-Request/Interim,.../ | 816 |----------------------------------------------->| 817 | Accounting-Response/.../ | 818 |<-----------------------------------------------| 819 .............................................................. 820 | | 821 | CoA-Request /Auth-ONLY,QSPEC.../ | 822 |<-----------------------------------------------| 823 | CoA-NACK/Auth-ONLY,"Request-Initiated"/ | 824 |----------------------------------------------->| 825 | Access-Request/Auth-ONLY,QSPEC.../ | 826 |----------------------------------------------->| 827 | Access-Accept/Auth-ONLY,QSPEC(New QoS).../ | 828 Install QoS *<-----------------------------------------------| 829 | | 830 | Accounting-Request/...QSPEC(installed QoS)../ | 831 |----------------------------------------------->| 832 | Accounting-Response/.../ | 833 |<-----------------------------------------------| 835 This example shows the interaction between a QoS enabled NAS and a 836 Home AAA server. This example aims to show a QoS-enabled access 837 session. The NAS performs authorization of the QoS-provisioned flows 838 as part of the user's access session. 840 The NAS performs initial authentication and authorization of the end 841 user for an access session. This process MAY take several Access- 842 Request / Access-Challenge message exchanges. By including the QSPEC 843 attribute, the RADIUS server provides a description of the QoS 844 parameters of the user access session. The NAS allocates certain QoS 845 resources according to the QoS parameters provided by the RADIUS 846 server and currently available QoS resources. The NAS initiates an 847 accounting session by sending the Accounting-Request message in which 848 it reports the actually allocated QoS resources for the access 849 session. The server replies with an Accounting-Response message that 850 MAY include instructions for further handling of the accounting 851 session, such as the Acc-Interim-Period attribute. 853 Later, when the NAS intercepts a QoS signaling message sent from the 854 end host an Authorize-ONLY Access-Request message is triggered and 855 sent to the RADIUS server. It includes the description of the 856 requested QoS resources in the QSPEC attribute. Optionally, an 857 identifier of the flow that should receive the requested QoS 858 treatment is included into the Access-Request message. The RADIUS 859 server (in the user's home domain) validates the QoS request and 860 replies with Authorize-ONLY Access-Accept message. The message 861 includes a QSPEC attribute with description of the authorized QoS 862 parameters and the duration of authorization. An identifier of the 863 flow that should receive the requested QoS is also provided. The 864 RADIUS client will install a QoS reservation based on the provided 865 QoS parameters for that flow and sends an Accounting-Request message 866 reporting the new QoS session. The server replies with an 867 Accounting-Response message. 869 In this example, the authorization lifetime of the QoS-provisioned 870 flow expires. The NAS releases the reserved QoS resources allocated 871 for the flow when the authorization has expired. In addition, the 872 NAS sends an Accounting-Request message to the RADIUS server, 873 indicating the stop of QoS provisioning for the flow. 875 If the Home AAA server decides to change QoS parameters for the 876 user's access session it sends an Authorize-ONLY Change-of- 877 Authorization-Request message to the RADIUS client, identifying the 878 affected access session. The NAS replies with a CoA-NACK message 879 indicating that an Access-Request has to be generated. The 880 Authorize-ONLY Access-Request message contains the QSPEC attribute 881 with the QoS resources currently available at the NAS. The RADIUS 882 server replies with the Authorize-ONLY Access-Accept message with a 883 QSPEC attribute containing the new QoS parameters that should be 884 provided to the user's session. The NAS allocates certain QoS 885 resources according to the QoS parameters provided by the RADIUS 886 server and the currently available QoS resources. It sends an 887 Accounting-Request message in which it reports the actual allocated 888 QoS resources for the access session. The server replies with an 889 Accounting-Response message. 891 10. Security Considerations 893 For this extension to RADIUS protocol the security considerations 894 defined in RFC2865 [1], RFC2866 [2], RFC2869 [3] and RFC3576 [4] are 895 applicable. Furthermore, the security of the QoS signaling protocol 896 and the QoS authorization framework must be considered in the 897 evaluation of the security properties. 899 [Editor's Note: A more detailed treatment will be provided in a 900 future document version.] 902 11. Acknowledgments 904 We would like to thank Pete McCann and Franck Alfano for their work 905 on the DIAMETER QoS application. 907 12. References 909 12.1. Normative References 911 [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 912 Authentication Dial In User Service (RADIUS)", RFC 2865, 913 June 2000. 915 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 917 [3] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 918 RFC 2869, June 2000. 920 [4] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 921 "Dynamic Authorization Extensions to Remote Authentication Dial 922 In User Service (RADIUS)", RFC 3576, July 2003. 924 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 925 Levels", March 1997. 927 [6] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 928 Authorization Policy Element", RFC 3520, April 2003. 930 [7] Shenker, S. and J. Wroclawski, "General Characterization 931 Parameters for Integrated Service Network Elements", RFC 2215, 932 September 1997. 934 [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 935 Weiss, "An Architecture for Differentiated Services", RFC 2475, 936 December 1998. 938 [9] Le Faucheur, F. and W. Lai, "Requirements for Support of 939 Differentiated Services-aware MPLS Traffic Engineering", 940 RFC 3564, July 2003. 942 [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 943 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 944 June 2005. 946 [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 947 "Diameter Base Protocol", RFC 3588, September 2003. 949 12.2. Informative References 951 [12] Alfano, F., "Diameter Quality of Service Application", 952 draft-tschofenig-dime-diameter-qos-00 (work in progress), 953 March 2006. 955 [13] Alfano, F., "Requirements for a QoS AAA Protocol", 956 draft-alfano-aaa-qosreq-01 (work in progress), October 2003. 958 [14] Congdon, P., "RADIUS Filter Rule Attribute", 959 draft-ietf-radext-filter-00 (work in progress), June 2006. 961 [15] Lior, A., "Prepaid extensions to Remote Authentication Dial-In 962 User Service (RADIUS)", draft-lior-radius-prepaid-extensions-10 963 (work in progress), February 2006. 965 [16] Ash, J., "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-10 966 (work in progress), June 2006. 968 [17] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using 969 Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in 970 progress), May 2005. 972 [18] Peterson, J., "Trait-based Authorization Requirements for the 973 Session Initiation Protocol (SIP)", 974 draft-ietf-sipping-trait-authz-02 (work in progress), 975 January 2006. 977 [19] Tschofenig, H., "SIP SAML Profile and Binding", 978 draft-ietf-sip-saml-00 (work in progress), June 2006. 980 Authors' Addresses 982 Hannes Tschofenig 983 Siemens 984 Otto-Hahn-Ring 6 985 Munich, Bavaria 81739 986 Germany 988 Email: Hannes.Tschofenig@siemens.com 989 URI: http://www.tschofenig.com 991 Allison Mankin 992 1025 Vermont Avenue 993 Washington, DC 20005 994 US 996 Phone: +1 301-728-7199 (mobile) 997 Email: mankin@psg.com 998 URI: http://www.psg.com/~mankin/ 1000 Tseno Tsenov 1001 Sofia, 1002 Bulgaria 1004 Email: tseno.tsenov@mytum.de 1006 Avi Lior 1007 Bridgewater Systems Corporation 1008 303 Terry Fox Drive 1009 Ottawa, Ontario K2K 3J1 1010 Canada 1012 Phone: +1 613-591-6655 1013 Email: avi@bridgewatersystems.com 1015 Intellectual Property Statement 1017 The IETF takes no position regarding the validity or scope of any 1018 Intellectual Property Rights or other rights that might be claimed to 1019 pertain to the implementation or use of the technology described in 1020 this document or the extent to which any license under such rights 1021 might or might not be available; nor does it represent that it has 1022 made any independent effort to identify any such rights. Information 1023 on the procedures with respect to rights in RFC documents can be 1024 found in BCP 78 and BCP 79. 1026 Copies of IPR disclosures made to the IETF Secretariat and any 1027 assurances of licenses to be made available, or the result of an 1028 attempt made to obtain a general license or permission for the use of 1029 such proprietary rights by implementers or users of this 1030 specification can be obtained from the IETF on-line IPR repository at 1031 http://www.ietf.org/ipr. 1033 The IETF invites any interested party to bring to its attention any 1034 copyrights, patents or patent applications, or other proprietary 1035 rights that may cover technology that may be required to implement 1036 this standard. Please address the information to the IETF at 1037 ietf-ipr@ietf.org. 1039 Disclaimer of Validity 1041 This document and the information contained herein are provided on an 1042 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1043 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1044 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1045 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1046 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1047 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1049 Copyright Statement 1051 Copyright (C) The Internet Society (2006). This document is subject 1052 to the rights, licenses and restrictions contained in BCP 78, and 1053 except as set forth therein, the authors retain all their rights. 1055 Acknowledgment 1057 Funding for the RFC Editor function is currently provided by the 1058 Internet Society.