Network Working Group A. Lior Internet-Draft Bridgewater Systems Expires: August 16, 2005 F. Adrangi Intel P. Congdon C. Black ProCurve Networking Business F. Bari Cingular Wireless February 12, 2005 Network Bandwidth Parameters for Remote Authentication Dial In User Service (RADIUS). draft-lior-radius-bandwidth-capability-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Lior, et al. Expires August 16, 2005 [Page 1] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 This document describes bandwidth profile parameters and a protocol framework that enables an AAA server to specify the parameters that should be allocated by the access network for duration of an authorized user session. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements language . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Bandwidth Parameters . . . . . . . . . . . . . . . . . . . 4 2.1.1 Egress Bandwidth . . . . . . . . . . . . . . . . . . . 4 2.1.2 Ingress Bandwidth . . . . . . . . . . . . . . . . . . 4 2.1.3 Bandwidth Profile Id . . . . . . . . . . . . . . . . . 4 2.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 Static Bandwidth Allocation . . . . . . . . . . . . . 6 2.2.2 Dynamic Bandwidth Allocation . . . . . . . . . . . . . 8 2.3 Diameter RADIUS Interoperability . . . . . . . . . . . . . 11 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative references . . . . . . . . . . . . . . . . . . . 15 8.2 Informative references . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 17 Lior, et al. Expires August 16, 2005 [Page 2] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 1. Introduction The bandwidth that a user is authorized within an access network can be a result of the access network capabilities based on its architecture and access technology, and the type of user subscription to the home network (e.g., gold, silver, bronze user types). This document describes a simple protocol framework that enables an access network to advertise its network bandwidth capabilities that it can allocate for a given user session. And, it enables the home network to indicate the desired network bandwidth for the user session within the access network. Note the access network can be the home network, this is not strictly a roaming problem. That is, even though the NAS is located in the home network it still would need to know what bandwidth to allocate to the user session. Session bandwidth can be allocated during initial authentication authorization of the session. It is also desirable to change the bandwidth mid-session. For example, the user may want to purchase additional bandwidth to download a large file. This document enables operators to dynamically modify the bandwidth allocation for a user session. In certain conditions bandwidth can be allocated to a user session by assigning a preconfigured bandwidth profile to the user session. In this case, the home network and the access network could pre-arrange bandwidth profiles such as "gold", "silver", and "bronze" in the NAS. The AAA servers, would then communicate which bandwidth profile to apply to the user. The advantage of this scheme is that it allows for complex bandwidth profiles to be provisioned for the user session. A single bandwidth profile could be provisioned to handle different bandwidth treatments for different flows. Such as bandwidth for best effort traffic and bandwidth for VoIP traffic. The disadvantage of communicating just a bandwidth profile id to the NAS is in roaming situations where this does not scale well. To address these needs, this document defines new AAA attributes that can be used for the following: o Conveying to the home network the available bandwidth at the access network that may be allocate to a given user session. o Conveying the access network the desired bandwidth that should be allocated by the access network for the duration of the user session. These attributes are also used for reporting the allocated bandwidth in RADIUS accounting packets [RFC2866]. The attributes are described for the RADIUS protocol[RFC2865] , but will work as is in Diameter [RFC3588] , and through the translation rules defined in [Diameter Lior, et al. Expires August 16, 2005 [Page 3] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 NASREQ]. 1.1 Requirements language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview This section describes the bandwidth parameters and the protocol by which these parameters can be exchanged between a NAS and the AAA server to help the access network determine the bandwidth parameters that should be allocated for the user's session at the access network. 2.1 Bandwidth Parameters Often bandwith is allocated in non-symmetric fashion, therefore the bandwidth parameters consists of two attributes: ingress bandwidth and egress bandwidth. As well, bandwidth profile id parameter that allows the AAA to assign a preconfigured bandwidth profile to a user session. The following subsections describe these parameters. 2.1.1 Egress Bandwidth This attribute indicates the data rate that the authorized user session should be allocated within the access network, for traffic flowing from the user's device. 2.1.2 Ingress Bandwidth This attribute indicates the data rate that the authorized user session should be allocated within the access network, for traffic flowing to the user's device. Typically, the Ingress Bandwidth is much greater then the Egress Bandwidth. 2.1.3 Bandwidth Profile Id This attribute indicates which bandwidth profile to assign to the user session. Use of this attribute requires apriori configuration of the NAS and therefore does not scale well in large roaming scenarios. Lior, et al. Expires August 16, 2005 [Page 4] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 2.2 Protocol Two aspects of the protocols are described. One aspect of the protocol is used to allocate bandwidth when a service is initiated (referred to as Static Bandwidth Allocation); the other protocol describes how to change bandwidth attribute dynamically that is, mid-session (also referred to as Dynamic Bandwidth Allocation). Both static and dynamic bandwidth allocation exchange parameters using the various AAA packets, and may include an advertisement phase, selection phase and confirmation phase. Bandwidth Advertisement: MAY be sent in Access-Request packet in RADIUS, and the AAR and DER commands in Diameter [Diameter NASREQ, Diameter EAP], from the NAS to the home AAA server. The attributes convey to the AAA server the possible/available bandwidth that can be allocated for the access network user session. A Bandwidth advertisement reflects the capability of the access network. If the access network can only provide symmetric bandwidth then the advertisement should only contain the Ingress bandwidth attribute. Note, providing both the Egress and Ingress attributes with the same value does not mean that the access network only supports symmetric bandwidth. Bandwidth Selection: MAY be sent in Access-Accept packet and Change of Authorization (COA) packets in RADIUS. MAY also be sent in RAR command in [RFC3588]. Selection conveys the home AAA server's desired bandwidth (either explicitly using the bandwidth parameters, or implicitly using the bandwidth profile id) for the user session in the access network. The use of both bandwidth profile id and bandwdith parameters in the selection phase is not supported by this document. If a Selection is sent in response to an Advertisement, for the Selection to be considered valid, the selection should match the attributes provided in the Bandwidth advertisement. For example, if the AAA replied with both Ingress and Egress bandwidth parameters to the an advertisment that indicates symmetric support, then the Selection response is considered invalid. Furthermore the bandwidth parameters in the Selection SHOULD NOT exceed the corresponding bandwidth parameters in the Advertisement. A bandwidth parameter with value of zero in Selection should be interpreted as a "don't care" value. Lior, et al. Expires August 16, 2005 [Page 5] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 Bandwidth Confirmation: If Bandwidth Selection is received by the NAS (for either static or dynamic allocation) and enforced, an indication MUST be sent in Accounting-Request packets in RADIUS and in ACR command in Diameter. Confirmation indicates the actual allocated bandwidth for the user session, or the bandwidth profile id that was applied to the session. The allocated bandwidth would either be exactly what was requested by the home network or defaults selected by the access network when the home network selection was not appropriated. Similarly if bandwidth profile id was used, the profile id that was applied to the session is to be reported. It is possible that a different profile-id was applied to the session by the NAS. The Bandwidth attributes, defined in section 3, are used to carry the Bandwidth Advertisement, Selection, Confirmation in various RADIUS packets and Diameter commands. The following subsections describe static and dynamic bandwidth allocation. 2.2.1 Static Bandwidth Allocation Static bandwidth allocation is performed during the initial session authentication / authorization. The following diagram shows the protocol interaction between the NAS and the home RADIUS server for determining network bandwidth rates that an access network needs to allocate for a user session within the access network. Lior, et al. Expires August 16, 2005 [Page 6] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 Client NAS home RADIUS server | | | | | | | Authentication | | | Phase Begin | | |----------------->| Access-Request | | | + | | | BA for Advertisement | | |----------------------------->| | | | |<> | | | | | | | | |<-----------------------------| | | Access-Accept | | Authentication | + | | Accept | BA for Selection | |<-----------------| | | | | | | | | | Accounting Request | | | + | | | BA for Confirmation | | |----------------------------->| | | | The NAS MAY send an Advertisement in an Access-Request packet. The advertisement will contain either both Egress and Ingress bandwidth attributes or just Ingress attribute indicating that the NAS supports symmetric bandwidth only. If the NAS receives an Advertisement containing only an Egress bandwidth attribute it SHOULD silently discard the Access-Request packet. A home RADIUS server MAY send the Selection after receiving a valid Advertisement. It MAY also send the Selection in the absence of an Advertisement, based on local policies such as the clientÆs subscription profile. When the NAS receives an invalid Selection, it SHOULD treat the Access-Accept packet as an Access Reject. The AAA SHOULD select bandwidth that is commensurate with what was advertised by the NAS. If the AAA is to respond with a Bandwidth Profile Id it SHOULD select the profile id as determined by policy and what is provisioned for the user profile. The policy may or may not take into consideration the Advertised bandwidth. If the NAS receives a valid Selection in response to an Access-Request that did not contain an Advertisement, then the NAS Lior, et al. Expires August 16, 2005 [Page 7] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 MAY honor the Selection. If the NAS receives a valid Selection in response to an Access-Request that contained a valid Advertisement, then the NAS SHOULD honor the Selection. In the case where the NAS receives explicitly bandwidth attribute and the attributes fall within the limits advertised, then the NAS SHOULD honor the request. In the case where the NAS receives an explicit bandwidth attribute that exceeded the advertised limit, the NAS should provide as much bandwidth as it can. In the case where the NAS advertised symmetric bandwidth and it received both an Egress and Ingress parameters, the NAS SHOULD ignore the Egress parameter and symmetric bandwidth that matches the received Ingress attribute. In the case where the NAS receives a bandwidth profile id, it SHOULD honor that request or utilize a different profile id as determined by the pre-provisioned policies between the two administrative domains. Otherwise if the NAS doesn't recognize the profile id, then it MAY treat the Access-Accept as an Access-Reject. In the absence of a Selection after sending a valid Advertisement, in accordance with local policy, the access network MAY enforce its default bandwidth rate values for that user session. During the Confirmation phase, if the NAS received a bandwidth selection, then the NAS MUST report what was provisioned for the user session. If the NAS did not receive a bandwidth selection then the NAS SHOULD report what bandwidth treatment was provided for the user session. 2.2.2 Dynamic Bandwidth Allocation Dynamic bandwidth allocation uses the Change of Authorization (COA) RADIUS packet as defined in [RFC3576], and the Diameter RAR message as defined in [RFC3588]. These packets/messages are referred to as the re-authorization messages in this specification. In accordance with [RFC3576] there are two methods for dynamically changing authorization attributes of a session. These two methods are described in this section. At anytime during the session the home AAA server may send the NAS a re-authorization message containing session identification attributes (see [RFC3576] for the possible options). The re-authorization message may include authorization attributes in which case it is "pushing" the bandwidth attributes to the NAS. Or, it may instruct the NAS to generate an "authorize-only" AAA exchange to "pull" the Lior, et al. Expires August 16, 2005 [Page 8] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 bandwidth attributes. In RADIUS this exchange is an Access-Request with Service-Type set to "Authorize-Only". In Diameter it is the AAR command with the Auth-Request-Type AVP set to "AUTHORIZE_ONLY". In either "push" or "pull" method, upon successful acceptance of the new bandwidth parameters for the session, the NAS MUST indicate the change in bandwidth in the Accounting stream (if accounting is available) by using one of two methods: The NAS SHOULD indicate the change of bandwidth by issuing a RADIUS Accounting-Request(Stop) packet that contains the old bandwidth attributes and Acct-Terminate-Cause set to "Change-of-Authorization" (TBD), followed by an RADIUS Accounting-Request(Start) packet that contains the new bandwidth attributes and Accounting-Terminate-Cause set to "Session-Continue". In order to allow for correlation of the accounting packets, a NAS that supports dynamic bandwidth allocation SHOULD include Acct-Multi-Session-Id(51) when writing accounting packets. Alternatively, the NAS MAY indicate the change of bandwidth by issuing a RADIUS Accounting-Request (Interim) which will contain the new bandwidth attributes. [EDITORS NOTE: The last case was motivated because at least one company reported that their resource management software actually released resources when an accounting session stop was received.] [EDITORS NOTE: Here the NAS is choosing the method. Perhaps the home network should be controlling how the change is to be reported. In this case we need to introduce an attribute that is sent in the Access-Accepts that instructs the NAS how to respond.] [EDITORS NOTE: Also note that Accounting Interim may be turned off. So does this mean that accounting interim will be generated for this case only.] [EDITORS NOTE: Finally, does this interfere with the accounting interim time.] 2.2.2.1 Push Method In the Push Method, to effect a dynamic bandwidth change the home RADIUS server sends a re-authorization message and includes a valid Selection. The RADIUS server MAY also include other attributes in the re-authorization message. Lior, et al. Expires August 16, 2005 [Page 9] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 NAS Home RADIUS Server | | | | |re-authorization + BAs for Selection | |<---------------------------------------------| | | | | | re-authorization ACK | |--------------------------------------------->| | | | | | Accounting-Stop + old BAs for Confirmation | |--------------------------------------------->| | | | Accounting-Start + new bandwidth | |--------------------------------------------->| | | | | Upon the reception of the re-authorization message (see [RFC3576] for details) by the NAS, if the re-authorization message contains an invalid Selection, the NAS MUST respond with a re-authorization NAK with Error Cause (101) set to "Invalid Request" (404). If the NAS is able to offer the requested bandwidth to the specified session, the NAS MUST reply with a re-authorization ACK and it MUST report the change in bandwidth in the accounting stream (if accounting is available) using one of the two mechanisms described above. If the NAS receives a re-authorization message that does not include Bandwidth attributes then as per [RFC3576] the NAS must not alter the bandwidth already allocated to the session. 2.2.2.2 Pull Method Alternatively, in the pull method, to effect a dynamic bandwidth change, as per [RFC3576], the home network sends a re-authorization message to instruct the AN to generate an Authorize-Only request (Access-Request with Service-Type set to Authorize-Only). Lior, et al. Expires August 16, 2005 [Page 10] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 NAS Home RADIUS server | | | re-authorization + Service-Type = öAuthorize Onlyö | |<-----------------------------------------------------| | | |re-authorization NAK + Service-Type = öAuthorize Onlyö | | + Error-Cause "Request Initiated" | |----------------------------------------------------->| | | | Access-Request + Service-Type öAuthorize Onlyö | | + BAs for Advertisement | |----------------------------------------------------->| | | | Access-Accept + BAs for Selection | |<-----------------------------------------------------| | | | Accounting-Stop + old BAs for Confirmation | |----------------------------------------------------->| | | | Accounting-Start + new BAs for Confirmation | |----------------------------------------------------->| | | | | Once the NAS issues the Access-Request with Authorize-Only then the procedure is identical to the static allocation method. With the following exceptions: If accounting is used then the NAS MUST report the change of bandwidth in the accounting stream using one of the two methods indicated above. Note: If the Access-Accept packet does not contain any bandwidth attributes then the NAS must allocate the default bandwidth attributes to the session. That is it would allocate the same bandwidth to the session that it would have if it did not receive any bandwidth attributes from the home network in the first place. 2.3 Diameter RADIUS Interoperability In deployments where both RADIUS clients talking with Diameter Servers or Diameter Client talking with RADIUS server then a translation agent will be deployed and operate in accordance to the NASREQ specification. Lior, et al. Expires August 16, 2005 [Page 11] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 3. Attributes This section describes format and syntax for the attributes that carry the network bandwidth parameters. The attributes are used for bandwidth parameters Advertisement, Selection, and Confirmation. A summary of the Bandwidth Attributes is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Ingress-Bandwidth Length 6 Value An integer value representing the ingress bandwidth (traffic to the user device) rate in bytes per second. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Egress-Bandwidth Length 6 Value An integer value representing the egress bandwidth Lior, et al. Expires August 16, 2005 [Page 12] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 (traffic from the user device) in bytes per second 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Bandwidth-Profile-Id Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters. 4. Table of Attributes The following table provides a guide to which attribute(s) may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute Request 0-1 0-1 0 0 0-1 TBD Ingress-Bandwidth [Note 1] 0-1 0-1 0 0 0-1 TBD Egress-Bandwidth [Note 1] 0-1 0-1 0 0 0-1 TBD Bandwidth-Profile-Id [Note 2] Lior, et al. Expires August 16, 2005 [Page 13] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 Note 1 : If Ingress-Bandwidth appears alone in an Access-Request packet then the NAS is indicating that it only supports symmetric bandwidth allocation. Therefore, Egress bandwidth SHOULD NOT appear in the corresponding Access-Accept packet. Note 2 : Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet that contains either or both of Ingress-Bandwidth or Egress-Bandwidth attributes. For Change-of-Authorization packets Request ACK NAK # Attribute 0-1 0 0 TBD Ingress-Bandwidth 0-1 0 0 TBD Egress-Bandwidth 0-1 0 0 TBD Bandwidth-Profile-Id Note 1 : If the Change-of-Authorization packet contains any bandwidth attributes then all the bandwidth attributes received for this session are overwritten. If the Change-of-Authorization packet does not contain any bandwidth attributes then, the previously received bandwidth attributes remain in effect. Note 2 : Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet that contains either or both of Ingress-Bandwidth or Egress-Bandwidth attributes. 5. IANA Considerations This document requires the assignment of four new RADIUS attribute numbers for the following attribute(s): 1. Ingress-Bandwidth 2. Egress-Bandwidth 3. Bandwidth-Profile-Id This document requires the assignment of a two new values for Acct-Terminate-Cause(49) define in [RFC2866]: 1. "Change of Authorization" 2. "Session Continue" Please See section 3 for the registered list of numbers. 6. Security Considerations The attributes in this document have no additional security considerations beyond those already identified in [RFC2865]. Lior, et al. Expires August 16, 2005 [Page 14] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 7. Acknowledgements The authors would specially like to thank Jari Arkko (of Ericsson) for his through review of the draft, providing feedback/comments and proposing text. The authors would like to thank Bernard Aboba (of Microsoft), Parviz Yegani (of Cisco), Stefan De_cnodder (of alcatel) for their feedback and guidance. 8. References 8.1 Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. 8.2 Informative references [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Authors' Addresses Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: avi@bridgewatersystems.com Lior, et al. Expires August 16, 2005 [Page 15] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503-712-1791 Email: farid.adrangi@intel.com Paul Congdon ProCurve Networking Business 8000 Foothills Blvd Roseville, CA 95747 USA Phone: +1 916 785 5753 Email: paul.congdon@hp.com Chuck Black ProCurve Networking Business 8000 Foothills Blvd Roseville, CA 95747 USA Phone: +1 916 785 9713 Email: chuck.black@hp.com Farooq Bari Cingular Wireless 7277 164th Avenue N.E. Redmond, WA USA Phone: +1 425-580-5526 Email: farooq.bari@cingular.com Lior, et al. Expires August 16, 2005 [Page 16] Internet-Draft Network Bandwidth Parameters for RADIUS February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lior, et al. Expires August 16, 2005 [Page 17]