[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS attributes
Good question John,
Well what do you call Bandwidth attributes and transporting them? We are
certainly talking about tranpsorting Bandwidth parameters in a RADIUS
message. It certainly makes sense to me to include Bandwidth attributes as
part of the authorization of a given service.
Is Bandwidth part of QoS? I think it is.
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Sunday, January 04, 2004 3:52 AM
> To: rrroy@att.com; jari.arkko@piuha.net; Madjid.Nakhjiri@motorola.com
> Cc: avi@bridgewatersystems.com; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
>
>
> Roy, Avi,
>
> I am getting quite confused by this discussion. Could I ask what
> we are actually discussing? RADIUS/Diameter are not
> signaling protocols, they are AAA protocols. RADIUS/Diameter
> should not transport QoS information. My expectation is that
> they would be involved in authorization for QoS for some
> services, but doing more would seem to be out of scope for
> AAA protocols.
>
> Am I missing something?
>
> John
>
> > -----Original Message-----
> > From: ext Roy, Radhika R, ALABS [mailto:rrroy@att.com]
> > Sent: 03 January, 2004 16:34
> > To: jari.arkko@piuha.net; Nakhjiri Madjid-MNAKHJI1
> > Cc: Avi Lior; Loughney John (Nokia-NRC/Helsinki);
> > radiusext@ops.ietf.org
> > Subject: RE: QoS attributes
> >
> >
> > 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/>