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

From: "Kobylarz, Thaddeus" <[email-masked]>
Date: Thu, 14 Jun 2001 14:08:41 -0400

Pat,
	I'm still trying to "catch-up" with my e-mail.  
	Correlation of charges is very important and I would like to have
the 3GPP SA5 folks think about the process you describe in the attached
before it becomes final.  I hope it's not too late to consider suggestions.
	My opinion is that the process is correct and have no comments.
Others may have different conclusions.
Thad

SA5 folks,
	Please examine the process, described below, in dealing with
correlation.  If you have comments, please reply on the SA5 reflector and I
will forward them to the AAA reflector.
	Again, time is of the essence.  Please reply ASAP. 
Thanks, Thad

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Thursday, June 07, 2001 5:00 PM
To: [email-masked]
Subject: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements

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