RE: QoS attributes

["Roy, Radhika R, ALABS" <rrroy@att.com>]

Let us take a single node/server situation where there is only one AAA
server.

Now, the situation is this: Let a SIP call comes with SDP information of
audio, video, and data where QoS needs to be supported for each kind of
media.

How do you want to represent QoS attributes for each kind of media?

Even if you represent QoS attributes for each media, what does the AAA
server do with all those QoS attributes? How do go from there to deal
with those attributes? (Please note that it is a single node/server
situation, not AAA node/server to node/server communications as it can
be seen in the case of roaming.)

Radhika R. Roy
rrroy@att.com

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Saturday, January 03, 2004 4:05 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Avi Lior'; john.loughney@nokia.com; radiusext@ops.ietf.org
Subject: Re: QoS attributes


Nakhjiri Madjid-MNAKHJI1 wrote:

> Maybe I am missing your point as well, but again, the grouping
>  comes into my mind: Can you group the parameters
> into a generic QoS attribute, with subtypes (or AVPs) that the AAA
> server or at least the AAA intermediaries don't have to understand
> in details? They just know it is a QoS related info they are passing
> along or receiving?
> 
> At the moment I am going to through Diameter base RFC,
> trying to understand how Diameter does this!
> I found the grouped AVP values, but I am not clear if all the
> original AVPs must be understood by the Diameter nodes?
> Anybody cares for a hint :)

Intermediate nodes may not need to understand the AVPs. (Grouping
has nothing to do with that, its just a representation.)

For the transport of this information to be meaningful, however,
the end nodes have to *do* something with the information. It
may not be necessary that they understand the attributes, but
on the server side you have to at least

- Determine whether the NAS/client/service nodes are capable
   and willing to provide the requested QoS. Alternatively, you
   just provide the information on a do-it-if-you-can basis.
   In Diameter, you would probably set the 'M' (Mandatory) bit
   in the former case and reset it in the latter.
- Determine what QoS this particular sesssion should get, on
   a policy basis. This could be e.g. a configuration on a user
   database, but it could also be something more complicated.

On the NAS side you have to at least

- Parse the AVPs that you have been given, if the 'M' bit is
   on.
- Force the effect requested by the AVPs, for instance by
   setting the max bandwidth parameter on the interface, talking
   to an access point about the priority it gives to this
   particular session, or something like that.

In conclusion the 'M' bit functionality in Diameter allows
you a limited form of control how the QoS instructions are to
be processed. Given that current nodes do not support the
kind of QoS attributes this BOF is looking at, its likely that
most usage would have to be M=0, at least for a while. However,
for the QoS attribute functionality to be useful, the end
nodes have to "understand" them in some manner. We have the
protocol means to carry the information in AAA without requiring
too much of that, but just carrying them in AAA is not enough
for the effects. I think one big question here is that if
link layer or SDO specific QoS attributes become available,
what is the likelihood of the server attributes matching
those understood by the NAS in a roaming setting.

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

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