Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage

From: <[email-masked]>
Date: Wed, 7 Jul 2004 14:20:14 +0300

Hi Chris,

This brings us back to the topic what an "application"
actually is. It could mean e.g. a software module in
a Diameter implementation, or a (set of) specifications 
that document how Diameter is extended for some particular 
purpose (such as SIP or Mobile IPv4).

My reading of RFC3588 supports the latter interpretation
(but I guess there is some room for disagreement and 
other interpretations as well...).

With this interpretation, it does not make sense to say 
that you send a message _to_ an application; you send 
a message that is defined in some application. So an 
Abort-Session-Request referring to a DCC session
would use application identifier 0. 

Of course, there might be a DCC-specific software module
that actually handles the message, but I think we should 
use some other word than "application" for that.

Best regards,
Pasi

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: Tuesday, July 06, 2004 5:56 PM
To: 'Bernard Aboba'; [email-masked]
Cc: Eronen Pasi (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage

Hi Bernard, All, 

I still have a problem with the use of an application-id of a
different application in a command.

Firstly, there is section 3 of RFC 3588. It states that the
application-id in the header of any command MUST be the same as the
application id in any relevant AVPs.

Secondly, what if a Diameter peer does not want to use a base
application but only wants to use some other application. It wants to
advertise support for application X but does not want to be used for a
base application (regardless of it's ability to support the base
applications). For example, an operator may want to disable a node's
Diameter Accounting application while maintaining some other
application(s). The Diameter protocol should not force the node to
advertise support for an application that is not enabled.

Regardless of which spec a command is defined, a command is only
relevant to the application to which the command is destined. E.g. if
a management node wants to Abort a DCCA session on the DCCA client, it
only makes sense to send the ASR to the DCC client application - since
it is the DCC client application which is handling the session.

Cheers, 
Chris 

Tel:    +1 613 763 8031 
ESN:    393 8031

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jul 2004 06:45:47 -0700 (PDT)

> other interpretations as well...).

I agree with Pasi that RFC 3588 supports the interpretation of
"Application" as a set of specifications for extending Diameter for some
particular purpose.

In particular, this implies that the Diameter Application-Id cannot be
used for multiplexing between software modules, as can other header
fields, such as the TCP/UDP port number, EAP Type, etc.

> would use application identifier 0.

Yes, because ASRs typically do not require additional Mandatory AVPs, and
therefore application identifier 0 is appropriate.

> use some other word than "application" for that.

Good point.

> application id in any relevant AVPs.

Can you be more specific on what the problem is with this?

> application but only wants to use some other application.

If the "base application" is part of the specification, why it would it
want to use something else?

> For example, an operator may want to disable a node's
> application(s).

Assuming that "other application" does not require advertising Diameter
Base Common Messages (app-id 0) there is no problem with this.

> The Diameter protocol should not force the node to

I don't see anything in RFC 3588 that requires this.

> relevant to the application to which the command is destined.

Commands are not destined to an application.  They are part of an
application as defined by the application's specification.  As Pasi noted,
I think the term "application" is used differently in RFC 3588 than it is
normally used in conversation, as equivalent to "software module".

> it is the DCC client application which is handling the session.

I think you are presuming that the Application-ID is used for multiplexing
between software modules resident on Diameter peers, somewhat like TCP/UDP
port numbers or EAP Types.  I don't think that the Diameter Application-Id
can actually be used this way, due to its definition.  Perhaps that is the
root of the issue we are discussing.