Subject: [AAA-WG]: RE: Diameter CCA: Number of sessions per user

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Mon, 25 Feb 2002 14:35:00 +0100

Hi Paco,

>the credit not consumed must be returned back to the user account, it
>means the money to return back is the 'reserved' credit minus the credit corresponding to the
>'Used-Service-Units'.... Is it OK?
YES

The credit control application contains all accounting AVPs specified in the base protocol, only
the additional AVPs are listed in the draft, so the second option is covered.

Regards............Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 21. helmikuuta 2002 19:12
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Diameter CCA: Number of sessions per user

Hi All,

     In the point 3.2 of the document 'Diameter Credit Control Application', is described the
Service Credit Control using several interrogations (session control). When a session is opened
(START_RECORD), the client ask for the server an amount of credit (stated in money, service units
and so on....) which is reserved until the next request (ACR) of the multi-interrogations dialogue
is received (INTERIM_RECORD or STOP_RECORD). When this new ACR is recived, a new amount of credit
asked by the client is reserved. As described in the document this amount of credit 'reserved' for
the user is stored in the server, so when the client finishes the dialogue (STOP_RECORD), the ACR
includes the 'Used-Service-Units' AVP indicating the real amount of credit consumed since the
previous interrogation. Then, the credit not consumed must be returned back to the user account, it
means the money to return back is the 'reserved' credit minus the credit corrsponding to the
'Used-Service-Units'.... Is it OK?

The question is: What happens when the user has serveral sessions opened at time? There is nothing
about that in the document but I suppose that we can not establish limits for the number of sessions
a user can have at time. A user could be downloading a document at the same time he is looking for
the neares restaurant or buying the tickets for the last Swertzeneger film. I suppose the server
must be able to identify which ACR corresponds to which session, however.... How could the server
identify this session? Maybe I'm confused but I did not find neither an AVP able to identify it, nor
a field corresponding to the Diameter Base protocol able to be used to identify the session (I
understand the server cannot use neither  the 'Hop-by-Hop' nor the 'End-to-End' identifier to
associate that a  received request corresponds to a specific session opened. This way, when a user
has several sessions opened and receives a request (INTERIM_RECORD as an example) must be able to
know which session must delete the stored credit and reserve a new credit again. I have been
thinking about two solutions:

1.- Not to store the reserved credit in the server. The client could ask for the credit and receive
it in the 'Granted-Service-Units' AVP, when the session is finished the client could send a
different AVP called 'Remaining-Service-Units' instead of the 'Used-Service-Units' AVP. This way the
session have not to be controlled by the server. This solution could have a problem, the fraud
produced due to the lack of the session by the server. The server must trust the client, because the
client could set the 'Remaining-Service-Units' AVP to a random value....  It could be difficult if
the home domain receives request from clients from visited domains, a formal agreement must exists
in this scenario to avoid fraud.

2.- Introduce in the request and answer the  AVP called  'Session-ID' (code 263) to identify the
session. This way the session is always identified for session oriented service control (several
queries).

In my humble oppinion, the second one is the best option to be able to solve this problem.

regards,

Paco.