Subject: [Dime] Acct-Application-Id value for NASREQ

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 21 Dec 2006 05:38:48 -0800

Just noticed that RFC 4005 doesn't appear to actually specify the value
of Acct-Application-Id for NASREQ accounting messages; I suspect that
what is intended is that the value be '3' for Diameter base accounting.
This seems to me to be problematic for a couple of reasons
*	it makes it difficult to determine what application actually
generated the accounting record (assuming that two or more applications
use unmodified base accounting on the same server)
*	It seems to make it impossible to separate accounting servers by
application (again assuming that two or more applications use base
accounting w/o modification) because all those servers would advertise
the same accounting application.

It does seem possible to separate generic accounting servers from others
by advertising just base accounting and no other applications, but that
doesn't seem quite good enough.  Comments?
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 21 Dec 2006 17:41:39 -0500

Glen,

Based on my understanding of the "Which App-Id to use in the message header
for base protocol messages" discussion in the last IETF, I would say that to
use the application identifier for NASREQ, i.e. "1", for all messages
exchanged for a NASREQ session makes sense.

I guess there was already consensus to follow that approach for base
protocol messages like STR, ASR. IMHO, extending that strategy to other
messages could be useful to guarantee successful routing of these messages
in all types of configurations and also to prevent confusions you listed.

BTW, if one reads RFC4005 literally, one can interpret it in a way where use
of app_id=0 is indicated for ACR and ACA as well based on the following
passage:
1.3 Advertising Application Support
....
All other messages are defined by [BASE] and
   use the Base application id value.

ACR/ACA belongs to other messages and base application id value is 0.
Nonetheless, I guess the real intention was to use App-Id=3 for ACR/ACA like
you stated.

   Thanks,
   Tolga

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]]
Sent: Thursday, December 21, 2006 8:39 AM
To: [email-masked]
Cc: Glen Zorn (gwz)
Subject: [Dime] Acct-Application-Id value for NASREQ

Just noticed that RFC 4005 doesn't appear to actually specify the value of
Acct-Application-Id for NASREQ accounting messages; I suspect that what is
intended is that the value be '3' for Diameter base accounting.  This seems
to me to be problematic for a couple of reasons
it makes it difficult to determine what application actually generated the
accounting record (assuming that two or more applications use unmodified
base accounting on the same server)
It seems to make it impossible to separate accounting servers by application
(again assuming that two or more applications use base accounting w/o
modification) because all those servers would advertise the same accounting
application.

It does seem possible to separate generic accounting servers from others by
advertising just base accounting and no other applications, but that doesn't
seem quite good enough.  Comments?

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 21 Dec 2006 18:18:04 -0500

Am I right in thinking that you always use the base application Id "0" 
for CER/CEA? I'm thinking that before these messages are exchanged there 
is no basis for routing on application.

---

From: Preeti Shandilya <[email-masked]>
Date: Fri, 22 Dec 2006 14:21:48 +0530

Hi !

Can someone tell me the AVP code for 3GPP-charging Id AVP. Also 
specification number in which it is mentioned

Regards
Preeti.

***********************  Aricent-Unclassified   ***********************

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 22 Dec 2006 09:08:18 -0500

Yes, CER/CEA is not exchanged for a particular application session and is
also hop-to-hop, i.e. does not need to be routed.

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Thursday, December 21, 2006 6:18 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Dime] Acct-Application-Id value for NASREQ
>
>

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 22 Dec 2006 12:08:05 -0500

Hi,

There maybe several points that needs clarification here. My historical 
understanding is that there is a relationship between auth-app-id and 
acct-app-id where the acct-app-id represents the accounting application 
that the auth application (auth-app-id) is using. So if an application 
supports accounting it would include an acct-app-id specifying what 
accounting application it uses and that id would be different from the 
app-id in the message header.

The proposals in Sec 2.12 of the errata draft somewhat attempted to 
clarify such app-id assignments (auth-id and acct-id avps) without 
considering this relationship. During the last IETF, there was a 
consensus that at least for Sec 2.12, we should just explain this 
relationship even though most existing applications do not use it. This 
does not really do any harm, i.e. routing problems, since that will 
still be based on the app id of the header. Note that this should not be 
confused with Sec 2.8 of the errata which deals with session level 
messages and their app-id assignments. And the proposal on that issue 
states the use of app id of the application for the noted session level 
messages.

regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 22 Dec 2006 16:01:13 -0500

Hi Victor,

My understanding is that RFC3588 does not leave much room for interpretation
in terms of the relationship between Application-Id in the message header
and the AVPs which are carrying application-id information (based on
definition of Application-ID in 3.Diameter Header in RFC3588). Like you
mentioned, there is currently nothing changing this behavior in the errata
draft either. It is of course possible to do so. It could be useful to
discuss advantages/disadvantages based on a proposed text regarding this
issue.

Actually after thinking a bit more about the problem Glen mentioned:
a) What I suggested won't work unless the authorization and accounting are
done on the same node/application instance, because the message header would
contain app-id of NASREQ causing the requests to be routed to the NASREQ
application. OTOH, I am not sure whether this is already the intent. I don't
know whether it is feasible to have a generic accounting application, which
can handle accounting for different purposes. Each application will add
service-specific AVPs to ACR for accounting purposes, the accounting
application needs to know how to make use of the data present in those AVPs,
which IMO would make a generic accounting server hard to implement.

b) If different applications are used for authorization and accounting,
indicating that the accounting is to be done for NASREQ could be useful.
Using Acct-App-Id for this purpose could make sense. If the same application
is used, I guess there is no point to use Acct-App-Id, because all messages
for the session will go to the same application anyhow.

    Thanks,
    Tolga

> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Friday, December 22, 2006 12:08 PM
> To: Tolga Asveren
> Cc: [email-masked]