Subject: [AAA-WG]: Mobile-IP accounting -- 3 thoughts

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

Hi Tony,

Here's a few Mobile-IP accounting thoughts.  I don't feel strongly
enough about them to submit as issues, but I will do so if anyone
thinks they are "issue-worthy".

1. The MIP-Feature-Vector is disallowed in AMA and HAA answer
messages.

Maybe the MIP-Feature-Vector should be returned in answer messages,
for a couple of reasons:

(a) The MIP-Feature-Vector is required in Mobile IP accounting
messages.  However the value which the FA originates in his AMR may
be modified by the AAAF, so the HA sees a different value.  Then
accounting messages sent by the FA and HA for the same session will
reflect different values for the MIP-Feature-Vector.

(b) Perhaps in the future, more bits may be added to the
MIP-Feature-Vector so that the AAAH or HA can use the
MIP-Feature-Vector to pass information.  Or maybe a new bit is set by
the AAAF that the FA needs to know about.  If so, then returning the
MIP-Feature-Vector in answer messages makes sure this information is
conveyed to all parties.

2. Both the NASREQ draft and the Mobile-IP draft require,
in their AVP occurrence rules, that the following AVPs be
present in an Accounting Request message:

   Accounting-Input-Extended-Octets
   Accounting-Input-Extended-Packets
   Accounting-Output-Extended-Octets
   Accounting-Output-Extended-Packets
   Accounting-Session-Time (= duration, in seconds)

In the case of an Accounting-Start, these values are all zero.
Are these AVP supposed to be required (with zero values) in this case,
or is this just an oversight when putting together the occurrence
rules?

3. The only AVP that conveys time information is the
Accounting-Session-Time, which indicates the session's duration, in
seconds.  So the server timestamps a received accounting message with
the server's notion of current time.  When processing accounting
messages, the session start time would be calculated by subtracting
the duration from the time the message was received.  This means the
session's calculated start time can vary message-to-message for the
same session.  This also means that accounting messages convey no
notion of the access device's time.  Should originators of accounting
messages convey a session start time and a current-time in some new
AVPs?

Bob K.

---

From: Johan Johansson <[email-masked]>
Date: Thu, 21 Feb 2002 15:34:48 +0000

>messages convey a session start time and a current-time in some new
We've been wondering about the same thing. One possible explanation why 
there is no way for the access device's time to be carried could be that 
the requirement for Diameter is real-time accounting and batch 
accounting is explicitly unsupported, and so there *should* be no 
significant differences, but I'm just guessing here. I think it would be 
nice but not essential to be able to pass the time to the server.

j

---

From: Johan Johansson <[email-masked]>
Date: Thu, 21 Feb 2002 16:34:43 +0000

Johan Johansson wrote:

> We've been wondering about the same thing. One possible explanation 
> why there is no way for the access device's time to be carried could 
> be that the requirement for Diameter is real-time accounting and batch 
> significant differences, but I'm just guessing here. I think it would 
> be nice but not essential to be able to pass the time to the server. 

A clarification: the timestamp would be useful in the case mentioned in 
the base draft (9.4):

     Upon a reboot,
     the client MUST starting sending the records in the non-volatile
     memory to the accounting server with appropriate modifications in
     termination cause, session length, and other relevant information in
     the records.

j

---

From: Tony Johansson <[email-masked]>
Date: Thu, 21 Feb 2002 13:44:03 -0800

Hello Bob,

Please, find comments embedded.

BR,

/Tony

> MIP-Feature-Vector to pass information.

> Or maybe a new bit is set by

To echo back the MIP-Feature-Vector in the AMA sound reasonable, so that
we can grantee that the FA and the HA uses the same values. For HAA I'm
not so sure. The main purpose of the MIP-Feature-Vector is to support the
AAAH in how to authorize the MN (HA assignment, etc.). Why would we need
to pass info from the HA to the AAAH? I may be wrong here but I don't see
why we should allow the MIP-Feature-Vector in the HAA unless we see a good
reason.

Others, comments?

> or is this just an oversight when putting together the occurrence

Good question, but I believe that they should be required. True, they are
all
zero, but instead of making exception the first time I would think it is
better to always send them and not only in all interims.

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 21 Feb 2002 17:38:36 -0500

Hi Tony,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tony Johansson
> Sent: Thursday, February 21, 2002 4:44 PM
> To: Bob Kopacz
> Cc: aaa-wg
> Subject: [AAA-WG]: Re: Mobile-IP accounting -- 3 thoughts
>
> Hello Bob,
>

That's fine.  This was just an 11th hour thought I was spewing out.  The
reason I suggested allowing the MIP-Feature-Vector in the HAA was that
my notion of the MIP-Feature-Vector was that it was a general purpose
flagword, so it could just as well be used by the HA to convey something
back to the AAAH (or FA).  But if the MIP-Feature-Vector is more for the purpose
of informing the AAAH about how to authorize the MN, then it probably
doesn't belong in the HAA, unless the HA has something of this nature
to feed back to the AAAH that might affect the AAAH's thinking.

> better to always send them and not only in all interims.

That's fine with me.  Just a question.

Bob K.