Subject: FW: [AAA-WG]: ISSUE

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Mon, 4 Feb 2002 14:50:49 +0100

Hi,

I try explain why in my opinion a little more functionality is
needed to support 'real time accounting'. I don't think that we need
to add any new accounting record types to the protocol to provide 
this support, only a few additional AVPs are needed.

I have used definitions 'non real time accounting' and 'real time
accounting' and I mean by this: 
Non real time accounting: 
the collecting information on resource usage, so that the 
collecting information does not affect, in real time, 
the service rendered.

Real time accounting: 
the collecting information on resource usage, so that the 
collecting information can affect, in real time, the service
rendered and therefore directly interacts with the
session/service control.

To support real time accounting (or credit control or 
prepaid or..) the first accounting message MUST be sent
before the accounting client allows any service to the end
user.
This is allowed according to base protocol (or ?)
but there is need for statement that if real time accounting
will be used the initial accounting message must be sent and 
its response must be received before service is offered to the 
end user.  

There services which can use different kind of accounting controlling
units. Some services can be charged based on used time or data volume. 
There is also services which can be charged based on number of events 
or amount of money. Client needs provide information what kind of units
(time, volume, event, money ...) it will use and the amount of the 
needed units in initial accounting message.
I think that this information is missing from the base protocol
accounting, if real time accounting is required. There is need for a 
new AVP (Service Unit Type), which contains the requested unit type
and possibly also the requested unit amount. 

The Accounting Server should then inform the client
when it must send next accounting message (either INTERIM or STOP) 
This is supported already now in base protocol, but there is need some
minor improvements. 
The Accounting-Interim-Interval AVP from the base protocol
with improvements (defining the Unit type) can be used for this, or it is
also possible to use a new AVP, Granted-Service-Unit. This AVP contains the 
amount of units that the Client can provide to the end user until a new 
Accounting Request must be sent.  

If the returned Granted-Service-Unit contains the final units for the service
(i.e. no more credit left), an indication must be returned to client that after
these units have expired, the Client is responsible for terminating the service
and sending the final accounting record (STOP) to accounting server.
To able to support real time accounting we need to add a new AVP 
(Final-Unit-Indication AVP) to Answer command to indicate that the answer command
contains the final units for the service. In my opinion this is missing from the
base protocol.

Also to be able to support real-time accounting the interim accounting information 
must be non-cumulative. This purpose a new AVP is needed to accounting request
commands, Used-Service-Unit. This AVP contains the amount of used units since
the previous Accounting-answer command.

By adding these new AVPs to Diameter accounting it will support both non real time
and real time accounting.

An option is also to create a diameter application that can be used for real time
cost and credit control.
We have made a proposal for this kind of application, called Diameter Credit Control 
Application.
http://search.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-01.txt
In this draft also previous mentioned AVPs are defined. 

Best Regards......Harri 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: 1. helmikuuta 2002 9:14
To: Glen Zorn
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: ISSUE

> Ok, I'll go out on a limb here and call this a new feature (not just new,
> but application-specific) and suggest that it be immediately rejected by the
> WG Chairs.

One of the beauties of AAA is that Accounting focusses on providing
estimates of resource consumption. The usage of that information or the
purpose of the transfer is immaterial, yet many types of service can 
still be provided. This includes prepaid, postpaid, and even unpaid
(guest) service. 

Before this Issue will be considered, I would like to understand why this
functionality cannot already be provided within the protocol as it exists. 
No evidence is provided in the issue report to justify the necessity of
the change.

Some comments below:

> > The postpaid accounting session is established to transfer CDRs
> > (Charging Data Records) from client to server. 

AAA does not transfer CDRs. It transfers binary accounting data which are
used to create CDRs.

> These CDRs are used for billing purposes, typically once a month. 

Discussion of billing practices is outside the scope of the AAA WG. 

> doesn't need to be completed  simultaneously with the communication
>session.

It sounds like Diameter accounting should work just fine for this. 
So why is a change being proposed?

> The prepaid accounting session is established to transfer
> charging information from client to server for rating purposes.

The reason for the transfer is not relevant to the protocol. 

> The cost of the communication session is calculated and according
> to these calculations money is reserved from subcribers account.
> If there is no credit left in subscribers account or the credit
> is used during the communication session, the prepaid accounting
> session will be terminated. That termination will also cause the
> termination of the communication session.

Seems to me that this effect could be achieved without any protocol
changes. So why is a change necessary?