QoS attributes

[Avi Lior <avi@bridgewatersystems.com>]

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/>