Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Thu, 10 Apr 2003 12:09:11 +0200

Hi Avi,

(I assume that your mail was pointed to the aaa-mailing list.)

It is associated with accounting because of rating and billing. 
The requested service must be rated before granting any quotas
to the client. This is needed in order to decide whether the end
user's account covers the requested service and to be able to grant
right amount of quotas. So the rating itself that is needed for the
decision is more related to accounting functionality than authorization.
And since the prepaid server will decrease the account during the 
session in order to bill to user for the usage of the service the 
billing as well is accounting related functionality.

In order to rate the service, rating input parameters are needed,
that is the authorization commands would need to carry all the rating
input parameters. The server also must return some control parameters to
the client (e.g. access device), so that the client can monitor the service
execution according to the instructions returned by the server.

Because the access device doesn't necessarily know if the user is 
postpaid or prepaid, then all authentication and authorization requests
would need to carry rating input parameters, also in case of postpaid users.
Also there might be some existing service specific authentication and
authorization protocols, which then need to be updated to include these 
parameters.

The client may need more quotas during the services and it may send 
interim request to the server requesting more quotas and reporting used
quotas, i.e. session based credit control (or prepaid). The Diameter base
accounting supports session based accounting (start, interim and stop) 
and this suits very well for credit control as well. This is also one 
reason why we want to associate the credit control application with the 
accounting, i.e. only few additional AVPs + new accounting state machines
(credit control session state machines) are needed. 
 
When session based credit control is used then credit control server must
maintain the session. If authorization commands would be used, then
during initial authorization the authorization server should establish the
session towards credit control server in order to perform 'prepaid 
authorization'. Then the re-authorization for additional quotas during the
session should flow through the AAA server to the prepaid server, adding an 
extra stateful hop (proxy, translator) in the signaling. When using 
accounting commands the client can communicate directly with the prepaid 
server.

You are right the draft is not just for the 3GPP and of course they also 
authenticate and  authorize the subscriber for the network access and 
for the services as well. For instance for multimedia services the
Diameter Multimedia Application can be used.

Regards......Harri

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: 9. huhtikuuta 2003 22:18
> To: Harri Hakala (LMF); [email-masked]'
> Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt
> 
> 
> Hi,
> 
> I have a question.  Why is Credit Application associated with 
> accounting?
> 
> Seems to me that granting prepaid quotas is really an authorization
> exercise. You are authorizing the subscriber to use a service 
> for a period
> of time.
> 
> This may seem like a petty philosophical point however it 
> does have serious
> technical ramification.  One of them that I have a huge 
> concern over is a
> timing issue.  In past implementations, for practical reasons 
> we had to
> solve these timing issues by combining Service Authorization 
> and Prepaid
> Authorization.
> 
> The home AAA during authentication discovers that the user 
> requires prepaid
> and then request prepaid authorization.  If all is 
> successful, the prepaid
> authorization(typically a quota) and the service 
> authorization are sent to
> the Access Device.
> 
> Making it an accounting activity decouples it from 
> Authorization and creates
> these problems.  My opinion is that accounting should be used 
> for reporting
> -- we still need real-time accounting.  But when we are 
> applying controls
> these should be related to Authentication and Authorization commands.
> 
> I realize that in 3GPP this won't be an issue -- because you 
> are not really
> authenticating the subscriber.  But this is not just a 3GPP 
> specification --
> right?
> 
> Comments?
> 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Apr 2003 05:58:30 -0700 (PDT)

> So the rating itself that is needed for the

Are we assuming that the accounting and authorizations servers are
separate and that only the accounting server has access to the rating
engine?

> billing as well is accounting related functionality.

Is it possible for the rate to change unexpectedly, so that the session
time cannot be calculated at session initiation? In other words, is
interim accounting required for this application?

> input parameters.

Since authorization and accounting commands contain the same information,
why wouldn't this be true for accounting commands, too?

> would need to carry rating input parameters, also in case of postpaid users.

Why wouldn't accounting requests also need those parameters?

> authorization'.

Yes.