idnits 2.17.00 (12 Aug 2021) /tmp/idnits26633/draft-tschofenig-radext-qos-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1040. ** 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 == Line 970 has weird spacing: '... domain prici...' -- 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 (October 22, 2005) is 6054 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 470 == Unused Reference: '11' is defined on line 941, 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-04 == Outdated reference: A later version (-22) exists of draft-lior-radius-prepaid-extensions-08 == 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 (-05) exists of draft-tschofenig-sip-saml-04 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: April 25, 2006 A. Mankin 5 Shinkuro, Inc 6 T. Tsenov 7 Siemens 8 A. Lior 9 Bridgewater Systems 10 October 22, 2005 12 RADIUS Quality of Service Support 13 draft-tschofenig-radext-qos-02.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 April 25, 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 . . . . . . . . . . . . . . . . . . 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 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 goals, 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 attributes containing a QoS 297 description and flow identification (see Section 7) are used in the 298 accounting session for reporting the status and parameters of the 299 provided QoS. The definition of new accounting attributes may be 300 necessary. This aspect is for further study. 302 After a successful QoS authorization the RADIUS client starts the 303 corresponding accounting session by sending the Accounting-Request 304 message. This message SHOULD contain necessary attributes to bind 305 the current accounting session to the reported QoS session. 306 Class(25) and Acc-Session-ID(44) attributes SHOULD be used according 307 to [1] and [2]. The RADIUS server responds with an Accounting- 308 Response message after successfully processing the Accounting-Request 309 message. The Accounting-Response message MAY contain instructions 310 for managing the accounting session, such as the Acct-Interim- 311 Interval(85) attribute. 313 After every successful re-authorization procedure the RADIUS client 314 SHOULD re-initiate accounting message exchange. 316 For indication of session termination the RADIUS client SHOULD 317 initiate a final exchange of accounting messages with the RADIUS 318 server. 320 7. Attributes 322 This section defines three categories of attributes: 324 o QSPEC parameters describing requested/authorized QoS 326 o Identification of the flow that should receive QoS described in 327 QSPEC 329 o Attributes required to carry authorization information (e.g., 330 authorization tokens as specified in [6]) 332 7.1. QSPEC Attribute 334 The generic QoS description is taken from QoS-NSLP QSpec Template 335 [15] which aims to support QoS parameters for all QoS reservations 336 and is independent of a specific QoS model (QOSM). The QSPEC 337 template format is organized into QoS Control information, Requested, 338 Reserved, Available and Minimum objects. Each of the objects 339 contains a number of QSPEC parameters. For QoS authorization 340 purposes only part of the parameters SHOULD be used, e.g., mainly 341 those included into the QoS Desired and some of those included into 342 QoS Control information objects. In addition information for 343 duration of the authorized QoS SHOULD be provided. 345 QSPEC parameters and QoS authorization session management parameters 346 are included as subtypes into the QSPEC attribute. Subtypes not used 347 are omitted in the message. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | QoSM ID | SUB-TYPE 2 | LENGTH | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Excess Treatment | SUB-TYPE 3 | LENGTH | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Bandwidth | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | SUB-TYPE 4 | LENGTH | Token Bucket Rate [r] | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Token Bucket Rate [r] | SUB-TYPE 5 | LENGTH | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Token Bucket Size [b] | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | SUB-TYPE 6 | LENGTH | Peak Data Rate [p] | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Peak Data Rate [p] | SUB-TYPE 7 | LENGTH | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Minimum Policed Unit [m] | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | SUB-TYPE 8 | LENGTH | Maximum Packet Size [MTU] | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Maximum Packet Size [MTU] | SUB-TYPE 9 | LENGTH | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | PHB Class | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | SUB-TYPE 10 | LENGTH |Y.1541 QoSClass| SUB-TYPE 11 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | LENGTH |DSTE Class Type| SUB-TYPE 12 | LENGTH | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Preemption Priority | SUB-TYPE 13 | LENGTH | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Defending Priority | SUB-TYPE 14 | LENGTH | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Reservation Priority | SUB-TYPE 15 | LENGTH | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Authorization lifetime | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | SUB-TYPE 16 | LENGTH | Authorized Volume | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Authorized Volume | SUB-TYPE 17 | LENGTH | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Application Server ID | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Type: Value of QSPEC 399 Length: variable, greater than 8 401 String: The String value MUST be encoded as follows: 403 Sub-Type (=1): Sub-Type for QoS-Model ID attribute 405 Length : Length of QoS-Model ID attribute (= 6 octets) 407 QoS-Model ID (QoSM ID): 409 Identifier of the used QoS signaling model.[15] 411 Sub-Type (=2): Sub-Type for Excess Treatment attribute 413 Length : Length of Excess Treatment attribute (= 3 octets) 415 Excess Treatment: 417 Description of how the excess traffic to be processed (out-of- 418 profile traffic). Excess traffic MAY be dropped, shaped and/or 419 remarked. 421 Sub-Type (=3): Sub-Type for Bandwidth attribute 423 Length : Length of Bandwidth attribute (= 6 octets) 425 Bandwidth: 427 Link bandwidth needed by a flow. 429 Sub-Type (=4): Sub-Type for Token Bucket Rate attribute 431 Length : Length of Token Bucket Rate attribute (= 6 octets) 433 Token Bucket Rate: 435 Rate is a Token Bucket parameter as specified in [7]. 437 Sub-Type (=5): Sub-Type for Token Bucket Size attribute 439 Length : Length of Token Bucket Size attribute (= 6 octets) 441 Token Bucket Size: 443 Size is a Token Bucket parameter as specified in [7]. 445 Sub-Type (=6): Sub-Type for Peak Data Rate attribute 447 Length : Length of Peak Data Rate attribute (= 6 octets) 449 Token Bucket Size: 451 Peak Data Rate is a Token Bucket parameter as specified in [7]. 453 Sub-Type (=7): Sub-Type for Minimum Policed Unit attribute 455 Length : Length of Minimum Policed Unit attribute (= 6 456 octets) 458 Minimum Policed Unit: 460 Minimum Policed Unit is a Token Bucket parameter as specified in 461 [7]. 463 Sub-Type (=8): Sub-Type for Maximum Packet Size [MTU] attribute 465 Length : Length of Maximum Packet Size [MTU] attribute (= 6 466 octets) 468 Maximum Packet Size [MTU]: 470 Maximum Packet Size [MTU] is a Token Bucket parameter as specified 471 in [7]. 473 Sub-Type (=9): Sub-Type for PHB class attribute 475 Length : Length of PHB class attribute (= 6 octets) 477 PHB class: 479 Indicates the QoS class used in DiffServ per-hop behavior QoS 480 signaling [8]. 482 Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute 484 Length : Length of Y.1541 QoS class attribute (= 3 octets) 486 Y.1541 QoS class: 488 Indicates the Y.1541 QoS Class [16]. 490 Sub-Type (=11): Sub-Type for DSTE class attribute 492 Length : Length of DSTE class attribute (= 3 octets) 494 DSTE Class: 496 Indicates the QoS class used in DiffServ-enabled MPLS traffic 497 engineering.[9]. 499 Sub-Type (=12): Sub-Type for Preemption Priority attribute 501 Length : Length of Preemption Priority attribute (= 4 octets) 503 Preemption Priority: 505 Parameter used in the process of differentiation of flows. 506 Indicates the priority of the new flow compared with the defending 507 priority of previously admitted flows. 509 Sub-Type (=13): Sub-Type for Defending Priority attribute 511 Length : Length of Defending Priority attribute (= 4 octets) 513 Defending Priority: 515 Parameter used in the process of differentiation of flows. It is 516 compared with the preemption priority of new flows. 518 Sub-Type (=14): Sub-Type for Reservation Priority attribute 520 Length : Length of Reservation Priority attribute (= 4 521 octets) 523 Reservation Priority: 525 Parameter used in the process of differentiation of flows for 526 emergency services, ETS, E911, etc., and assigning them a higher 527 admission priority. [Editor's Note: Reference to be included 528 here.] 530 Sub-Type (=15): Sub-Type for Authorization lifetime attribute 532 Length : Length of Authorization lifetime attribute (= 6 533 octets) 534 Authorization lifetime: 536 The parameter indicates the duration of the authorized QoS 537 provisioning. 539 Sub-Type (=16): Sub-Type for Authorized volume attribute 541 Length : Length of Authorized volume attribute (= 6 octets) 543 Authorized volume: 545 The parameter indicates the data volume that should receive the 546 authorized QoS. 548 Sub-Type (=17): Sub-Type for Application server ID attribute 550 Length : Length of Authorized volume attribute (IPv4 = 6 551 octets, IPv6= 18 octets) 553 Application server ID: 555 Application server ID indicates the address of the authorizing 556 Application Server. 558 Provided QSPEC parameters list is not exhaustive and SHOULD be 559 updated according to [15]. 561 7.2. Flow Identification 563 Depending on the deployment and used QoS signaling protocol, 564 identification of the flow that SHOULD receive authorized QoS takes a 565 different format. Signaling session Identifier (NSIS) or flow 566 identifier and explicit filter specifications are used. The 567 Attribute QoS-Flow-ID is designated to encapsulate such information. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Signaling Session ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | SUB-TYPE 2 | LENGTH | Flow-ID | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | SUB-TYPE 3 | LENGTH | Flow-Status | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Type : Value of QoS-Flow-ID 583 Length: variable, greater than 8 585 String: The String value MUST be encoded as follows: 587 Sub-Type (=1): Signaling Session ID 589 Length : Length of Signaling Session ID attribute (= 6 590 octets) 592 Signaling Session ID: 594 With the NSIS framework [10], a signaling session ID is a unique 595 identifier of the signaling session that remains unchanged for the 596 entire lifetime of the session. It is locally mapped to the 597 specific flow identifiers. 599 Sub-Type (=2): Flow-ID 601 Length : Length of Flow-ID attribute 603 Flow-ID: 605 The Flow-ID attribute is an application assigned identifier for an 606 IP flow that identifies the IP flow in an application layer 607 session (e.g., SIP/SDP). It might be used in conjunction with a 608 QoS-Filter-Rule [17] attribute for provision of flow description 609 and identification. Note that more than one Flow-ID sub- 610 attributes MAY be present in the QoS-Flow-Id attribute. 612 Sub-Type (=3): Flow-State 614 Length : Length of Flow-State attribute 616 Flow-State: 618 The Flow-State attribute indicates the action that MUST be 619 performed on the flow(s) to which QoS authorization message 620 exchange applies as identified by the QoS-Flow-Id. The flow could 621 be enabled (i.e., it is allowed to trespass the QoS element) and 622 it is treated according to the QoS described in the QSPEC 623 attribute. The flow could be disabled, i.e., the QoS described in 624 the QSPEC could be reserved but additional authorization approval 625 by the Authorizing entity is required in order for the flow to 626 receive this QoS treatment and to trespass the QoS element. 628 In the current approach, there is a one to one binding between a 629 QSPEC and a QoS-Flow-Id attribute in a RADIUS message. It is for 630 further study whether different QoS authorization information (i.e., 631 multiple QSPEC attributes) for different groups of flows (i.e., 632 multiple QoS-Flow-Id attributes) might need to be carried in a single 633 RADIUS message. 635 7.3. Authorization Objects 637 Depending on the deployment, different attributes MAY be used as an 638 input for computing the QoS authorization decision by the Authorizing 639 entity. In addition to the credentials of the end host, requesting 640 QoS reservation (e.g., User-Name(1) attribute), an authorization 641 token MAY be used. This occurs in a deployment scenario, where the 642 QoS parameters are negotiated as part of an application layer 643 signaling exchange and where the authorization decision at this 644 application layer exchange needs to be associated with the 645 authorization of the QoS reservation of the QoS signaling exchange. 646 The QoS-Authorization-Data attribute is designated to encapsulate 647 such information. 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Authorization-Token | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Type : Value of QoS-Authorization-Data 659 Length: variable, greater than 8 661 String: The String value MUST be encoded as follows: 663 Sub-Type (=1): Authorization-Token 665 Length : Length of Authorization-Token attribute 667 Authorization-Token: 669 The Authorization-Token sub-attribute is a container that 670 encapsulates an authorization token received via the QoS signaling 671 message typically sent by the end host. The token is generated by 672 the Authorizing entity during the application layer signaling 673 exchange and identifies the application service session, for which 674 the QoS reservation request applies. A possible structure for the 675 authorization token is proposed in context of RSVP [6], with the 676 Open Settlement Protocol (OSP) [18] or using SAML as outlined in 677 [19] and [20]. The structure of the token is considered to be out 678 of the scope for this document. 680 8. Diameter RADIUS Interoperability 682 In deployments where RADIUS clients communicate with DIAMETER servers 683 or DIAMETER clients communicate with RADIUS servers then a 684 translation agent will be deployed and operate. The DIAMETER-QoS 685 specification [12] provides a natural candidate for mapping the 686 RADIUS QoS related AVPs to DIAMETER AVPs and messages. 688 9. Examples 690 The following diagrams show RADIUS protocol interactions for 691 different scenarios and deployment architectures. 693 9.1. RADIUS authorization of a QoS signaling reservation request 694 RADIUS RADIUS 695 Client Server 696 -----------> | | 697 QoS | Access-Request/UserID, QSPEC/ | 698 reservation |----------------------------------------------->| 699 request | | 700 | Access-Accept/QSPEC/ | 701 |<-----------------------------------------------| 702 | | 703 Start |Accounting-Request/Start, Acc-Session-ID.../ | 704 Accounting |----------------------------------------------->| 705 | Accounting-Response/...Acc-Interim-Period.../ | 706 |<-----------------------------------------------| 707 | | 708 Authorization| | 709 LifeTime | | 710 Expires: | | 711 Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ | 712 Authorization|----------------------------------------------->| 713 | Access-Accept/ Auth-ONLY, QSPEC/ | 714 |<-----------------------------------------------| 715 | Accounting-Request/Interim, Acc-Session-ID./ | 716 |----------------------------------------------->| 717 | Accounting-Response/...Acc-Interim-Period.../ | 718 |<-----------------------------------------------| 719 ..................... 720 | Session 721 | Termination 722 | initiated 723 | by 724 | server 725 | Disconnect-Request/Auth-ONLY, .../ <------ 726 |<-----------------------------------------------| 727 | Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ | 728 |----------------------------------------------->| 729 | Access-Request/Auth-ONLY,... | 730 | Acc-Terminate-Cause="Admin-Reset"/| 731 |----------------------------------------------->| 732 | Access-Accept | 733 |<-----------------------------------------------| 734 Accounting | Accounting-Request/Final,Acc-Session-ID./ | 735 end |----------------------------------------------->| 736 | Accounting-Response /Final,.../ | 737 |<-----------------------------------------------| 739 This example shows the protocol exchange between the RADIUS client 740 and the RADIUS server. An incoming QoS reservation request received 741 at the QoS policy aware node (i.e., RADIUS client) invokes the 742 transmission of a Access-Request message (AR) to the RADIUS server. 743 This message contains the requested QoS resources in a QSPEC 744 attribute along with user identification and authentication 745 information. After the request is successfully authenticated and 746 authorized, the RADIUS server replies with a Access-Accept message 747 (AA), which grants a reservation for a certain amount of resources 748 (as included in the QSPEC attribute). After the successful exchange 749 of the AR/AA messages, the RADIUS client starts an accounting session 750 by sending an Accounting-Request message. The server replies with an 751 Accounting-Response message that MAY include instructions for further 752 handling of the accounting session, such as the Acc-Interim-Period 753 attribute. 755 The client-side re-authorization caused by expiration of the 756 authorization lifetime initiates an Authorize-ONLY Access-Request / 757 Access-Accept message exchange. After a successful re-authorization 758 an Accounting-Request message SHOULD be sent to indicate the new 759 authorization parameters. The server replies with an Accounting- 760 Response message. 762 In this example, the RADIUS server initiates a session termination. 763 It therefore sends a Disconnect-Request message. The client responds 764 with a Disconnect-NACK message and sends an AR message indicating the 765 termination cause. The server replies to the AR message with an AA 766 message. After receiving the AA message sent by the server, the 767 client sends remaining accounting information with the Accounting- 768 Request message. The server replies with the Accounting-Response 769 message. 771 9.2. RADIUS authentication, authorization and management of a QoS- 772 enabled access session 774 QoS enabled NAS Home 775 RADIUS client RADIUS server 776 | | 777 | Access-Request/....QSPEC(QoS Available) .../ | 778 v----------------------------------------------->| 779 * | 780 * Multiple | 781 Authentication *<==============================================>| 782 process * Access-Request/Access-Challenge Exchange | 783 * | 784 * | 785 Access granted; * Access-Accept/...QSPEC(user-profile QoS).../| 786 install QoS v<-----------------------------------------------| 787 | | 788 | Accounting-Request/...QSPEC(installed QoS)../ | 789 |----------------------------------------------->| 790 | Accounting-Response/.../ | 791 |<-----------------------------------------------| 792 | | 793 | | 794 QoS-Request | Access-Request/Auth-ONLY, QSPEC, QoS-Flow-ID/ | 795 --------------->|----------------------------------------------->| 796 | Access-Response/Auth-ONLY, QSPEC, QoS-Flow-ID/| 797 QoS authorized; *<-----------------------------------------------| 798 install QoS for | | 799 QoS-Flow-ID | | 800 | Accounting-Request/Interim,.../ | 801 |----------------------------------------------->| 802 | Accounting-Response/.../ | 803 |<-----------------------------------------------| 804 .............................................................. 805 | | 806 * | 807 QoS-Flow-ID authz.lifetime expires | 808 Delete QoS for QoS-Flow-ID | 809 | | 810 | Accounting-Request/Interim,.../ | 811 |----------------------------------------------->| 812 | Accounting-Response/.../ | 813 |<-----------------------------------------------| 814 .............................................................. 815 | | 816 | CoA-Request /Auth-ONLY,QSPEC.../ | 817 |<-----------------------------------------------| 818 | CoA-NACK/Auth-ONLY,"Request-Initiated"/ | 819 |----------------------------------------------->| 820 | Access-Request/Auth-ONLY,QSPEC.../ | 821 |----------------------------------------------->| 822 | Access-Accept/Auth-ONLY,QSPEC(New QoS).../ | 823 Install QoS *<-----------------------------------------------| 824 | | 825 | Accounting-Request/...QSPEC(installed QoS)../ | 826 |----------------------------------------------->| 827 | Accounting-Response/.../ | 828 |<-----------------------------------------------| 830 This example shows the interaction between a QoS enabled NAS and a 831 Home AAA server. This example aims to show a QoS-enabled access 832 session. The NAS performs authorization of the QoS-provisioned flows 833 as part of the user's access session. 835 The NAS performs initial authentication and authorization of the end 836 user for an access session. This process MAY take several Access- 837 Request / Access-Challenge message exchanges. By including the QSPEC 838 attribute, the RADIUS server provides a description of the QoS 839 parameters of the user access session. The NAS allocates certain QoS 840 resources according to the QoS parameters provided by the RADIUS 841 server and currently available QoS resources. The NAS initiates an 842 accounting session by sending the Accounting-Request message in which 843 it reports the actually allocated QoS resources for the access 844 session. The server replies with an Accounting-Response message that 845 MAY include instructions for further handling of the accounting 846 session, such as the Acc-Interim-Period attribute. 848 Later, when the NAS intercepts a QoS signaling message sent from the 849 end host an Authorize-ONLY Access-Request message is triggered and 850 sent to the RADIUS server. It includes the description of the 851 requested QoS resources in the QSPEC attribute. Optionally, an 852 identifier of the flow that should receive the requested QoS 853 treatment is included into the Access-Request message. The RADIUS 854 server (in the user's home domain) validates the QoS request and 855 replies with Authorize-ONLY Access-Accept message. The message 856 includes a QSPEC attribute with description of the authorized QoS 857 parameters and the duration of authorization. An identifier of the 858 flow that should receive the requested QoS is also provided. The 859 RADIUS client will install a QoS reservation based on the provided 860 QoS parameters for that flow and sends an Accounting-Request message 861 reporting the new QoS session. The server replies with an 862 Accounting-Response message. 864 In this example, the authorization lifetime of the QoS-provisioned 865 flow expires. The NAS releases the reserved QoS resources allocated 866 for the flow when the authorization has expired. In addition, the 867 NAS sends an Accounting-Request message to the RADIUS server, 868 indicating the stop of QoS provisioning for the flow. 870 If the Home AAA server decides to change QoS parameters for the 871 user's access session it sends an Authorize-ONLY Change-of- 872 Authorization-Request message to the RADIUS client, identifying the 873 affected access session. The NAS replies with a CoA-NACK message 874 indicating that an Access-Request has to be generated. The 875 Authorize-ONLY Access-Request message contains the QSPEC attribute 876 with the QoS resources currently available at the NAS. The RADIUS 877 server replies with the Authorize-ONLY Access-Accept message with a 878 QSPEC attribute containing the new QoS parameters that should be 879 provided to the user's session. The NAS allocates certain QoS 880 resources according to the QoS parameters provided by the RADIUS 881 server and the currently available QoS resources. It sends an 882 Accounting-Request message in which it reports the actual allocated 883 QoS resources for the access session. The server replies with an 884 Accounting-Response message. 886 10. Security Considerations 888 For this extension to RADIUS protocol the security considerations 889 defined in RFC2865 [1], RFC2866 [2], RFC2869 [3] and RFC3576 [4] are 890 applicable. Furthermore, the security of the QoS signaling protocol 891 and the QoS authorization framework must be considered in the 892 evaluation of the security properties. 894 [Editor's Note: A more detailed treatment will be provided in a 895 future document version.] 897 11. Acknowledgments 899 We would like to thank Pete McCann and Franck Alfano for their work 900 on the DIAMETER QoS application. 902 12. References 904 12.1. Normative References 906 [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 907 Authentication Dial In User Service (RADIUS)", RFC 2865, 908 June 2000. 910 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 912 [3] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 913 RFC 2869, June 2000. 915 [4] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 916 "Dynamic Authorization Extensions to Remote Authentication Dial 917 In User Service (RADIUS)", RFC 3576, July 2003. 919 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 920 Levels", March 1997. 922 [6] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 923 Authorization Policy Element", RFC 3520, April 2003. 925 [7] Shenker, S. and J. Wroclawski, "General Characterization 926 Parameters for Integrated Service Network Elements", RFC 2215, 927 September 1997. 929 [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 930 Weiss, "An Architecture for Differentiated Services", RFC 2475, 931 December 1998. 933 [9] Le Faucheur, F. and W. Lai, "Requirements for Support of 934 Differentiated Services-aware MPLS Traffic Engineering", 935 RFC 3564, July 2003. 937 [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 938 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 939 June 2005. 941 [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 942 "Diameter Base Protocol", RFC 3588, September 2003. 944 12.2. Informative References 946 [12] Alfano, F., "Diameter Quality of Service Application", 947 draft-alfano-aaa-qosprot-04 (work in progress), September 2005. 949 [13] Alfano, F., "Requirements for a QoS AAA Protocol", 950 draft-alfano-aaa-qosreq-01 (work in progress), October 2003. 952 [14] Lior, A., "PrePaid Extensions to Remote Authentication Dial-In 953 User Service (RADIUS)", draft-lior-radius-prepaid-extensions-08 954 (work in progress), July 2005. 956 [15] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06 957 (work in progress), October 2005. 959 [16] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using 960 Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in 961 progress), May 2005. 963 [17] Congdon, P., "RADIUS Extensions for IEEE 802", 964 draft-congdon-radext-ieee802-03 (work in progress), 965 February 2005. 967 [18] European Telecommunications Standards Institute, 968 "Telecommunications and Internet Protocol Harmonization Over 969 Networks (TIPHON); Open Settlement Protocol (OSP) for Inter- 970 domain pricing, authorization, and usage exchange", TS 101 971 321. 973 [19] Peterson, J., "Trait-based Authorization Requirements for the 974 Session Initiation Protocol (SIP)", 975 draft-ietf-sipping-trait-authz-01 (work in progress), 976 February 2005. 978 [20] Tschofenig, H., "Using SAML for SIP", 979 draft-tschofenig-sip-saml-04 (work in progress), July 2005. 981 Authors' Addresses 983 Hannes Tschofenig 984 Siemens 985 Otto-Hahn-Ring 6 986 Munich, Bavaria 81739 987 Germany 989 Email: Hannes.Tschofenig@siemens.com 990 URI: http://www.tschofenig.com 992 Allison Mankin 993 Shinkuro, Inc 994 1025 Vermont Avenue 995 Washington, DC 20005 996 US 998 Phone: +1 301-728-7199 (mobile) 999 Email: mankin@psg.com 1001 Tseno Tsenov 1002 Siemens 1003 Otto-Hahn-Ring 6 1004 Munich, Bayern 81739 1005 Germany 1007 Email: tseno.tsenov@mytum.de 1009 Avi Lior 1010 Bridgewater Systems Corporation 1011 303 Terry Fox Drive 1012 Ottawa, Ontario K2K 3J1 1013 Canada 1015 Phone: +1 613-591-6655 1016 Email: avi@bridgewatersystems.com 1018 Intellectual Property Statement 1020 The IETF takes no position regarding the validity or scope of any 1021 Intellectual Property Rights or other rights that might be claimed to 1022 pertain to the implementation or use of the technology described in 1023 this document or the extent to which any license under such rights 1024 might or might not be available; nor does it represent that it has 1025 made any independent effort to identify any such rights. Information 1026 on the procedures with respect to rights in RFC documents can be 1027 found in BCP 78 and BCP 79. 1029 Copies of IPR disclosures made to the IETF Secretariat and any 1030 assurances of licenses to be made available, or the result of an 1031 attempt made to obtain a general license or permission for the use of 1032 such proprietary rights by implementers or users of this 1033 specification can be obtained from the IETF on-line IPR repository at 1034 http://www.ietf.org/ipr. 1036 The IETF invites any interested party to bring to its attention any 1037 copyrights, patents or patent applications, or other proprietary 1038 rights that may cover technology that may be required to implement 1039 this standard. Please address the information to the IETF at 1040 ietf-ipr@ietf.org. 1042 Disclaimer of Validity 1044 This document and the information contained herein are provided on an 1045 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1046 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1047 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1048 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1049 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1050 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1052 Copyright Statement 1054 Copyright (C) The Internet Society (2005). This document is subject 1055 to the rights, licenses and restrictions contained in BCP 78, and 1056 except as set forth therein, the authors retain all their rights. 1058 Acknowledgment 1060 Funding for the RFC Editor function is currently provided by the 1061 Internet Society.