One document matched: draft-adrangi-radius-bandwidth-capability-00.txt
Network Working Group F. Adrangi, Intel
INTERNET DRAFT P. Congdon, C. Black, Hewlett Packard
Category: Informational A. Lior, Bridgewater Systems
Expires: Aug 2004 F. Bari, AT&T Wireless
Feb 8, 2004
Access Network Bandwidth Capability
draft-adrangi-radius-bandwidth-capability-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes network bandwidth parameters and a
protocol framework within which the parameters can be exchanged
between an Access Network (AN) and a Home Service Network (HSN)
in order to determine the average minimum and maximum bandwidth
for both ingress and egress traffic that should be allocated by
the AN for the duration of an authorized client session.
Adrangi, et al. Expires April 13, 2004 [Page 1]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
Table of Contents
1. Introduction....................................................2
1.2 Requirements language..........................................3
1.3 Terminology....................................................3
2. Overview........................................................3
2.1 Bandwidth Parameters...........................................3
2.1.1 Ingress Minimum Bandwidth....................................3
2.1.2 Ingress Maximum Bandwidth....................................4
2.1.3 Egress Minimum Bandwidth.....................................4
2.1.4 Egress Maximum Bandwidth.....................................4
2.2 Protocol.......................................................4
2.2.1 Static Bandwidth Allocation..................................5
2.2.2 Dynamic Bandwidth Allocation.................................7
2.2.2.1 Push Method................................................7
2.2.2.2 Pull Method................................................8
3. Operations.....................................................10
4. Attribute Format/Syntax........................................10
5. Table of Attribute(s).........................................12
6. Attribute Usage Examples.......................................12
7. IANA Considerations............................................13
8. Security Considerations........................................13
9. Acknowledgements...............................................13
10. References....................................................13
AuthorsÆ Addresses................................................14
1. Introduction
The bandwidth that a user is authorized within an Access Network
(AN) can be a result of the AN bandwidth 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 (AN) to advertise its network bandwidth
capabilities that it can allocate for a given AN client connection
to the clientÆs Home Service Network (HSN). And, it also enables
the HSN to indicate its selection of the desired network bandwidth
capabilities for the client connection to the AN.
User bandwidth can be determined during initial authentication
authorization of the session. It is also desirable to change the
bandwidth for the 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 session.
Adrangi, et al. Expires Aug 30, 2004 [Page 2]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
This document defines a new AAA attribute used for exchanging
network bandwidth parameters between the AN and the HSN, to
determine the average minimum and maximum bandwidth for both
ingress and egress traffic that an AN should allocate for the
duration of an authorized client session. This attribute is also
used for reporting the allocated bandwidth in accounting records.
The attribute is described for RADIUS [1].
1.2 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].
1.3 Terminology
Access Network (AN)
The network that provides wired or wireless connectivity
to the Internet for clients (or stations) present in the
local access area. This MAY be in a separate security and
routing domain with respect to the Home Service Network or a
Mediating Network.
Home Service Network (HSN)
The network providing the service and therefore maintaining
the direct relationship to its users and subscribers. All AAA
functions are ultimately performed by the HSN.
RADIUS server
ôThis is a server which provides for
authentication/authorization via the protocol described in
[1], and for accounting as described in [6].ö It is deployed
in the PWLAN AN, MN, and HSN.
2. Overview
This section describes the bandwidth parameters and the protocol
by which these parameters are exchanged between an AN and a HSN.
2.1 Bandwidth Parameters
Bandwidth parameters describe the average minimum and maximum
data rates (for both ingress and egress traffic) for a client
connection within an AN. There are four bandwidth parameters,
which are described in the following subsections.
2.1.1 Ingress Minimum Bandwidth
Adrangi, et al. Expires Aug 30, 2004 [Page 3]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
The ingress minimum bandwidth parameter indicates the average
minimum ingress data rate that an AN will try to provide to an
authorized user. This value is a target, rather than a
guarantee.
2.1.2 Ingress Maximum Bandwidth
The ingress maximum bandwidth parameter indicates the average
maximum ingress data rate that an AN can allow to an authorized
user.
2.1.3 Egress Minimum Bandwidth
The minimum egress bandwidth parameter indicates the average
minimum egress data rate that an AN will try to provide to an
authorized user.
2.1.4 Egress Maximum Bandwidth
The maximum egress bandwidth parameter indicates the average
maximum data rate that an AN can allow to an authorized user.
2.2 Protocol
Two protocols are described. One 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 (referred to
as Dynamic Bandwidth Allocation).
Both protocols exchange bandwidth parameters using the various
RADIUS messages, and they are comprised of three phases:
bandwidth Advertisement, Selection, and Confirmation.
Bandwidth Advertisement:
MAY be sent in Access-Request packet from the AN to the HSN
and conveys possible/available bandwidth parameters that can
be allocated for an the AN client connection to the HSN by the
AN. Advertisements are optional.
Bandwidth Selection:
MAY be sent in Access-Accept packet and Change of
Authorization (COA) messages. Selection conveys the desired
bandwidth for the AN Client connection to the AN by the HSN.
Bandwidth Confirmation:
If Bandwidth Selection is received and enforced, It MUST be
sent in Accounting-Request packets. Confirmation indicates
Adrangi, et al. Expires Aug 30, 2004 [Page 4]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
that the desired bandwidth parameters specified by a HSN are
being enforced by the AN.
Bandwidth Attribute (BA), defined in section 3, is used to carry
the Bandwidth Advertisement, Selection, Confirmation in various
RADIUS packets.
An Advertisement, Selection, Confirmation is said to be valid if
it contains the four aforementioned bandwidth parameters and the
minimum bandwidth rate values for ingress and egress traffic MUST
be equal or less than their corresponding maximum bandwidth rate
values.
If a Selection is sent in response to an Advertisement, for the
Selection to be considered valid, then the bandwidth parameters
in the Selection MUST NOT exceed the corresponding bandwidth
parameters in the Advertisement.
The following subsections describe static and dynamic bandwidth
allocation.
2.2.1 Static Bandwidth Allocation
Static bandwidth allocation is preformed during the initial
session authentication / authorization.
The following diagram shows the protocol interaction between
the AN and the HSN for determining network bandwidth rates that
an AN needs to allocate for an AN client connection.
Adrangi, et al. Expires Aug 30, 2004 [Page 5]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
AN Client AN Device + AAA client HSN + AAA 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 AN MAY send an Advertisement in an Access-Request message.
If the HSN receives an invalid Advertisement, then the HSN MUST
silently discard the Access-Request.
A HSN 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 AN
clientÆs subscription profile. When the AN receives an invalid
Selection, it MUST treat the Access-Accept message as an Access
Reject.
If the AN receives a valid Selection in response to an Access-
Request that did not contain an Advertisement, then the AN MAY
honor the Selection.
If the AN receives a valid Selection in response to an Access-
Request that contained a valid Advertisement, then the AN MUST
honor the Selection.
In the absence of a Selection after sending a valid
Advertisement, in accordance with local policy, the AN MAY
Adrangi, et al. Expires Aug 30, 2004 [Page 6]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
enforce its default bandwidth rate values or it MAY use ôbest
effortö bandwidth for that client connection.
2.2.2 Dynamic Bandwidth Allocation
Dynamic bandwidth allocation uses the Change of Authorization
(COA) message as defined in [3]. In accordance with [3] 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 HSN may send the AN a COA
message containing session identification attributes (see [3]
for the possible options). The COA message may include
authorization attributes in which case it is pushing the BAs to
the AN; or it may instruct the AN to generate an Authorize-Only
Access-Request (Access-Request with Service-Type set to
ôAuthorize-Onlyö) in which case it is instructing the AN to
pull the BAs.
In either push or pull method, upon successful acceptance of
the new bandwidth parameters for the session. The AN MUST
generate an Accouting-Stop record that contains the old
bandwidth attributes followed by an Accounting-Start message
that contains the new bandwidth attributes.
In order to allow for downstream correlation of the accounting
records, an AN that supports dynamic bandwidth allocation MUST
include Acct-Multi-Session-Id when writing accounting records.
2.2.2.1 Push Method
In the Push Method, to effect a dynamic bandwidth change the
HSN sends a COA message and includes a valid Selection. The
AN MAY also include other attributes in the COA message.
Adrangi, et al. Expires Aug 30, 2004 [Page 7]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
AN HSN
| |
| |
| COA + BAs for Selection |
|<---------------------------------------------|
| |
| |
| COA ACK |
|--------------------------------------------->|
| |
| |
| Accounting-Stop + old BAs for Confirmation |
|--------------------------------------------->|
| |
| Accounting-Start + new bandwidth |
|--------------------------------------------->|
| |
| |
Upon the successful reception of the COA message (see [3] for
details) by the AN, if the COA message contains an invalid
Selection, the AN MUST respond with a COA NAK with Error
Cause (101) set to ôInvalid Requestö (404).
If the AN is able to offer the requested bandwidth to the
specified session, the AN MUST reply with a COA-ACK and it
MUST generate an Accounting-Stop record containing the old
bandwidth attributes followed by an Accounting-Start record
containing the new bandwidth attributes. If the AN can not
comply with the request for new bandwidth it MUST reply with
a COA-NAK with Error Cause (101) set to ô"Resources
Unavailable"(506).
2.2.2.2 Pull Method
Alternatively, in the pull method, to effect a dynamic
bandwidth change, as per [3], the HSN sends a COA message to
instruct the AN to generate an Authorize-Only request
(Access-Request with Service-Type set to Authorize-Only).
Adrangi, et al. Expires Aug 30, 2004 [Page 8]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
AN HSN
| |
| COA + Service-Type ôAuthorize Onlyö |
|<----------------------------------------------|
| |
| COA 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 |
|---------------------------------------------->|
| |
| |
As with the static bandwidth allocation (described earlier),
the AN MAY Advertise the currently available bandwidth in the
Authorize-Only message.
Upon receiving the Authorize-Only message from the AN, the
HSN MUST respond with either an Access-Accept message or an
Access-Reject message.
When responding with an Access-Accept message, the HSN MAY
include the BAs for Selection. If the Authorize-Only message
included an Advertisement, the bandwidth parameters in
Selection MUST be within the bounds of bandwidth parameters
in the Advertisement received in the Authorize-Only message.
Upon sending an Authorize-Only message, the AN will receive
an Access-Accept message or an Access-Reject message.
Upon receiving an Access-Reject in response to the Authorize-
Only, the AN will terminate the session and send an
Accounting-Stop record.
Upon receiving an Access-Accept in response to an Authorize-
Only request that does not contain bandwidth Selection, the
AN MUST resume utilizing the existing bandwidth parameters,
and it MUST NOT generate an Accounting Stop message.
Adrangi, et al. Expires Aug 30, 2004 [Page 9]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
Upon receiving an Access-Accept packet that contains an
invalid Bandwidth Selection, the AN MUST treat the response
as an Access-Reject and immediately terminate the session.
Upon receiving an Access-Accept message in response to an
Authorize-Only message that contained the Bandwidth
Advertisement, then providing the bandwidth selections are
within the bounds of the Advertisement, then AN MUST honor
the requested bandwidth and generate an Accounting-Stop
message that contains the old bandwidth attributes followed
by an Account-Start message that contains the new bandwidth
attributes. If the bandwidth Selection were outside the
bounds of the Advertisement, then the AN MUST treat the
Access-Accept as an Access-Reject and immediately terminate
the session.
Upon receiving an Access-Accept message that contains a valid
Selection in response to an Authorize-Only that did not
contain the Advertisement, the AN MAY honor the Selection or
it MAY continue to honor the previously agreed to bandwidth.
In the former case, the AN must generate an Accounting Stop
message containing the old bandwidth attributes followed by
an Accounting-Start message containing the current bandwidth
attributes.
3. Operations
Operation is identical to that defined in RADIUS AAA
specifications [1][2] and Dynamic Authorization Extensions to
Remote Authentication Dial In User Service (RADIUS)[3].
4. Attribute Format/Syntax
This section describes format and syntax for the attribute that
carries AN bandwidth rate parameters. The attribute is used for
bandwidth rate parameters Advertisement, Selection, and
Confirmation.
The attribute MAY be present in Access-Request, Access-Accept,
Accounting-Request.
Adrangi, et al. Expires Aug 30, 2004 [Page 10]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
A summary of the AN Bandwidth Parameter Attribute 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 | Params |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD Network Bandwidth Capability
Length
8
Params
It indicates what the value signifies. The values defined
in the document are:
1 û Average Minimum Bandwidth Rate for Ingress Traffic in
bits per second
2 û Average Minimum Bandwidth Rate for Ingress Traffic in
Kilo bits per second
3 û Average Minimum Bandwidth Rate for Ingress Traffic in
Giga bits per second
4 û Average Maximum Bandwidth Rate for Ingress Traffic in
bits per second
5 û Average Maximum Bandwidth Rate for Ingress Traffic in
Kilo bits per second
6 û Average Maximum Bandwidth Rate for Ingress Traffic in
Giga bits per second
7 û Average Minimum Bandwidth Rate for Egress Traffic in
bits per second
8 û Average Minimum Bandwidth Rate for Egress Traffic in
Kilo bits per second
9 û Average Minimum Bandwidth Rate for Egress Traffic in
Giga bits per second
10 û Average Maximum Bandwidth Rate for Egress Traffic in
bits per second
11 û Average Maximum Bandwidth Rate for Egress Traffic in
Kilo bits per second
12 û Average Maximum Bandwidth Rate for Egress Traffic in
Giga bits per second
Adrangi, et al. Expires Aug 30, 2004 [Page 11]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
Value
An integer value interpreted based the value of Param.
5. Table of Attribute(s)
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-4 0-4 0 0 0-4 TBD Network Bandwidth
Capability
For Change-of-Authorization Messages
Request ACK NAK # Attribute
0-4 0-4 0 TBD Network Bandwidth Capability
6. Attribute Usage Examples
This section provides an example on how Bandwidth attribute can be
used to indicate the four bandwidth rate parameters, in
Advertisement, Selection, and Confirmation.
Ingress Minimum Bandwidth Rate for 28 Kilo bits 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 7 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ingress Maximum Bandwidth Rate for 28 Kilo bits 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 7 | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Egress Minimum Bandwidth Rate for 28 Kilo bits per second
Adrangi, et al. Expires Aug 30, 2004 [Page 12]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Egress Maximum Bandwidth Rate for 28 Kilo bits 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 7 | 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. IANA Considerations
This document requires the assignment of three new RADIUS
attribute numbers for the following attribute(s):
AN-Bandwidth-Rate-Paramters
See section 3 for the registered list of numbers.
8. Security Considerations
The attributes in this document have no additional security
considerations beyond those already identified in [?].
9. Acknowledgements
The authors would like to thank Bernard Aboba (of Microsoft),
Parviz Yegani (of Cisco), for their feedback and guidance.
10. References
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Server (RADIUS)", RFC 2865, June
2000.
[2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[3] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B.,
ôDynamic Authorization Extensions to Remote Authentication
Dial In User Service (RADIUS)ö, RFC 3576, July 2003.
Adrangi, et al. Expires Aug 30, 2004 [Page 13]
Internet Draft Access Network Bandwidth Capability 8 Feb 2004
AuthorsÆ Addresses
Farid Adrangi, Intel Corporatation farid.adrangi@intel.com
Chuck Black, Hewlett Packard Company chuck.black@hp.com
Paul Congdon, Hewlett Packard Company paul.congdon@hp.com
Farooq Bari, AT&T Wireless farooq.bari@attws.com
Avi Lior, Bridgwater Systems Corporation avi@bridgewatersystems.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by
the Internet Society.
Adrangi, et al. Expires Aug 30, 2004 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 12:59:42 |