[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-adrangi-radius-bandwidth-capability-00.txt
Hi Farid,
Overall, I think the basic functionality suggested
in this draft is valid and useful. Some work remains,
however. The attributes need to work with Diameter,
too, so when you mention a Radius message you should
also list the equivalent Diameter message. There's
a bunch of editorial issues and some suggested
simplifications below too. I'm not sure if the
pull model is useful, and the 12 attributes defined
should be compressed to 8. Finally, I would use
a different format in the attribute.
In more detail:
Substantial:
============
The attribute is described for RADIUS [1].
As I have stated before, I'd like attributes to be
defined generally. Suggested rewrite: The attribute
is described for RADIUS, but works as is also in
Diameter [RFC 3588], and through the translation
rules defined in [Diameter NASREQ]."
However, this probably means that the attribute format
corresponds to some known Diameter type. More on this
later.
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.
I have a feeling that "average minimum" is not well defined. What
does that mean? I guess it does not mean guaranteed minimum peak
rate. If not, what does it mean?
How about "... indicates the minimum peak rate that the
authorized user should get. However, this value is a target
and not a guarantee."
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
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.
RADIUS specific. Suggested rewrite:
Both protocols exchange bandwidth parameters using the various
AAA messages, and they are comprised of three phases:
bandwidth Advertisement, Selection, and Confirmation.
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 AN to the HSN. The attributes convey 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 in RADIUS. MAY be sent in RAR
command in Diameter [RFC 3588]. 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 in RADIUS and in ACR command
in Diameter. Confirmation indicates 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 and Diameter commands.
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.
I believe this text from 2.2.1 is unnecessary, as the MAY already
appeared in 2.2. The MUST part might be useful, except that it
would perhaps be better to move it too to 2.2.
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.
So the bottom line is that the HSN MAY send the advertisement,
which was already stated in 2.2... suggested rewrite:
A selection is sent after receiving a valid Advertisement,
or based on a local policy such the user's subscription
parameters.
(The style is explanation rather than normative language, I
think 2.2 already covered this pretty well.)
Similar comments apply to the rest of 2.2.1-2
Dynamic bandwidth allocation uses the Change of Authorization
(COA) message as defined in [3].
Suggested rewrite: "Dynamic bandwidth allocation uses the
Change of Authorization (COA) RADIUS message as defined in [3],
and the Diameter RAR message as defined in [RFC 3588]. These
messages are referred to as the re-authorization messages in
this specification."
In the rest of the section, change "COA message" to "re-authorization
message".
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.
How about "or it may instruct the AN to generate an authorize-only
AAA exchange. 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 case, the HSN instructs the AN to pull the bandwidth
attributes."
2.2.2.2 Pull Method
I'm not sure why the pull method is needed. Seems like in
both pull and push the HSN needs to take the initiative.
Simplify by removing the pull method from the spec?
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.
Does this cause the real session to appear as a set of
sessions in the accounting records?
The attribute MAY be present in Access-Request, Access-Accept,
Accounting-Request.
Duplicate text, but if you want to say something about the
attributes here, then an occurrence table per message would
be appropriate here. Alternatively, delete the text.
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
Three attributes for the same thing appear a bit unnecessary,
imho. Also, it is not in line with the byte - gigaword approach
defined in RFC 2869. My suggestion is to provide the rates as
bytes/s and gigawords/s. This will compress your set of attributes
down to 8 instead of 12.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Params |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I'm not sure I want to open the subtype can-of-worms here.
Are these attributes deployed somewhere by some SDO and vendor,
and we can't change the format? If yes, we can think about it,
but then there may be issues for Diameter translation. If not,
my preference would be to use plain old standards space RADIUS
attributes. We don't need that many. See also above. If that
fails, VSA with vendor=IETF would also work better for me.
Editorial:
==========
�Authorize-Only�)
Non-ASCII char.
preformed
performed
1 � Average
Non-ASCII char.
This document describes network bandwidth parameters and a
Additional spacing between words. I think the I-D guidelines
say that left justification is preferred.
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.
This is a pretty long sentence. Suggested rewrite:
This document describes network bandwidth parameters and a
protocol mechanism within which the parameters can be exchanged
between an access network and a home network. The parameters
can be used to allocate and police the minimum and maximum
bandwidth for the user's session, for both ingress and egress
traffic.
�This is a server which provides for
Non-ASCII char.
�Dynamic Authorization Extensions to Remote Authentication
Non-ASCII char.
pushing the BAs
pushing the 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].
This seems like an unnecessary section, imho. Refer to the specs
the first time you mention RADIUS, that should do it.
Authors� Addresses
Non-ASCII char.
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
This is not the usual style of author address lists.
Here's an example format from RFC 2865:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
EMail: wsimpson@greendragon.com
--Jari
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>