RE: QoS attributes

[<john.loughney@nokia.com>]

Hi Jari,

> > Taking a systematic view, I would think that AAA protocols can
> > do the authorization & accounting side of any QoS-aware services.
> > COPS can be used inside of the network to transport QoS
> > policies to the enforcement points, to ensure that QoS parameters
> > are not exceded. 
> 
> We have a couple of fixed things in the architecture, namely:
> 
>    o  The client, obviously.
> 
>    o  The Policy Enforcement Point (PEP). If the link of
>       whose bandwidth is being controlled terminates on
>       a node, that's where you _have_ to do to the
>       enforcement.
> 
>    o  The home network. This is the ultimate decision point
>       regarding the authority to request some QoS. (Of course,
>       in many cases the decision is delegated to others "offer him
>       the best service you can, our roaming contract price
>       is in any case fixed".)
> 
>    o  The protocols between the client and the PEP. For instance,
>       it could be some yet-to-be-defined 802.11k bandwidth allocation
>       scheme on the link, RSVP, PPP multilink negotiation, or 
> 	  whatever.
>       No one is proposing to replace these protocols with either COPS
>       or AAA.

Agreed.  However, for the last bullet: protocols between the client and the PEP,
a reasonable assumption could be that certain services have hard-coded QoS,
so the client doesn't have to signal anything more than just initiating services.
For example, SIP video call assumes certain a QoS profile, and if the request
for the service is successful, it means the QoS profile is fufilled.

> Then we have some other things which are not so fixed, such as
> the protocols between the PEP and the home network.
> 
> I think this model helps us understand the issues better. For instance,
> when we say "AAA is not a QoS signaling protocol", do we really mean
> that AAA should not be used the client and the PEP, do we mean that
> it should not be uesd between the PEP and the home network, or what?
> 
> I think you John are suggesting an architecture like this:
> 
>    1. Client---(RSVP)---PEP---(COPS)---Local AAA---(Diameter)---Home AAA

Well, there are many ways to skin a cat, the above was just one way to do it.

> A couple of other possible alternatives would include:
> 
>    2. Client---(RSVP)---PEP---(Diameter)---Local AAA---(Diameter)---Home AAA
> 
> and:
> 
>    3. Client---(RSVP)---PEP---(COPS)---Local PDP---(COPS+)---Home PDP

These are other ways.  My feeling is that some of these will be determinted
by the service provider.  If you replace PEP with NAS (they could be the
same box) then using something like Diameter is very reasonable.
 
> What are the tradeoffs involved in these different architectures?
> Here are some tradeoffs that I was able to identify: number 3 appears
> to require some extensions of COPS, such as a DIAMETER/RADIUS -like
> roaming & routing scheme. Numbers 2 or 3 would be simpler than number 1,
> because just one protocol is needed instead of two.

Agreed - I just wanted to use as many protocols as possible ;)
 
> Also, who is binding the authentication of the user into the various
> QoS requests that happen elsewhere in the network? How? Or do we expect
> users to authenticate to every router that the send an RSVP request to?
> I'm hoping someone has answers to these questions already...

This is something that we are looking at in NSIS.  NSIS is planning on using
an RSVP-like mechanism for QoS signaling (& middlebox traversal).  Not all
routers are RSVP / NSIS aware, but hopfully things like NASes & PEPs will
be.  My guess is that the user will signaling to something like a NAS on
the datapath, the NAS checks the users credentials & possibly signals to
the AAA server to ensure authorzation, etc.

br,
John

PS - I think we are getting a little bit into the weeds on this topic. I don't
think RADext will architect a complete solution on this topic.

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