Subject: [AAA-WG]: Accounting fault resilience

From: Johan Johansson <[email-masked]>
Date: Thu, 28 Feb 2002 22:28:05 +0000

Hi, All.

I'm wondering what the requirements on the client sending records when 
recovering from a fail-over is.

Section 9.4 states (I think - keeping up with changes is difficult these 
days);

Upon a reboot,
   the client MUST starting sending the records in the non-volatile
   memory to the accounting server with appropriate modifications in
   termination cause, session length, and other relevant information in
   the records.

What information may change? I am mostly thinking about:

1. What should the record type be? If we limit ourselves to the ones in 
draft-8, is it ok to just send a STOP_RECORD. Could a session, now 
obviously long gone, be compressed into a single EVENT_RECORD? A single 
STOP_RECORD? Would it be necessary to first send a START_RECORD if no 
record was ever acked?

2. What if any session ids need to be maintained? Is it sufficient if 
the user can be identified? A Diameter client may among other things be 
a gateway from other AAA protocols, most probably some form of RADIUS, 
where the original device may be storing its own records non-volatilely 
and may wish to resend them on recovery. Can the Diameter client know 
what ids to use in such a case without storing *all* accounting session 
states for arbitrary amounts of time?

j

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 28 Feb 2002 23:41:43 +0200

> states for arbitrary amounts of time?

I'm thinking that we should do any of the very complicated things. It
is still possible for the a device to crash and lose it's memory
completely. So servers must be able to deal with a missing Stop
record, for instance.

But I see that the text may not be clear enough to make this
obvious. How about:

 Upon a reboot,
    the client MUST starting sending the records in the non-volatile
    memory to the accounting server with appropriate modifications in
    termination cause, session length, and possibly other relevant,
    application specific information in
    the records. The client MUST not modify the Accounting-Record-Type
    or other basic information in the records, or try to reconstruct
    STOP_RECORDs.

Jari

---

From: Johan Johansson <[email-masked]>
Date: Thu, 28 Feb 2002 22:50:52 +0000

Jari Arkko wrote:

>    STOP_RECORDs

So the diameter node stores exactly those records that it has had time 
to receive and stores it complete with record type and the session id, 
accounting multi session id, sub session id and radius session id (the 
ones that apply anyway) and recovers properly only from faults in the 
diameter node but not from faults in the device/process generating the 
data? This would then by necessity be treated as a new session unless 
extra effort is applied?

j