Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements

From: "Jari Arkko" <[email-masked]>
Date: Mon, 4 Jun 2001 00:28:26 +0300

David Spence wrote:

>     In thinking about this proposal since the interim meeting, I do have
>     one reservation.  In the primary use of the Acct-Multi-Session-ID AVP
>     to support PPP Multilink connections, there is an authentication/
>     authorization request for each single link as it comes up.  Thus,
>     each Accounting-Request message can be matched to an authentication/
>     authorization message by using the Session-ID AVP.  With the 3GPP2
>     standard, this will not be the case.  Successive accounting sessions
>     do not have corresponding auth/auth sessions.  Instead, one long
>     auth/auth session will match a series of shorter accounting sessions.

I'm not sure the difference is significant. We already agreed earlier to
allow accounting records for sessions that do not perform authentication/
authorization. So, for PPP multilink we get a bunch of correlated accounting
records, all of which happen to be also authenticated. For 3GPP2, we
also get a bunch of correlated accounting records, except that only one
of them is authenticated in the DIAMETER sense. 

Also, the mult-session-identity would potentially be useful also elsewhere.

Jari

---

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

> >     auth/auth session will match a series of shorter accounting sessions.

The same thing is true of 802.11. If the session is established on an AP
due to context transfer, then the AAA server will not have been contacted
for the purposes of authentication and authorization. Instead, the context
established originally is transferred to the new AP. The
Acct-Multi-Session-Id links the two sessions together.

---

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

> Also, the mult-session-identity would potentially be useful also elsewhere.

Well, the Mobile IP extension actually uses the Accounting-Session-Id in a
special way. When the authorization answer is sent back to the access device,
the message MAY include an Accounting-Session-Id, and if so, then all
accounting records for the particular session MUST use the session id returned.
 Of course, this is only for accounting, and would solve this particular
problem.

My solution: Propagate this information into the definition of the Accounting-
Session-Id in the base protocol.

PatC

---

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

> My solution: Propagate this information into the definition of the
> Accounting- Session-Id in the base protocol.

oops, Bernard is right, this *should* have been the Accounting-Multi-Session-Id
AVP, not the Accounting-Session-Id.

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 6 Jun 2001 00:50:38 +0300

> AVP, not the Accounting-Session-Id.

Good. If we have this, then there should be no major problem left.

By the way, in the proposed text that I sent to issue #57 
(http://www.diameter.org/issues.html#Issue%20#57, Accounting-
Record-Type and clarification I wrote the text as if we still had only
Accounting-Session-Id. That text needs to be modified to say how
both Ids should be treated. Note that there still remains a need to
correlate records from several nodes, even if within one node we
can solve the correlation through Accounting-Multi-Session-Id.)

Jari

---

From: David Spence <[email-masked]>
Date: Mon, 04 Jun 2001 18:14:17 -0400

I'm not sure I understand where you are going with this.  I thought Jari and
Bernard were arguing the the Session-ID should be different in each of the
accounting records to distinguish them from each other.  The
Acct-Multi-Session-ID AVP would tie them all together.

What I wanted was to allow the same Session-ID to appear in all the
accounting messages.  Some other mechanism could be used to indicate that
multiple accounting records are present for the same session.  My proposal
would be to create a new value for the Accounting-Record-Type AVP, call it
SUBSESSION_RECORD, to indicate that this record needs to be kept, but it is
not the final or STOP_RECORD for the session.

In either proposal, I don't see where the Acccounting-Session-Id would be
needed.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 15:13:00 -0700

> can solve the correlation through Accounting-Multi-Session-Id.)

The definition of the Accounting-Multi-Session-Id states:

"  The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type
   OctetString and SHOULD be encoded in UTF08 format [13], following the
   format specified in section 10.3. The Accounting-Multi-Session-Id AVP
   is used to link together multiple related accounting sessions, where
   each session would have a unique Accounting-Session-Id, but the same
   Acounting-Multi-Session-Id AVP. This AVP MAY be returned by the
   Diameter server in an authorization answer, and MUST be used in all
   accounting messages for the given session."

Is this sufficient?

PatC

---

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

> Acct-Multi-Session-ID AVP would tie them all together.

Yes.

> not the final or STOP_RECORD for the session.

Ah, now I see where you're going! But would that be sufficient? I can think
of situations where we want the subsessions to survive. Say, access from
base station #1 costs more than from #2... What about possibly interleaved
subsessions? Also, would we need SUBSESSION_RECORD_{START,
INTERIM,STOP}? In any case, wouldn't Acct-Multi-Session-Id and Acct-Session-Id
do the job?

Jari

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 16:21:00 -0700

> INTERIM,STOP}? In any case, wouldn't Acct-Multi-Session-Id and Acct-Session-Id

I support this! RADIUS Tunneling has some rather gross hacks, and introduces
new accounting message types (tunneling vs. sessions). Using subsessions could
be re-used for nasreq tunneling.

Jari, will you propose text, or should I just "go for it".

PatC