Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review

From: <[email-masked]>
Date: Thu, 22 May 2003 13:55:35 +0300

Bernard,

>  It seems cleaner to me to use a conventional authentication
>  request/response sequence to inform the Diameter server of
>  the requested service, and have the Diameter server do the
>  service rating, and check the user's credit allocation.
>  The Diameter server can then return the allocated resource
>  usage prior to re-authorization. When the Diameter client
>  has expended the allocated resources it will send a
>  re-authorization request (actually you probably want
>  it to send one sooner in case there are delays). The
>  Diameter server can then check the user's credit
>  limit and the service rating again and allocate more
>  resources, or deny the request and force the user off.

Are you suggesting something like this:

NAS		AAA Server
-------auth req----->  
                       a) check user credit
                       b) if OK, deduct amount (if approriate)
<------auth  ans ---	  and reply

some time goes by

-----re-auth req----->  
                       a) check user credit
                       b) if OK, deduct amount (if approriate)
<----re-auth  ans ---	  and reply

and so on?

John

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 May 2003 06:07:44 -0700 (PDT)

> <------auth  ans ---	  and reply

a) but not b). The auth req/ans sequence does not demonstrate that the
service event has actually occurred -- that is what accounting messages do.
So while you can check user credit (and place limits on session-time and other
resources) via the answer it is probably not appropriate to credit/debit
at that time. This can wait until the accounting messages are sent.

> <----re-auth  ans ---	  and reply

In this figure, I'm not clear whether we're talking about
re-authentication or re-authorization. I hope it's the latter.  What we
need in the first authentication answer is AVPs which give the time
(or other resources) until session re-authorization (NOT
re-authentication).  The RADIUS Session-Time attribute isn't appropriate for
this, since it forces re-authentication when Termination-Action=1 (RADIUS).
So you need to define new AVPs, I think.

Assuming that this is done, on re-authorization the user credit is checked
again, and new time/resources can be allocated to the session.  Note that
it is also possible to initiate re-authorization from the Diameter/RADIUS
server side, via dynamic authorization messages.  Thus, the server can
check the declining user credit via the interim accounting messages and
decide to change the allocated resources/time at any point.