[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS attributes
John:
As long as authentication, authorization, and accounting for any services (e.g., VoIP services/SIP, QoS services, any other resources) of a given call are concerned, it is in the domain of the AAA protocol.
However, services or calls are usually reside in the application layer, and we should restrict ourselves to remain in that layer as per standards. In the same token, calls (e.g., opening of a transport channel) can be in the transport layer (e.g., IPSec, TLS) as well .
Now, there are some dependency. For example, if authentication/authorization services are provided for the SIP/VoIP services, it means it should also deal with QoS resources in the SIP layer if the AAA server wants to do something specific to QoS (e.g., use of specific codecs or applications - this ,in turn, will lead to detail QoS parameters for each media) of that SIP call.
If the authentication is provided for a user for the transport layer (e.g., IPSec, TLS) only, we can deal with the IP/Transport layer QOS resources (e.g., RSVP, DiffServe) authorization. If we stop here for the Transport layer call, as I understand from your email, I think that we are OK.
If a SIP user is authentication, it will also mean how to authorize the use of resources like codecs (e.g., audio, video) and applications (e.g., white board, data sharing). If we stop here for the SIP call, as I understand from your email, I think that we are OK.
From AAA server point of view, the QoS attributes MUST be generic enough, like authentication/authorization, to satisfy all the needs for all types (e.g., application, transport) of calls (e.g., SIP, IPSec/TLS). This is our challenge in creating the common QoS attributes standard for the AAA server.
Hope that others will also add to this.
Radhika
-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Sunday, January 04, 2004 3:52 AM
To: Roy, Radhika R, ALABS; 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/>