Subject: [AAA-WG]: Diameter, Vendor Specific Accounting Application: Acct-Applicatio n-Id and Vendor-Specific-Application-Id

From: Lollo Tönnesson (QPK) <[email-masked]>
Date: Tue, 12 Mar 2002 16:24:32 +0100

The usage of Acct-Application-Id and 
Vendor-Specific-Application-Id for vendor specific 
accounting application is unclear.

I'd like to specify a vendor specific accounting application
by using ACR and ACA commands in the Diameter Base Protocol
and add on some optional service specific AVPs.

How do you specify the application Id in the ACR and ACA commands if you
are using a vendor specific accounting application? Should
Acct-Application-Id and/or Vendor-Specific-Application-Id be used?

1) Alternative 1:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Acct-Application-Id }
                { Origin-Host }
                 .......
  Question: What Acct-Application-Id should be used?

2) Alternative 2:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Acct-Application-Id }
                { Vendor-Specific-Application-Id }
                { Origin-Host }
                 .......
  Question: What Acct-Application-Id should be used?
  
3) Alternative 3:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Vendor-Specific-Application-Id }
                { Origin-Host }
                 .......
  Question: Acct-Application-Id is defined as mandatory for ACR.
           Is it appropriate to replace the mandatory 
           Acct-Application-Id with Vendor-Specific-Application-Id.
           This is not explicitly stated anywhere in the draft (09).

According to 09 draft of the Diameter Base Protocol:

* 6.10 Vendor-Specific-Application-Id

 AVP Format
      <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                        1* [ Vendor-Id ]
                                        0*1{ Auth-Application-Id }
                                        0*1{ Acct-Application-Id }
The vendor-Id is assigned by IANA. 
The Acct-Application-Id is defined by the vendor (private use).

*Is chapter 1.2.4, 2.4 applicable for vendor specific 
accounting applications, i.e. that an Acct-Application-Id
should be assigned by IANA?

* According to e.g. chapter 6.10 in the base protocol, the 
Vendor-Specific-Application-Id AVP should be used for advertise 
support for vendor specific diameter applications, but this AVP 
is not mentioned in the ACR or ACA, only for CER and CEA (table in 10.1, 10.2) 
The only application Id AVP required for ACR and ACA are the  
Acct-Application-Id.
??: Implication: During capability exchange (CER/CEA) you advertise 
support for the vendor specific application but the vendor 
specific application id is not included in the ACR/ACA commands.
Can this really be correct?
??: Should both the Acct-Application-Id and 
Vendor-Specific-Application-Id be part of CER/CEA?

* Acct-Application-Id AVP is mandatory in ACR and ACA (9.7.1, 9.7.2, 10.2)

Best regards Lollo

---

From: Tony Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 19:24:46 -0800

Submitter name: Tony Johansson (originally Lollo Tonnesson)
Submitter email address: [email-masked]
Date first submitted: March 13, 2002
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 9.7.1  Accounting-Request

Rationale/Explanation of issue

> * Acct-Application-Id AVP is mandatory in ACR and ACA (9.7.1, 9.7.2, 10.2)

Requested change:

Change the ABNF in 9.7.1  Accounting-Request

from:

                {...}
                { Acct-Application-Id }
                [...]

To:

                { ... }
                [ Acct-Application-Id ]
                [ ... ]

Since you may run only the base protocol, your own vendor specifc application and
no relay agent
support. In such a case your ACR messages will only include the
Vendor-Specific-Application-Id and no Acct-Application-Id.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Mar 2002 03:59:21 -0800 (PST)

I think that this issue is in part engendered by a lack of clarity in the
spec about when a new Acct-Application-Id is needed. 

Accounting is somewhat different from Authentication in that in many cases
the accounting server only writes the AVPs to disk, and therefore doesn't
need to understand them. As a result, one can send vendor-specific AVPs to
an accounting server without the server needing to "support" them. Thus,
section 1.2.4 was written to try to discourage gratuitous use of new
Acct-Application-Ids:

1.2.4  Creating New Accounting Applications

   There are services that only require the use of Diameter accounting.
   Since such services need to define the service specific AVPs that
   must be carried in the Accounting-Request/Answer messages, but do not
   need to define command codes, the rules on allocation of Accounting
   Application Identifiers is different from the ones defined in section
   2.3.3.

   When possible, a new Diameter accounting application SHOULD attempt
   to re-use any existing Diameter AVP, in order to reduce the
   possibility of having multiple AVPs that carry similar information.

   Every Diameter accounting application specification MUST have an IANA
   assigned Application Identifier (see section 2.4).

Note that section 1.2.4 says that rules on allocation of Accounting
Applications Identifiers [sic] is different, but doesn't say *how* it is
different. My understanding is that it is different because there is even
less reason to create a new Acct-Application-Id than a new Auth
Application. Thus, it would seem that adding Vendor-Specific AVPs may not
be a good enough reason to create a  new Acct-Application-Id. To resolve
this issue, I think we need to specify when new Accounting Applications
are created in more detail. 

Here is what section 2.3.3. says about Authentication Applications:

2.3.3  Creating New Auth Applications

   Should a new application require Diameter support, but it cannot fit
   within an existing application without requiring major changes to the
   specification, it may be desirable to create a new Diameter
   application. Major changes to an application include:
      - Requiring a whole different set of mandatory AVPs to a command
      - Requiring a command that has a different number of round trips
        to satisfy a request (e.g. application foo has a command that
        requires one round trip, but new application bar has a command
        that requires two round trips to complete).
      - The method used to authenticate the user is drastically
        different from any existing application, and the authentication
        information cannot be carried within the AVPs defined in the
        application.

   Note that the creation of a new application should be viewed as a
   last resort.

   New Diameter applications MUST define at least one Command Code, the
   expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY
   also define new AVPs. If the Diameter application has any accounting
   requirements, it MUST also specify the AVPs that are to be present in
   the Diameter Accounting messages (see section 9.3).

   When possible, a new Diameter application SHOULD attempt to re-use
   any existing Diameter AVP, in order to reduce the possibility of
   having multiple AVPs that carry similar information.

   Every Diameter application specification MUST have an IANA assigned
   Application Identifier (see section 2.4).