Internet DRAFT - draft-lior-radius-bandwidth-capability
draft-lior-radius-bandwidth-capability
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 |
| |----------------------------->|
| | |
|<<More Authentication/Authorization Exchanges>> |
| | |
| | |
| |<-----------------------------|
| | 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]
