Subject: [AAA-WG]: Issue 360: Accounting standalone

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Sep 2002 18:02:46 -0700 (PDT)

Issue 360: Accounting standalone
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 1, 2, 7.1.3
Rationale/Explanation of issue:

The specification is contradictory on whether the Accounting
functionality of the Diameter base protocol can be used without
a corresponding application (MIP, NASREQ, etc.) For example,
the SIP accounting extension does not include an authentication
application definition, yet makes use of the Base protocol:

(see
http://www.ietf.org/internet-drafts/draft-narayanan-sipping-aaa-diameter-00.txt

Thus, the above specification seems to provide an example of how the
Diameter Accounting can be used by itself, and I would argue that this is to be
encouraged instead of create Yet Another Accounting Protocol (YAAP). The
proposed fix is to adjust the text in the following places to make this clear:

Page 14: Change definition of Diameter Server to the following:

"A Diameter Server is one that handles authentication, authorization and
accounting requests for a particular realm."

Section 2, page 17, first paragraph.

Change the first sentence of the first paragraph to:

"The base Diameter protocol may be used by itself for accounting
applications, but for use in authentication and authorization it is always
extended for a particular application."

Section 7.1.3, Page 81, DIAMETER_UNABLE_TO_DELIVER

Change "no host within the realm was available" to
"no host within the realm supporting the required application was
available"

Page 94, last paragraph

Delete the paragraph starting with "Note that the server side state
machine..."
This paragraph appears to be redundant with the first paragraph of page
93.

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Wed, 11 Sep 2002 15:40:04 +0200

If we want to say that the base Diameter protocol
may be used by itself for accounting applications,
then we need application Id for it.

I think that we are back to issue 196.

/ Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11. syyskuuta 2002 15:36
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue 360: Accounting standalone

Hi Harri,

> If the Accounting functionality of the Diameter base protocol
> can be used without a corresponding application, which would be
> good, what application id should a Diameter accounting client
> advertise during the capabilities exchange phase and when sending
> Accounting Request command ? Relay application Id ?

Should we allocate an application id for base accounting application?

John

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Thu, 12 Sep 2002 09:52:40 +0200

> If you buy this argument, then I think the indicated fix is:
> 
> a. Delete the "disk writing" text.
> 
> b. Change the "Extensions" text to indicate that a new  accounting
> application ID is needed only when there are new commands, OR when new
> AVPs defined in the application ABNF have the "M" bit set. If 
> there are no
> new commands, and new AVPs are non-mandatory, a new 
> application ID MUST
> NOT be used.
> 
> c. Add text to require that in accounting
> commands, the "M" bit is only set when a backend billing server MUST
> support the AVP in order to issue a correct bill. If the 
> backend billing
> server can ignore the AVP in computing the bill, then the  
> AVP MUST NOT
> have the "M" bit set within an accounting message, even if the "M" bit
> was set on that AVP within an authentication message.
> 
> d. Add a "standard accounting application" ID so that 
> accounting can be
> used by itself within Diameter.

I can but this. I think these are clear rules. 

/ Harri

---

From: <[email-masked]>
Date: Thu, 12 Sep 2002 11:04:19 +0300

Hi Harri,

> I can but this. I think these are clear rules. 

Sorry, I don't understand - do you mean:

 'I can buy this.' ?

John

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Thu, 12 Sep 2002 10:06:24 +0200

yes, sorry my typo.

/ harri

> Sent: 12. syyskuuta 2002 11:04
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 12 Sep 2002 11:09:44 +0300

Hi Bernard,

> There are two cases:
> 
> 1. If the application not only requires new AVPs to be present in the
> application (e.g. ABNF mandates them), but also requires the billing
> server to understand them (e.g. new AVPs have "M" bit set in accounting
> messages), then a new application ID is required, even if no new
> commands are used, only ACR/ACA.
> 
> 2. However, if the application requires new AVPs to be present (ABNF
> mandatory), but does not require the billing server to understand them
> (e.g. new AVPs don't have "M" bit set) and there are no new commands, then
> I'd argue that a new application ID is not required and MUST 
> NOT be used.
> 

I buy the argument.

> AVPs defined in the application ABNF have the "M" bit set. If there are no
> new commands, and new AVPs are non-mandatory, a new application ID MUST
> NOT be used.
> 
> support the AVP in order to issue a correct bill. If the backend billing
> server can ignore the AVP in computing the bill, then the AVP MUST NOT
> d. Add a "standard accounting application" ID so that accounting can be

I think this is the way to go.  Also, your original issue 360 text should
be added (added below for reference).

Anyone oppose the inclusion of this (above & below) text?

John

Page 94, last paragraph

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2002 05:04:38 -0700 (PDT)

I've added your suggestions to the text for #365.

On Thu, 12 Sep 2002, Stura Marco wrote:

> Hi,
>
> > > if the application requires new AVPs to be present (ABNF mandatory), but
> > > does not require the accounting server to understand them (e.g.new AVPs
> > > don't have "M" bit set), there are no new commands and there are no
> > > additional mechanisms defined (e.g. application state machine); a new
> > > application Id is not required and MUST NOT be used.
>
> Yes sounds like we agree. But it would be nice if you address all of these
> topics in the solution to this issue:
>
> 1- Mandatory AVP (e.g. M bit set)
> 2- New command
> 3- Application define additional mechanisms (e.g. application state machine)
>
> In the text you propose for the solution 1 and 2 are fine, it might be good
> to add some word also about 3.
> I would slightly modify you proposed text as follow:
>
> "1.2.4 Creating New Accounting Applications
>
> There are services that only require Diameter accounting.
> Such services need to define the AVPs carried in the ACR/ACA messages,
> but do not need to define new command codes. An implementation MAY add
> arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not set) to any
> command defined in an application, including vendor-specific
> AVPs, without needing to define a new accounting application. Please
> refer to section 11.1.1 for details.
>
> Application Identifiers are still required for Diameter capability
> exchange. Every accounting application MUST have either an IANA
> allocated Application Identifier, or a vendor specific Application
> Identifier.
>
> Since every Diameter implementation MUST support accounting, there
> is no need to advertise support for the Base accounting application
> within the CER/CEA, since this is implicit. This basic accounting
> support is sufficient to handle any application that uses the
> ACR/ACA commands defined in this document, as long as no new
> mandatory AVPs are added. A mandatory AVP is defined as one
> which has the "M" bit set when sent within an accounting command,
> regardless of whether it is required or optional within the ABNF for
> the accounting application.
>
> The creation of a new accounting application should be viewed as a
> last resort and MUST NOT be used unless a new command or additional
> mechanisms (e.g. application defined state machine)is defined within
> the application, or new mandatory AVPs are added to the ABNF.
>
> Within an accounting command, setting the "M" bit implies that
> the backend billing server or the accounting server it self MUST understand
> the AVP in order to compute
> a correct bill. If the AVP is not relevant to the billing process, when
> the AVP is included within an accounting command, it MUST NOT
> have the "M" bit set, even if the "M" bit is set when the same AVP is
> used within other Diameter commands (i.e. authentication/authorization
> commands).
>
> When possible, a new Diameter accounting application SHOULD attempt
> to reuse existing AVPs, in order to avoid defining multiple AVPs
> that carry similar information.
>
> Every Diameter accounting application specification MUST have an IANA
> assigned Application Identifier (see section 2.4) or a vendor specific
> Application Identifier.
>
> If the base accounting is used without any mandatory AVPs, new commands or
> additional mechanisms (e.g. application defined state machine), then the
> base protocol defined standard accounting application Id (section 2.4) must
> be used in ACR/ACA commands."
>
> Br
> Marco
>
>
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Thu, 12 Sep 2002 15:05:49 +0200

I but also this ;-)
Seriously, I think that in pre-paid case the accounting server 
should understand at least some of the AVPs ('control' and 'rating' AVPs)
in real time (i.e. "M" bit approach makes sense) and but in post-paid 
case the accounting server does not necessarily need to interpret these AVPs,
but even in post-paid case in some point you need an instance (e.g. billing system)
which knows the meaning of the AVPs, when it prepares the bill. 
But in the latter case it depends case by case (based on operators billing policy)
which AVPs are mandatory for bill.

/ Harri

> Jari Arkko wrote:
> 
> I think the most serious issue we have in the current specifications
> is what Marco brought up, i.e., that credit control -like applications
> are not compatible with the disk-writing approach. For this reason, it
> makes sense to make it the choice of the application specification
> whether or not fallback to "disk-writing" is allowed or not. This is
> essentially what deleting the disk-writing text and adding a base
> accounting application id accomplishes.
> 
> However, I'm pretty uncertain whether the "M" bit approach is the
> right one. Remember that billing is a process inherently guided by
> a policy. How would we as accounting-application-writers know whether
> a particular field from the SIP protocol is or is not going to be
> necessary for printing the bill? The answer is that we do not, and
> any information specified in the application standard *could* be
> used. Furthermore, the information about whether the AVPs are
> mandatory in a specific business case is something that only the
> home network knows. Therefore, it is hard for us to do anything
> else than to declare most accounting AVPs mandatory, and then
> have the client set the bits. According to the rules below
> this would lead to the situation where the basic accounting
> application is used by almost no one.
> 
> This is undesirable since in many cases the basic accounting
> application would in fact be sufficient as long as the
> record reached the right server. On the other hand, the combination
> of the home domain and the accounting application Id would
> act as a convenient routing mechanisms to get to the dial-in/wlan/3g
> department accounting servers.
> 
> In conclusion my main concern is that there'll be new applications
> and we'll be under the mercy of the negotiation process. And I
> need to get vendor X's server to get it to work with their client,
> if they chose to invent a new application ID -- even if *I* think
> I can handle it with my disk-writing basic accounting mechanism.
> 
> But perhaps there's an easy fix to this. We could require that
> all implementations of DIAMETER basic accounting must be 
> _configurable_
> to advertise a specific accounting application support.
> 
> This would mean that we lose the automatic fallback to disk-writing
> server (but for a good reason noted by Marco). Instead, we have
> a human-controlled process.
> 
> Jari
> 
> Bernard Aboba wrote:
> 
> > I'd argue that a new application ID is not required and 
> MUST NOT be used.
> >

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Sep 2002 04:33:35 -0700 (PDT)

I will modify the text for issue #365 to incorporate this.

On Fri, 13 Sep 2002, Stura Marco wrote:

> Hi,
>
> sounds good, but perhaps It is better to add some text according to the Jari
> Arkko suggestion.
>
> Jari wrote
>
> "
> all implementations of DIAMETER basic accounting must be _configurable_
> to advertise a specific accounting application support."
>
> Would you agree to update text for the issue #365 as follow?
>
> Br
> Marco