Re: QoS attributes

[Jari Arkko <jari.arkko@piuha.net>]

Hi John,

> > The question is this: Can we not develop standards 
> > complementing both COPS and DIAMETER/RADIUS as they are also 
> > a part of IETF standard protocols?
>
>
> 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.

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

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

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.

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

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