[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS attributes
Not having much prior RADIUS experience and having looked at the activities
in this group, I have been wondering why RADIUS needs to define every single parameter as an attributes. Given that there are so many customers for RADIUS:
we have seen SIPPING, WLAN community, QoS and so forth. Shouldn't there be
a method to bundle paramters regarding each application, given the fact
that attribute space is so limited??
But that aside, to comment on the QoS issue, isn't the issue that how
the RADIUS server configure the NAS (which is typically the same as the
device at the edge of the network) to know how to handle user's traffic?
If so then it depends on what kind of edge device the NAS is.
Also each user may have various kinds of sessions, for each it may get
different QoS treatment, so the QoS will be tied to SIP or other call
control protocols.
If it is a Diffserv router(filter), it needs to have DSCP for each flow the
user is using (not just one per user). If it is a L2 device, it may need
to have a whole bunch of access technology specific paramters, such as
slots, etc.
So again the question is, whether there needs to be one attribute
for every QoS parameter under the sun, or is there a way to do grouping?
my 2/100s
Madjid
-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior
Sent: Tuesday, December 16, 2003 11:29 AM
To: radiusext@ops.ietf.org
Subject: QoS attributes
I noticed that we are talking about QoS on the list.
In the current drafts folks are talking about QoS but are only specifying
Bandwidth attributes. There are other QoS attributes. The problem is that
there are a lot of different QoS attributes and different flavours as well.
The question is which attributes and flavours should be modelled.
I think we need a RADIUS QoS Draft in general. I started to write one and
stopped to see what was going on in a couple of other areas. (For example
Diameter and as well, work in 3GPP2 where the interface between the PDSN and
the AAA will be used to query and transport QoS attributes).
For example, one of the useful things about the CoA is that now I can change
the QoS attributes of a session mid stream. So it would be useful to define
these attributes (and not just Bandwidth).
Any comments would be greatly appreciated.
> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Tuesday, December 16, 2003 11:45 AM
> To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid
> Subject: RE: Comments on
> draft-adrangi-radius-extension-for-pwlan-00.txt
>
>
>
>
> > -----Original Message-----
> Jari wrote:
>
> o I dislike the Sect 2.2 string syntax, as it is hard
> to make this really work in a consistent manner across
> vendors and organizations. A standardized bit pattern
> approach would be better, IMHO. Then again, I'm not sure
> whether we should really extend RADIUS with a feature
> capabilities discovery.
>
> Avi's reply:
>
> A bit mask maybe a better approach.
>
> Capability advertizing is important in certain situations
> such a prepaid. We need to be able to ensure that AAA server
> can make policy decision based on the capabilities that are
> supported by the NAS. In prepaid we need to know whether the
> NAS can actually do that 'counting' and enforce the policy
> that is required. If the NAS did not then the AAA can decide
> on a different tack for providing service to a prepaid
> client. For example it can ask the NAS to tunnel the client
> to another device that can enforce the policy.
>
> We also need to know whether the NAS supports POD or COA
> (3576) messages. Again this is improtant for prepaid etc....
>
> Whether or not this is standardized or not it is important
> for the prepaid feature and hence its also part of the prepaid draft.
>
> --
> 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/>
>
--
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/>
--
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/>