[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-adrangi-radius-bandwidth-capability-00.txt
Hello Jari,
Thanks so much for your thorough review and detailed/excellent comments
- as always. I will update the draft accordingly.
- Yes, the attributes need to work with Diameter. The draft was
submitted before our diameter discussion in the last IETF!!
- The key difference between pull and push models is in the
advertisement. In the pull model, the HSN receives the current
bandwidth capabilities (in the Advertisement) before doing the
Selection.
- On attributes format/syntax, we have the flexibility to do the right
thing -- WFA is looking for IETF for the most appropriate syntax. I
don't want to open subtype can-of-worms here either! I am okay with
your proposal.
BR,
Farid
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Wednesday, June 02, 2004 4:30 AM
> To: 'radiusext@ops.ietf.org'; Adrangi, Farid
> Subject: 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/>