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

From: <[email-masked]>
Date: Thu, 8 Jul 2004 10:42:43 +0300

> 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.

> 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.  

I think RFC3588 does not specify any details regarding this kind
of internal implementation issues. In my opinion, Application-Id can
be used for multiplexing between software modules, just like any other
information in the messages.

I would also like to note that Application-Id can be used for
routing messages between peers. RFC3588 Section 2.7 Realm-Based Routing Table
states that "A route entry can have a different destination based on
the application identification AVP of the message."

BR,
Mikko

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Bernard Aboba
> Sent: 07 July, 2004 16:46
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage
> 
> 
> > 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...).
> 
> 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.
> 
> > Abort-Session-Request referring to a DCC session
> > would use application identifier 0.
> 
> Yes, because ASRs typically do not require additional 
> Mandatory AVPs, and
> therefore application identifier 0 is appropriate.
> 
> > 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.
> 
> Good point.
> 
> > 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.
> 
> Can you be more specific on what the problem is with this?
> 
> > Secondly, what if a Diameter peer does not want to use a base
> > 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
> > Diameter Accounting application while maintaining some other
> > 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
> > advertise support for an application that is not enabled.
> 
> I don't see anything in RFC 3588 that requires this.
> 
> > Regardless of which spec a command is defined, a command is only
> > 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".
> 
> > 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.
> 
> 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.
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jul 2004 06:58:26 -0700 (PDT)

> In my opinion, Application-Id can

The point is that Application-Id *alone* can't be used this way in all
cases. You need something like a combination of Application-Id and command to do the
multiplexing.

> routing messages between peers.

RFC 3588 is clear on that part, yes.