[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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