Subject: Re: [Dime] Summary of 3588bis Issues Status

From: Anders Kristensen <[email-masked]>
Date: Thu, 17 Aug 2006 11:24:41 -0400

[Going through old email.]

I like this proposal a lot. It's simple and greatly clarifies things. 
IMO 3588 is pretty clear that the app id space is flat. It's a mystery 
why application IDs were ever tagged with vendor IDs but if the 
Vendor-Specific-Application-Id can be retired then good riddance (due to 
backwards compatibility it probably can't, though). If we could get rid 
of the Auth/Acct tagging of app IDs then in my view that would be a good 
thing too. For better or worse Diameter is being used for non-AAA 
purposes too now.

Thanks,
Anders

Jan Nordqvist wrote:
> Few topics has generated as many messages in this and other groups as 
> the subject regarding (or the confusion surrounding) the fact that there 
> is an AVP-based application id in the message in addition to the message 
> id in the Diameter header.
> 
> As far as I am concerned, the application-id serves three purposes:
> 
>  1. Combined with the Command-Code as a message type discriminator to
>     determine what dictionary and processing entry point to apply in
>     order to process the message.
>  2. Combined with the Destination-Realm to determine message routing.
>  3. As a special case in the CER/CEA as a means to advertise
>     application id support.
> 
> I just can't imagine what scenario would require more than one 
> application id in a message to serve the purpose of both case 1 and 2 
> above, but I may be wrong.
> Only in case 3, which is an exception, use of the application id AVPs is 
> necessary since they are overloaded to mean "support for" in contrast to 
> identifying the type of message. In this latter case the header 
> application id only serves as a discriminator to indicate "base".
> 
> For messages that are intended for a specific server, such as ASRs or 
> any other message that are tied to a specific session, the primary means 
> for reaching the correct destination is the Destination-Host AVP. The 
> application id may of course still be used to make coarse routing 
> decisions to reach a host that has connectivity to and knowledge about 
> the given host. Obviously it is the responsibility of the network 
> administrator to configure the network in this case in such a way that 
> messages aren't dropped, i.e. are being relayed or proxied to reach a 
> "knowledgeable" peer. This would also seem as a very likely way to set 
> up routing in practice, i.e. make course decisions far away from the 
> target and make more precise decisions as the message gets closer to its 
> destination.
> 
> If the header application id is always set to resolve cases 1 and 2 
> above, i.e. set to identify the application pertaining to the message, 
> the only remaining meaningful use for the AVP based application ids is 
> for CE[AR]s. For existing AVP rules that include application ids as 
> AVPs, the standard could simply state that if one of the Application-Id 
> AVPs appear in a message, it MUST be set to the same value as the header 
> application id and thereby relieve implementers from a lot of confusion. 
> For new definitions, AVP application ids may be defined as optional, or 
> simply handled by the "universal last resort" *AVP rule.
> 
> IMHO, a clean and simple rule that would make life much easier both for 
> implementers and standards writers that avoids complicated and/or hard 
> to grasp rules regarding when to use one or the other of the application 
> ids.
> 
> One obvious issue is that the AVP application id can carry 65 bits of 
> information; an optional 32 bits of vendor id and a binary selector 
> between Auth versus Acct. There seems to be some disagreement as to 
> whether the application id numbering space is flat or not, but if it 
> considered flat, which indeed a 32 bit number would be sufficient for, 
> the "optional" AVP information could be disregarded and the header carry 
> the authoritative source of information.  As an alternative, if the 
> vendor id and the Auth/Acct distinction is deemed necessary, the header 
> application id could be disregarded and the AVP be treated as the only 
> authoritative piece of information instead.
> 
> Just my five cents,
> Jan Nordqvist
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime