Subject: [AAA-WG]: ISSUE

From: <[email-masked]>
Date: Fri, 1 Feb 2002 09:03:11 +0200

Description of issue: Separation of the prepaid and postpaid accounting sessions
Submitter name: Juha-Pekka Koskinen 
Submitter email address: [email-masked] 
Date first submitted: January 31, 2002 
Reference: draft-hakala-diameter-credit-control-01.txt
Document: Base (draft-ietf-aaa-diameter-08.txt) 
Comment type: T 
Priority: 1
Section: 9.5 and 9.8.1 
Rationale/Explanation of issue: 

There are two different kind of accounting sessions used for charging purposes.

The postpaid accounting session is established to transfer CDRs (Charging Data Records) from client to server. These CDRs are used for billing purposes, typically once a month. The transfer of the CDRs is not critical task from the communication session point of view. The CDRs could be transferred only when the communication session has been disconnected, so the actual postpaid accounting session doesn't need to be fully completed  simultaneously with the communication session.

The prepaid accounting session is established to transfer charging information from client to server for rating purposes. 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.

Requested change: 
Proposal 

As these two accounting sessions has different logic, it would be very useful to specify new values used in Accounting-Record-Type AVP (Chapter 9.8.1):

EVENT_PREPAID		5
	An Accounting Event Prepaid record is used to indicate that one-time prepaid event has occured (meaning that the start and end of the event are simultaneous). This record contains all information relevant to service and granted threshold.

START_PREPAID		6
	 An Accounting Start Prepaid record is used to indicate that a prepaid service will have measurable length. An Accounting Start Prepaid record is used to initiate that money reservation will be needed for this session. This record contains all information that is relevant to determine cost of the service and granted threshold.

UPDATE_PREPAID		7
	An Accounting Update Prepaid record is used to indicate that a prepaid service will need more credit to continue. It is also used when service (client) need to update itself tariff of the ongoing accounting session. This record contains all information that is relevant to determine cost of the service and granted threshold.

STOP_PREPAID		8
	An Accounting Stop Prepaid record is sent to terminate and prepaid accounting session. This record also contains unused amount of the granted threshold.

Also the chapter 9.5 should have following structure:

9.5  Accounting Records

   In all accounting records the Session-Id and User-Name AVPs MUST be
   present. If strong authentication across agents is required, as
   described in [11], the CMS-Signed-Data AVP may be used to
   authenticate the Accounting Data and Service Specific AVPs. It is not
   typically necessary that the CMS-Signed-Data AVP cover any additional
   AVPs, but it is permitted as long as the AVPs protected are defined
   to have their 'P' bit set.

9.5.1 Postpaid Accounting Records

   Different types of postpaid accounting records are sent depending on the
   actual type of accounted postpaid service and the accounting server's
   directions for interim accounting. If the accounted postpaid service is a one-
   time event, meaning that the start and stop of the event are
   simultaneous, then the Accounting-Record-Type AVP MUST be present and
   set to the value EVENT_RECORD.

   If the postpaid accounted service is of a measurable length, then the AVP MUST
   use the values START_RECORD, STOP_RECORD, and possibly,
   INTERIM_RECORD.  If the accounting server has directed interim
   accounting to be enabled for the session, but no interim interval was
   specified, two accounting records MUST be generated for each service
   of type session.  When the initial Accounting-Request is sent for a
   given session is sent, the Accounting-Record-Type AVP MUST be set to
   the value START_RECORD. When the last Accounting-Request is sent, the
   value MUST be STOP_RECORD.

   If a specified interim interval exists, the Diameter client MUST
   produce additional records between the START_RECORD and STOP_RECORD,
   marked INTERIM_RECORD. The production of these records is directed
   both by Accounting-Interim-Interval as well as any re-authentication
   or re-authorization of the session.  The Diameter client MUST
   overwrite any previous interim accounting records that are locally
   stored for delivery, if a new record is being generated for the same
   session. This ensures that only one pending interim record can exist
   on an access device for any given session.

   A particular value of Accounting-Sub-Session-Id MUST appear only in
   one sequence of accounting records from a DIAMETER client, except for
   the purposes of retransmission.  The one sequence that is sent MUST
   be either one record with Accounting-Record-Type AVP set to the value
   EVENT_RECORD, or several records starting with one having the value
   START_RECORD, followed by zero or more INTERIM_RECORD, and a single
   STOP_RECORD. A particular Diameter application specification MUST
   define the type of sequences that MUST be used.

9.5.2 Prepaid Accounting Records

   Different types of prepaid accounting records are sent depending on the
   actual type of accounted prepaid service and the accounting server's
   directions for interim accounting. If the accounted prepaid service is a one-
   time event, meaning that the start and stop of the event are
   simultaneous, then the Accounting-Record-Type AVP MUST be present and
   set to the value EVENT_PREPAID.

   If the prepaid accounted service is of a measurable length, then the AVP MUST
   use the values START_PREPAID, STOP_PREPAID, and possibly,
   UPDATE_PREPAID. When the accounting server has granted threshold value
   to used for the session, but the granted threshold is not used completely or the
   client's tariff doesn't change, two accounting records MUST be generated for each    
   service of type session.  When the initial Accounting-Request for a
   given session is sent, the Accounting-Record-Type AVP MUST be set to
   the value START_PREPAID. When the last Accounting-Request is sent, the
   value MUST be STOP_PREPAID.

   When granted threshold value is used up or the client's tariff will change,
   the Diameter client MUST produce additional records between the START_PREPAID and 
   STOP_PREPAID records, marked UPDATE_PREPAID. The production of these records is directed
   both by Accounting-Interim-Interval, application specific AVP concerning granted 
   threshold as well as any re-authentication or re-authorization of the session.  The 
   Diameter client MUST produce UPDATE_PREPAID record when granted threshold is used up.

   A particular value of Accounting-Sub-Session-Id MUST appear only in
   one sequence of accounting records from a DIAMETER client, except for
   the purposes of retransmission.  The one sequence that is sent MUST
   be either one record with Accounting-Record-Type AVP set to the value
   EVENT_PREPAID, or several records starting with one having the value
   START_PREPAID, followed by zero or more UPDATE_PREPAID, and a single
   STOP_PREPAID. A particular Diameter application specification MUST
   define the type of sequences that MUST be used.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 31 Jan 2002 23:13:55 -0800

[email-masked] [mailto:[email-masked]] writes:

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.

> The postpaid accounting session is established to transfer CDRs
> (Charging Data Records) from client to server. These CDRs are
> used for billing purposes, typically once a month. The transfer
> of the CDRs is not critical task from the communication session
> point of view. The CDRs could be transferred only when the
> communication session has been disconnected, so the actual
> postpaid accounting session doesn't need to be fully completed
> simultaneously with the communication session.
>
> The prepaid accounting session is established to transfer
> charging information from client to server for rating purposes.
> 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.
>
> Requested change:
> Proposal
>
> As these two accounting sessions has different logic, it would be
> very useful to specify new values used in Accounting-Record-Type
> AVP (Chapter 9.8.1):
>
> EVENT_PREPAID		5
> 	An Accounting Event Prepaid record is used to indicate that
> one-time prepaid event has occured (meaning that the start and
> end of the event are simultaneous). This record contains all
> information relevant to service and granted threshold.
>
> START_PREPAID		6
> 	 An Accounting Start Prepaid record is used to indicate
> that a prepaid service will have measurable length. An Accounting
> Start Prepaid record is used to initiate that money reservation
> will be needed for this session. This record contains all
> information that is relevant to determine cost of the service and
> granted threshold.
>
> UPDATE_PREPAID		7
> 	An Accounting Update Prepaid record is used to indicate
> that a prepaid service will need more credit to continue. It is
> also used when service (client) need to update itself tariff of
> the ongoing accounting session. This record contains all
> information that is relevant to determine cost of the service and
> granted threshold.
>
> STOP_PREPAID		8
> 	An Accounting Stop Prepaid record is sent to terminate and
> prepaid accounting session. This record also contains unused
> amount of the granted threshold.
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 Jan 2002 23:13:38 -0800 (PST)

> but application-specific) and suggest that it be immediately rejected by the

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:

> > (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?

> charging information from client to server for rating purposes.

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

> termination of the communication session.

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

---

From: Johan Johansson <[email-masked]>
Date: Fri, 01 Feb 2002 11:35:04 +0100

>changes. So why is a change necessary?
I don't see the need for the requested change either, but are you saying 
that it would be acceptable for an accounting server to start sending ASRs?

j

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 1 Feb 2002 02:05:00 -0800

> that it would be acceptable for an accounting server to start

I can't find any place where the proposed change mentions sending an ASR: it
appears to me that the Diameter "client" is responsible for terminating
service (only reasonable, since it is known in advance how many "units" of
service should be delivered).

---

From: Johan Johansson <[email-masked]>
Date: Fri, 01 Feb 2002 12:08:08 +0100

>service should be delivered).
My question was prompted by Bernard's comment and not the suggested change.

j