[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS attributes
Hi Avi, John,
"I agree that we need a QoS Class Id, (or QoS-Bundle-Id)."
It seems that this is the closest we got to my question at least,
which was: how do RADIUS-NAS convey a variety of information,
containing a large number of parameters, between each other without
the RADIUS community having to assign an attribute to each parameter.
Is the "Class Id" (or bundle-ID) a Diameter notion? How is grouping
handled in Diameter?
Although I agree that this list neither is chartered nor has time to
solve all the QoS problems (the way NSIS does), I must say that QoS
type issues, or more specific authorization issues are AAA issues and
not just NSIS issues. A call control architecture (such as SIP) should
talk to both AAA servers and QoS managers before it sets up a call.
The problem is that authorization is not as clear cut for standards as
say authentication, since it depends on the QoS technology and service
contracts. So as Dave said, we need to leave a lot of it to VSAs.
My issue still is (without getting into specifics of QoS or WLAN
parameters) how can bundle the parameters in a way that not every
single parameter has to be listed in a RADIUS RFC?
Madjid
-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior
Sent: Friday, December 19, 2003 11:06 AM
To: john.loughney@nokia.com; dnelson@enterasys.com;
radiusext@ops.ietf.org
Subject: RE: QoS attributes
Hi John,
I agree that we need a QoS Class Id, (or QoS-Bundle-Id).
Would RADIUS only ever transport the QoS-Class-Id?
Also reading through some of the drafts you point to. I noticed that COPS
is used. I think that at least in certain cases that RADIUS/Diameter should
be utilized instead of COPS. There certainly have been discussion on this.
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: December 18, 2003 4:40 AM
> To: dnelson@enterasys.com; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
>
>
> Hi all,
>
> My 2 cents are as follows: RADext/AAAext (or whatever)
> shouldn't define QoS signaling,
> NSIS is already doing that:
>
http://www.ietf.org/html.charters/nsis-charter.html
There has been some discussion on AAA issues for QoS:
http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-0
0.txt
Looking into QoS issues, my feeling is that we want to specify QoS classes.
These classes may support a set of QoS parameters. I think that QoS will be
an area that vendors try to differentiate on; service providers may create
services that support different QoS parameters, etc. I don't think that we
can get into the QoS signaling / provisioning / definition of QoS
parameters, as that excedes the scope of AAA (either RADIUS or Diameter). I
would prefer that RADIUS / Diameter would contain a
QoS class parameter, which could make use something like a IANA QoS class
registry.
Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have
defined seperate QOS classes. One could imagine registering these classes
in IANA, and service providers could support, in various degrees, different
QoS classes. It would then be in scope of AAA to provide authorization for
these classes.
John
--
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/>
--
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/>