RE: QoS attributes

[Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>]

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Monday, December 22, 2003 2:07 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: radiusext@ops.ietf.org
Subject: Re: QoS attributes


Nakhjiri Madjid-MNAKHJI1 wrote:

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

Oh that's easy -- we can just put it in some opaque string, vendor
specific attribute, or design some OID hierarchy around the parameters.

Madjid>>I wonder if we could something in between. I.e.
It would be nice to have a hierarchy, where the server would 
recognize that an attribute is a QoS or L2 definition (WLAN, CDMA..)
attribute and then leave the details either as opague stings or VSAs?
Currently (correct me if I am wrong), it seems that if something is Vendor
specific, only a vendor ID is provided, but it does not say anything further.

But the question is do we want to? The hard issue is how all this works
without buying the whole network from one vendor. Or how a home server
can control parameters in a roaming situation when it has never even
heard of the link technology that the foreign network uses. Essentially,
there would have to standardization of the parameters. Whether or not
that happens inside a particular IETF RFC is another question.

Madjid>> Again, VSA kind of force you to buy from one vendor, they
don't promote interoperability. It seems they don't allow for negotiations
between vendors either. However, if you had a method where the servers
would at least know that the issue is QoS or an L2 attribute, they
may be able to query an entity that knows, for instance a QoS manager
or a mobility manager. I don't think we should require AAA server to 
understand all QoS techs and all L2 techs and all mobility techs and
so on, but many architectures do require that AAA server talks to other
entities in the network (QoS manager or Mobile IP HA).

Maybe the best we can do at the moment is this Gold-Silver-Etc
service level classification. 

Madjid>> Based on the discussions we had, Generic service level classes
are starting to appeal to me. However, I like to see categorizations that have come
out of IETF and are widely accepted, such as ToS or DSCP (I am not
sure how MPLS does classifications) and with many levels (DSCP has ~64) so anybody
can use them as they see fit (like DSCP bits), rather than too few levels
such as Gold-Silver,bronz, unless we run them all the way to alkali metals :) 
Did I miss any RFC that defines things in Gold-Silver-Bronz??

Madjid
 
Or perhaps we could do that, and
the specific, more detailed parameters for a popular link layer,
such as 802.11 wireless LANs.

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