Subject: [AAA-WG]: Accounting issue submission

From: "Jari Arkko" <[email-masked]>
Date: Sun, 3 Jun 2001 21:50:47 +0300

Here's the accounting clarification issue in an issue-form.
Issue number to be assigned. Yolanda, Pat, please review
the proposed modification.

/Jari
------

Accounting-Record-Type and clarification 
Submitter name: Jari Arkko (originally Yolanda Garcia-Serrano)
Submitter email address: [email-masked] 
Date first submitted: 16-May-2001 
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00256.html
Document: Base 
Comment type: C 
Priority: 2 
Section: 12.5
Rationale/Explanation of issue: 

The current draft version seems to have unclarity with respect to the 
use of the same session identity in several records, and the use of
different Accounting-Record-Types over the same session. This needs
to be clarified.

Requested change: 

At the end of section 12.5, add the following text:

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. Note that sometimes such
sequence of records is related to a higher-level session, possibly
spanning several DIAMETER clients. The linking of such record
sequences together lies, however, outside DIAMETER and is
typically performed by postprocessing systems. It is the responsibility
of the particular extensions document to define a sufficient set
of AVPs so that this correlation can be done based on, for instance,
IP addresses. Likewise, the extensions document MUST also define
the exact concept of a session that is being accounted. For instance,
the NASREQ DIAMETER extension treats a single PPP connection
to a Network Access Server as one session.

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.
That is, it is not allowed to mix record types, such as sending
interim records followed by an event record. A particular
extensions document MUST define which kind of sequences
should be used for the particular application.

Resolution: tbd

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Jun 2001 07:30:56 -0700 (PDT)

Question about this recommended change. Will we now have *both* the
Acct-Multi-Session-Id and some other AVP? 

Also, AAA has traditionally supplied the Acct-Multi-Session-Id for the
explicit purpose of linking sessions together, so that this would *not* be
the responsibility of the back-end system (which can have a devil of a
time doing this without some help). IP addresses are generally not
sufficient since they are dynamically allocated, so I don't think this is
a good example to give. 

I do agree that the individual extension documents need to define what a
session is. For PPP, a summary accounting record is issued for each link
in use. Multiple links within the same session share an
Acct-Multi-Session-Id. Within 802.11, a summary accounting record is
issued for each client-AP session. Sessions created as a result of roaming
between APs have different Session-Ids, but are linked via the
Acct-Multi-Session-Id. 

Why can't one send Interim records, followed by a summary record? Isn't
this how RADIUS accounting works?

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 6 Jun 2001 01:10:04 +0300

> Acct-Multi-Session-Id and some other AVP? 

I believe consensus to the issue #5 results in a need to add the
Acct-Multi-Session-Id. We still need Acct-Session-Id as well to
identify the subsessions, don't we? Otherwise there'd be no
way to see for which subsession a particular Stop belongs to,
for instance.

> sufficient since they are dynamically allocated, so I don't think this is

I agree this isn't a good example, but there may be cases where
you can't implement context transfer such that the Acct-Multi-Session-Id
gets transferred between nodes.

One possible way forward on this issue would be to define Diameter
sessions as those being identified either by Acct-Multi-Session-Id
or Acct-Session-Id, and leave any further correlation issues outside
the scope of Diameter, i.e. to the back-end systems.

> this how RADIUS accounting works? 

We do allow Interims to be followed by a Stop. Just that a set of Start
and Interims may not be followed by an Event.

Below you'll find another trial at the proposed text:

/Jari
-------------new proposed text---------------

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. Note that sometimes such
sequence of records is related to a higher-level session, possibly
spanning several DIAMETER clients. The linking of such record
sequences together MUST be performed using the Accounting-Multi-
Session-Id AVP. The extensions 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.

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.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 15:20:19 -0700 (PDT)

> way to see for which subsession a particular Stop belongs to,

Accounting-Session-Id is already defined in the base protocol spec.

I've updated the issues web page with your new proposed text.

PatC