RE: QoS attributes

[Avi Lior <avi@bridgewatersystems.com>]

Hi Farooq,

I will give you a real usecase in DSL/Cable systems that we are involved
with.

A user wants to download a movie from a content provider.  The Operator
offers a service whereby the user can extend his bandwidth for a period of
time for a fee.  This is called bandwidth on demand or BOD.  This is done
using two mechanisms: either by pressing a "turbo" button or by going to a
website.  In either case, the system validates that the subscriber is
allowed to request for more bandwidth, if so it then checks to see what is
available (not in scope for RADIUS but there are ways to do this), and
grants the user the bandwidth by sending the network element a RADIUS CoA
message (RFC 3576) instructing the device to open up the user's pipe.  All
of this is done mid-session.

This was an example where the user has initiated the request.  A similar
scenario can happen when the Content Provider can request that the user's
pipe be opened for a period of time.

Finally, there are examples that we are exploring now where a new IP flow is
requested mid session and the QoS has to be negotiated.  RADIUS is involved
because RADIUS know who the subscriber is and what the subscriber is
allowed.  Other elements are involved such as a Policy Decision Function
(PDF) as well.  Still trying to figure out the details for this one.

But I hope that this gave you an insight that shows that these things need
to be addressed mid session as well as at the start of the session.

> -----Original Message-----
> From: Bari, Farooq [mailto:farooq.bari@attws.com] 
> Sent: December 16, 2003 5:05 PM
> To: Avi Lior; Nelson, David; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
> 
> 
> Hi Avi, all
> 
> We need to have some consensus on what is the rationale/use 
> of QoS attributes for RADIUS/DIAMETER before moving forward 
> on the topic. It seems that we have more than one perspective 
> on it. I for example see it as static information during an 
> authorized session i.e. QoS information gets exchanged only 
> during session setup where AN informs AAA of its capabilities 
> and AAA server tells the AN of user QoS susbcription. I do 
> not think RADIUS/DIAMETER servers should be involved in 
> provisioning QoS for individual services running in an 
> already authorized session later on.  However Avi's email 
> suggests it is somewhat more dynamic than this. Avi, can you 
> pls clarify if I understood your comments correctly.....
> 
> Farooq
> 
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org]
> On Behalf Of Avi Lior
> 
> Sent: Tuesday, December 16, 2003 1:42 PM
> To: 'Nelson, David'; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
> 
> 
> 
> David Nelso wrote:
> 
> > Provisioning detailed, and more importantly, potentially 
> dynamic, QoS 
> > parameters as authorization information in RADIUS or any other AAA 
> > protocol is probably not the right thing to do.  What ought to be 
> > provisioned is a "level of service" indication (e.g. 
> bronze, silver, 
> > gold, platinum) that can be used by each NAS to modify the QoS 
> > parameter negotiation process for each session.
> 
> It requires that each Hot Spot for example understand what to 
> deliver to a Bronze User or a Gold user etc.....
> 
> Like filter id, this just does not scale!
> 
> We need a way to explicitly push attributes down to the NAS.  
> Equally important is to make sure that the NAS tell us what 
> it can currently honour. This will alow the home RADIUS to 
> make an appropriate policy decision.
> 
> 
> 
> --
> 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/>