RE: QoS attributes

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

Avi,

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 :)

Thanks,

Madjid

-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior
Sent: Friday, January 02, 2004 10:39 AM
To: john.loughney@nokia.com; Avi Lior; radiusext@ops.ietf.org
Subject: RE: QoS attributes




> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] 
> Sent: Sunday, December 28, 2003 6:35 AM
> To: avi@bridgewatersystems.com; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
> 
> 
> Hi Avi,
> 
> > There are two problems with this approach is certain conditions:
> > 
> > Dealing with a QoS Class Id only only addresses static arrangements 
> > where both parties agree apriori on the contents of that are 
> > represented by a particular instance of the QoS Class Id.  This is 
> > useful but its not the only model.
> 
> > In some cases the QoS maybe more dynamic, we therefore need the 
> > flexibility to transfer the QoS Class Id and/or QoS parameters.
> 
> Agreed, however the more dynamic model is something that is 
> probably beyond RADext to standardize.

I don't particularly want to standerdize all QoS models.  But we are
starting to see QoS related work coming into RADIUS and Diameter from the
following areas:  WLAN, 3GPP2 (Go/Gq) interfaces and probably 3GPP.

The SDO will want to transport their QoS attributes in AAA (we don't know
what these are).  Learning from past experiences they will use VSAs which is
fine but it will cause interoperability issues down the road.  So the
question is can we be more proactive and accommodate the various QoS models
here?

Or as a minimum provide a framework or guidelines as to how deal with the
various QoS models and then have one or more RFCs for each QoS model thereby
achieving interoperability.


> > Something that I understand is Bandwidth.  Two parties can agree on 
> > how to bill for bandwidth without having to agree on 
> descrete bundles 
> > of bandwidth. We bill bandwidth on bits/second.
> 
> So, why are we not discussing Bandwidth?  If I understand, 
> you want to support a bandwidth attribute.  If so, I think 
> that a more comprehensive proposal would be good, one which 
> discusses the trade-offs, etc.  QoS is probably a swamp if we 
> start at supporting multiple attributes.

Bandwidth is just one of the attributes. Bandwidth is being discussed now.
And other QoS attributes would come to light shortly.
 
> > Also I am very surprised about the resistance to do this.  If we 
> > justify doing Credit Control over AAA why is this a problem?
> 
> I don't see the comparison, actually.  The Credit Control is 
> trying to standardized a token based approach for doing AAA 
> authorization. It is not standardizing (or at least trying to 
> carefully work
> with) billing models, etc.  

I agree with you and that is why I raised the question.  When I brought up
QoS, I did not intend for RADEXT to define new QoS attributes but rather to
show how existing QoS parameter would be transported within AAA messages.
Whatever the QoS attributes are.

I think the disconnect is that you are thinking I want to define (new) QoS
attributes and/or (new) QoS models.  I don't want to do this at all.

Avi.

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