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