Network Working Group A. Lior Internet-Draft Bridgewater Systems Expires: January 18, 2006 F. Adrangi Intel P. Congdon C. Black ProCurve Networking Business F. Bari AT&T July 17, 2005 Network Bandwidth Parameters for Remote Authentication Dial In User Service (RADIUS). draft-lior-radius-bandwidth-capability-01 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes bandwidth profile parameters and a protocol Lior, et al. Expires January 18, 2006 [Page 1] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 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. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Ingress Bandwidth . . . . . . . . . . . . . . . . . . . . 4 2.2 Egress Bandwidth . . . . . . . . . . . . . . . . . . . . . 5 2.3 Bandwidth Profile Id . . . . . . . . . . . . . . . . . . . 6 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 7 4. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Normative references . . . . . . . . . . . . . . . . . . . 10 8.2 Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 A. Issue Resolution . . . . . . . . . . . . . . . . . . . . . . . 12 B. Example: Static Bandwidth Allocation . . . . . . . . . . . . . 12 C. Example: Mid-Session Bandwidth Allocation . . . . . . . . . . 14 C.1 Push Method . . . . . . . . . . . . . . . . . . . . . . . 15 C.2 Pull Method . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 18 Lior, et al. Expires January 18, 2006 [Page 2] Internet-Draft Network Bandwidth Param. for RADIUS July 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 the network bandwidth capabilities that it can allocate for a given user session in the Access Network. And, it enables the Home Network to indicate the desired bandwidth to be allocated for the user session within the access network. +--------+ +------+ +--------+ | | Data Ingress flow | | Bandwidth Attributes| Home | | User | <----------- | +<------------------->+ AAA | | Device +<----------------->+ NAS | AAA Protocol | Server | | | -----------> | +<------+ +--------+ | | Egress flow | | Data | +--------+ +------+ V --- -- --- --- Internet-- -- - -- --- ---- 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 modify the bandwidth allocation for a user during mid- 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. Lior, et al. Expires January 18, 2006 [Page 3] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 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 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. Attributes The following subsections describe the format and syntax of the Bandwidth parameters. 2.1 Ingress Bandwidth Ingress Bandwidth attribute is available for use in Access-Request, Accept-Accept, COA and Accounting packets. If used in an Access-Request packet the Ingress Bandwidth attribute is a hint indicating the data rate that the NAS has available to allocate for traffic flowing to the user's device for that session. NASs that support only symmetric bandwidth allocation MUST only include Ingress Bandwidth attribute which is a hint to the available bandwidth in both ingress and egress direction. If used in an Access-Accept packet the Ingress Bandwidth attribute indicates the desired data rate for traffic flowing to the user's device for the session. The value expressed SHOULD NOT exceed the value specified by the Ingress Bandwidth attribute in the Access- Request packet (if any). If the value specified in Access-Accept is less then the value specified in an Access-Request then the NAS SHOULD allocate the ingress bandwidth specified in the Access-Accept for that user session. If the value requested in the Access-Accept is greater then the value indicated in the Access-Request then the Lior, et al. Expires January 18, 2006 [Page 4] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 NAS MAY allocate bandwidth up to the bandwidth requested in the Access-Accept. A value of '0' for this attribute in an Access-Accept implies I don't care. If the NAS is receives an Ingress Bandwidth attribute that it understands, the NAS MUST include the Ingress Bandwidth attribute in the Accounting packets to indicate the actual bandwidth allocated by the NAS for traffic flowing to the user's device. In the case where the NAS is only capable of symmetric bandwidth allocation, the Ingress Bandwidth SHALL indicate the bandwidth allocated in both direction. 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 Kilo-bits per second. 2.2 Egress Bandwidth Egress Bandwidth attribute is available for use in Access-Request, Accept-Accept, COA and Accounting packets. If used in an Access-Request packet the Egress Bandwidth attribute is a hint indicating the data rate that the NAS has available to allocate for traffic flowing from the user's device for that session. If used in an Access-Accept packet the Egress Bandwidth attribute indicates the desired data rate for traffic flowing from the user's device for the session. The value expressed SHOULD NOT exceed the value specified by the Egress Bandwidth attribute in the Access- Request packet (if any). If the value specified in Access-Accept is Lior, et al. Expires January 18, 2006 [Page 5] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 less then the value specified in an Access-Request then the NAS SHOULD allocate the egress bandwidth specified in the Access-Accept for that user session. If the value requested in the Access-Accept is greater then the value indicated in the Access-Request then the NAS MAY allocate bandwidth up to the bandwidth requested in the Access-Accept. A value of '0' for this attribute in an Access-Accept implies I don't care. If the NAS is allocating bandwidth then the NAS MUST include the Egress Bandwidth attribute in the Accounting packets to indicates the actual bandwidth allocated by the NAS for traffic flowing from the user's device. If the NAS is only capable of symmetric bandwidth allocation the NAS MUST NOT include the Egress Bandwidth attribute in the Accounting packets. 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 (traffic from the user device) in Kilo-bits per second 2.3 Bandwidth Profile Id The Bandwidth Profile Id attribute is available in an Access-Accept, COA and Accounting Packets and 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 January 18, 2006 [Page 6] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 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. 3. 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,3] 0-1 0-1 0 0 0-1 TBD Egress-Bandwidth [Note 1,3,5] 0 0-1 0 0 0-1 TBD Bandwidth-Profile-Id [Note 2] 1 0 0 0 0 80 Message-Authenticator [Note 4] 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. Lior, et al. Expires January 18, 2006 [Page 7] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 Note 2 : Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet that contains either or both of Ingress-Bandwidth or Egress- Bandwidth attributes. Note 3 : If the NAS only supports symmetric bandwidth allocation then it signals its support for symmetric bandwidth allocation by not sending the Egress-Bandwidth attribute in an Access-Request. The NAS SHALL ignore any Egress-Bandwidth attribute received in the Access-Accept. If the NAS only sends the Ingress-Bandwidth attribute in an Access-Request then the RADIUS server SHOULD NOT send the Egress-Bandwidth attribute in an Access-Accept. Note 4 : An Access-Request message that contains Ingress-Bandwidth attribute and/or Egress-Bandwidth attribute MUST be integrity protected by including the Message-Authenticator (80) attribute. RADIUS clients and servers MUST compute and validate the Message- Authenticator as described in [RFC2869]. Note 5 : A RADIUS server that receives an Access-Request packet containing only an Egress Bandwidth attribute and a Message- Authenticator (80) SHOULD ignore the Egress Bandwidth Attribute. For Change-of-Authorization packets Request ACK NAK # Attribute 0-1 0 0 TBD Ingress-Bandwidth [Note 1,3] 0-1 0 0 TBD Egress-Bandwidth [Note 1,3] 0-1 0 0 TBD Bandwidth-Profile-Id [Note 2] Note 1 : If the COA packet contains any bandwidth attributes then all the bandwidth attributes received for this session are overwritten. If the COA 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 COA packet that contains either or both of Ingress-Bandwidth or Egress-Bandwidth attributes. Note 3 : If the NAS only supports symmetric bandwidth allocation then it signals its support for symmetric bandwidth allocation by not sending the Egress-Bandwidth attribute in an Access-Request. In this case the NAS SHALL ignore Egress-Bandwidth attribute received in the COA. If the NAS only sends the Ingress-Bandwidth attribute in an Access-Request then the RADIUS server SHOULD NOT send the Egress-Bandwidth attribute in a COA packet. 4. Diameter RADIUS Interoperability The attributes specified in this document may be used in Diameter Lior, et al. Expires January 18, 2006 [Page 8] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 NASREQ application. In DIAMETER the Ingress and Egress Bandwidth Attribute are of type Unsigned32 Integer (which corresponds to RADIUS Integer type). The Bandwidth Profile Id attribute is defined as UTF8String (which corresponds to a RADIUS Text type). RADIUS Access-Request packets corresponds to AA-Request messages in Diameter applications based on NASREQ . RADIUS Access-Accept packet correspond to AA-Answer messages in Diameter applications based on NASREQ. RADIUS accounting packets correspond to Diameter Accounting- Request ACR messages as defined by [RFC3588]. The RADIUS rules defined for these attributes in RADIUS packets SHALL also apply to their inclusion in the aforementioned Diameter messages. Diameter applications based on NASREQ do not support COA "PUSH" method of changing bandwidth dynamically (see the appendix at the end of this document). If a RADIUS to Diameter translating agent receives a COA message containing an Ingress Bandwidth attribute, and/or Egress Bandwidth attribute or a Bandwidth Profile Attribute then the RADIUS to Diameter translating agent SHALL engage the Diameter server by sending a Diameter Re-Auth-Request RAR as defined by [RFC3588] which forces a Diameter Re-authentication. 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 Please See section 3 for the registered list of numbers. 6. Security Considerations The protocol extension to RADIUS described herein is susceptible to all the security threats described for RADIUS in [RFC2865], [RFC2866], [RFC2869] and [RFC3576]. Mitigation of these security threats are provided in those document. However, specific to this document, since RADIUS Access-Request messages are not integrity protected, it would be possible for a Man- In-The-Middle to modify Access-Requests packets and reduce the advertized bandwidth by the NAS for the Access-Network. This would result in user getting lower bandwidth response. To mitigate this atack, in this document we mandate the use of the RADIUS Message- Authenticator (80) attribute which provides for integrity protection. Lior, et al. Expires January 18, 2006 [Page 9] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 Message-Authenticator is widely supported due to its required use when transporting EAP payloads in RADIUS messages. 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. Lior, et al. Expires January 18, 2006 [Page 10] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 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 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 Lior, et al. Expires January 18, 2006 [Page 11] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 Farooq Bari AT&T Wireless 7277 164th Avenue N.E. Redmond, WA USA Phone: +1 425-580-5526 Email: farooq.bari@attws.com Appendix A. Issue Resolution The following have been addressed by this version of the document: Attribute Scale: Use of Integer and units of Kilobits gives us 2**35 bits per second. As per Bernard, today we are at 10 Gbps (or 2*30). At an increase of one order of magnitude every 3 years will gives us headroom for the next 15 years or so. Bernard suggested to use a 64-bit attribute. We think that this is wasteful now. As well, RADIUS only supports Integer type. We could gain 2-3 years by using Kilo Octets instead of Kilobits. Re-organized the contents. Moved text into the attribute section and added text into an appendix. The text in the appendix is INFORMATIVE. Strengthened the Diameter Section Removed new Acct-Terminate-Cause value introduced in the last version. This are nice to have but if we add them it should be added to the 3576bis version (if ever). Appendix B. Example: 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 January 18, 2006 [Page 12] Internet-Draft Network Bandwidth Param. for RADIUS July 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 sends "advertizement" in an Access-Request packet. The "advertizement" contains either both Egress and Ingress bandwidth attributes or just Ingress attribute indicating that the NAS supports symmetric bandwidth only. A home RADIUS server could request bandwidth for the session regardless of whether it has recieved "advertizement" from the NAS. The home RADIUS server SHOULD select bandwidth that is commensurate with what was advertized by the NAS. If the AAA is to respond with a Bandwidth Profile Id it SHOULD select the appropriate bandwidth profile id as determined by policy, and what is provisioned for the user profile. The policy may or may not take into consideration the "advertizement" bandwidth. If the NAS receives a bandwidth attributes in an Access-Accept that is in response to an Access-Request that did not contain an "advertizement", then the NAS could allocate bandwidth up to the requested values. If the NAS receives a bandwidth attributes in an Access-Accept in Lior, et al. Expires January 18, 2006 [Page 13] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 response to an Access-Request that contained a "advertizement", then the NAS SHOULD honor the requested bandwidth. If it is unable to provide the requested bandwidth then it should attempt to provide as much bandwidth as possible without excceeding the amound requested. In the case where the NAS advertized symmetric bandwidth and it received both an Egress and Ingress bandwidth parameters, the NAS SHOULD ignore the Egress parameter and allocate 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 doesnt recognize the profile id, then it could 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 could enforce its default bandwidth rate values for that user session. During accounting phase, if the NAS received a bandwidth selection, then the NAS will report what was provisioned for the user session. If the NAS did not receive a bandwidth selection then the NAS SHOULD report what bandwidth treatement was provided for the user session. Appendix C. Example: Mid-Session Bandwidth Allocation Mid-session 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 changing authorization attributes of mid-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 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 Lior, et al. Expires January 18, 2006 [Page 14] Internet-Draft Network Bandwidth Param. for RADIUS July 2005 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, followed by an RADIUS Accounting- Request(Start) packet that contains the new bandwidth attributes. In order to allow for correlation of these accounting packets, an NAS that supports mid-session 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.] C.1 Push Method In the Push Method, to effect a mid-session 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 January 18, 2006 [Page 15] Internet-Draft Network Bandwidth Param. for RADIUS July 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 combination of bandwidth attributes (for example only Egress Bandwidth attribute or Bandwidth Profile Id or one or both of the other Bandwidth attributes), the NAS will 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 will 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. C.2 Pull Method Alternatively, in the pull method, to effect a mid-session 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 January 18, 2006 [Page 16] Internet-Draft Network Bandwidth Param. for RADIUS July 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 will 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. Lior, et al. Expires January 18, 2006 [Page 17] Internet-Draft Network Bandwidth Param. for RADIUS July 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 January 18, 2006 [Page 18]