Subject: [AAA-WG]: Accouting AVP issue...

From: Tony Johansson <[email-masked]>
Date: Tue, 19 Feb 2002 11:27:29 -0800

All,

In my efforts to update the Diameter MIPv4 application I have stumble on
the Accounting AVPs defined and realized that exactly the same AVPs are
defined also in the NASREQ application, see below.

Unless I have misunderstood something, I would suggest that we move
these AVPs to the Base, since they are used by both NASREQ and MIP.

Regards,

/Tony

In MIP:

"7.1  Accounting-Input-Extended-Octets AVP

   The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
   Unsigned64, and contains the number of octets in IP packets received
   from the user.

7.2  Accounting-Output-Extended-Octets AVP

   The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
   Unsigned64, and contains the number of octets in IP packets sent to
   the user.

7.3  Accounting-Session-Time AVP

   The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
   and indicates the length of the current session in seconds.

7.4  Accounting-Input-Extended-Packets AVP

   The Accounting-Input-Extended-Packets (AVP Code 365) is of type
   Unsigned64, and contains the number of IP packets received from the
   user.

7.5  Accounting-Output-Extended-Packets AVP

   The Accounting-Output-Extended-Packets (AVP Code 366) is of type
   Unsigned64, and contains the number of IP packets sent to the user."

In NASREQ:

8.1  Accounting-Input-Extended-Octets AVP

   The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
   Unsigned64, and contains the number of octets in IP packets received
   by the user.

8.2  Accounting-Output-Extended-Octets AVP

   The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
   Unsigned64, and contains the number of octets in IP packets sent to
   the user.

8.3  Accounting-Session-Time AVP

   The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
   and indicates the length of the current session in seconds.

8.4  Accounting-Input-Extended-Packets AVP

   The Accounting-Input-Extended-Packets (AVP Code 365) is of type
   Unsigned64, and contains the number of IP packets received by the
   user.

8.5  Accounting-Output-Extended-Packets AVP

   The Accounting-Output-Extended-Packets (AVP Code 366) is of type
   Unsigned64, and contains the number of IP packets sent to the user.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 20 Feb 2002 10:06:38 +0100

sounds good to me,
btw. why Extended, can't it just be Accounting-Output-Octets...

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Tony Johansson
>Sent: den 19 februari 2002 20:27
>To: [email-masked]
>Subject: [AAA-WG]: Accouting AVP issue...
>
>
>All,
>

---

From: Johan Johansson <[email-masked]>
Date: Wed, 20 Feb 2002 16:00:15 +0100

>these AVPs to the Base, since they are used by both NASREQ and MIP.
I don't have any objections either, but I think the perspective could be 
a bit broader. Considering that special provisions are made to ensure 
that the lifetime of the protocol stretches beyond 2030-something my 
reasoning is that it seems likely that most accounting application will 
count both bytes and packets and measure the duration of the session.

j

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 21 Feb 2002 11:55:17 +0200

> sounds good to me,

Yes. This should be sufficient, and we can make
the AVPs optional in the base. As Base 2.3.3 states,
Diameter extensions MUST also specify the AVPs
that are to be present in the Diameter Accounting messages.
This means that individual apps can be pick and choose the
AVPs they need.

> btw. why Extended, can't it just be Accounting-Output-Octets...

Desire to avoid a conflict with a similarly (but not exactly) named
RADIUS attribute that has different contents? Acct-Output-Octets,
32 bits.

Jari

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 21 Feb 2002 08:30:56 -0500

Hi Frederick

> Fredrik Johansson
> Sent: Wednesday, February 20, 2002 4:07 AM
> To: Tony Johansson; [email-masked]
> Subject: RE: [AAA-WG]: Accouting AVP issue...
> 
> 
> sounds good to me,

I had something to do with this.  See issue#182.

Basically, a while back these attributes had numbers in the
RADIUS attribute space, they were the same as RADIUS attributes
Acct-Input-Octets et al, but had 64-bit values rather than 32-bit
value.

I asked that these AVPs be assigned Diameter AVP codes, and given
names different from the RADIUS dictionary names for the corresponding
attributes.  I tossed out "extended" as an indication that their
precision was greater.

However, the RADIUS attributes are named "Acct-...", while the corresponding
Diameter ones are named "Accounting-...".

Since the Diameter ones have a different name, I don't have any complaints
if the "-Extended" is removed from the name, as it certainly isn't obvious
what "extended" means.

Bob K.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 21 Feb 2002 14:47:59 +0100

Hi Bob,

It was just for curiosity that I asked. I have no problem with them beeing
called somehting Extended

/Fredrik

>From: Bob Kopacz [mailto:[email-masked]]
>Sent: den 21 februari 2002 14:31
>To: Fredrik Johansson; Tony Johansson; [email-masked]