Subject: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements

From: Pat Calhoun <[email-masked]>
Date: Thu, 7 Jun 2001 13:59:34 -0700

All,

A few of us got together on the phone today to try to iron out some of the remaining
issues, and I will be sending out how we propose to close any remaining issues (well,
we haven't been through them all... yet).

In this particular issue, the problem is how to do accounting record correlation when
many accounting "subsessions" are needed. 3GPP2, btw, has a requirement for this, and
have addressed this in a largely proprietary nature. We would prefer to detail how
this should be done to ensure consistency across services.

So, we agreed that the protocol already had the necessary components, but the lack
of clarity was what caused this issue to be opened.

Here is my proposed text to be included in the base protocol:

11.6  Correlation of Accounting Records

   The Diameter protocol's Session-Id AVP, which is globally unique (see
   section 10.3), is used during the authorization phase to identify a
   particular session. Services that do not require any authorization
   still use the Session-Id AVP to identify sessions.

   However, there are certain applications that require multiple
   accounting sub-sessions. Such applications would send messages with a
   constant Session-Id AVP, but a different Accounting-Session-Id AVP.
   In these cases, correlation is performed using the Session-Id.

   Furthermore, there are certain applications where a user receives
   service from different access devices (e.g. Mobile IP), each with
   their own unique Session-Id. In such cases, the Accounting-Multi-
   Session-Id AVP is used for correlation. During authorization, a
   server that determines that a request is for an existing session,
   SHOULD include the Accounting-Multi-Session-Id AVP, which the access
   device MUST include in all subsequent accounting messages.

   The Accounting-Multi-Session-Id AVP MAY include the value of the
   original Session-Id. It's contents are implementation specific, but
   MUST be globally unique across other Accounting-Multi-Session-Id, and
   MUST NOT change during the life of a session.

Thanks,

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 7 Jun 2001 15:08:41 -0700

On Sat, Jun 09, 2001 at 12:59:53AM +0300, Jari Arkko wrote:
> Looks good!
> One editorial issue is that some of
> this text overlaps a little with issue #57
> proposed text. Perhaps you could fix that
> by trimming the text in #57 as follows.
> 
[great text deleted]

ok, thanks for the text.

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 9 Jun 2001 00:59:53 +0300

Looks good!

"A particular value of Accounting-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 extensions document MUST define which kind of 
sequences should be used for the particular application. "

and then move the text below to the end of your proposed
text for #5:

"A Diameter extension document MUST define 
the exact concept of a session that is being accounted, and MAY 
define the concept of a multi-session. For instance, the NASREQ 
DIAMETER extension treats a single PPP connection to a 
Network Access Server as one session, and a set of Multilink PPP 
sessions as one multi-session."

Jari