[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS attributes
Thanx for the comments. See my replies in line:
>
> 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??
The concept of applications has been addressed in Diameter.
The concept of grouping related has been address in Diameter as well.
However, if you look at some of the emails you will see some discussion on
subtypes that I have been pushing for.
> 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.
Yes I agree that this is a difficult issue and there may not be away for
doing this other than to address specific requirements.
> 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/>