RE: clarification on extensibility rules

["Harri Hakala (JO/LMF)" <harri.hakala@ericsson.com>]

Hi,

when the credit control application is used in the credit control
context, the approach one is most in line with what is defined in the 
DCCA draft. The Diameter CCA defines the framework for credit-control;
it provides generic credit-control mechanisms supporting multiple 
service applications, but it does not define AVPs that could be used
as input in the rating process. Because of this, the draft specifies
that new rating AVPs can be sent as non mandatory AVPs together with 
two other AVPs, which are used to specify the service in question.

If a rating input required for the rating process is incorrect, or
if the credit-control server does not support the requested service
context, then the credit control server shall return the CCA specific
error code, EC 5031, DIAMETER_RATING_FAILED.

The above extension mechanism is used, for instance, by 3GPP in its 
online charging interfaces between different network elements (credit
control clients) and online charging systems (credit control server).

When the CCA or other diameter applications are used in a slightly 
different context as defined in the diameter specifications, for instance,
when the diameter client requesting charging rules from the charging rule
server (different server than the CC server), then own application id 
may be favorable due to slightly different functionality. Separate 
application-id may also help to route (as a secondary key in a realm
based routing table) the diameter messages to the right server with
the realm. In these cases, either the alternative 3 or 4 may be practical,
if the intermediate diameter agents do dot misinterpret such standard 
diameter commands which have just vendor-specific application identifier
included or which have a vendor-specific application identifier placed 
it in Auth-Application-Id. 

regards........Harri

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: 15. huhtikuuta 2005 15:31
> To: AAA Doctors
> Subject: clarification on extensibility rules
> 
> 
> 
> Hello folks,
> 
> I have a question that relates to some of the ongoing work in 3GPP
> to use Diameter for some of their interfaces.
> 
> This is basically the re-use of a standard application, but with some
> additional attributes that are mandatory in the given context. I'd
> like to advice our people on what the right way to go about this is,
> but its not easy. Perhaps you can help. I'll use the credit control
> application as an example and provide a couple of potential ways
> to do what is needed, along with the implications for interoperability
> of our protocols:
> 
> 1. Define the additional information as an optional attribute, but
> take a "policy level" decision that when this information does not
> come, you reject access.
> + this has the least impact on the protocols, can use existing
>    applications as is
> - could be used to circumvent extensibility rules
> - what exact error code to return?
> 
> 2. Allocate a new vendor-specific application identifier.
> + This seems most in line with the intent of RFC 3588. It
>     says that adding mandatory AVPs requires a new application
>     identifier
> -   Here's where we get to the problem. Since we are using
>     a standard command, the syntax is of the form:
> 
>               { Auth-Application-Id }
> 
>     and not
> 
>                [ Acct-Application-Id ]
>                [ Vendor-Specific-Application-Id ]
> 
>     as in accounting application, for instance. As a result,
>     if the application identifier is vendor-specific this would
>     break the original command ABNF.
> 
> 3. Allocate a new vendor-specific application identifier,
>     and use Vendor-Specific-Application-Id in the ABNF
>     instead of Auth-Application-Id.
> + Seems reasonable
> - Does this change of the ABNF require a new command code?
>   The rules on how to add new command codes are not
>   crystal clear.
> - Are there issues in passing these through proxies?
> 
> 4. Allocate a new vendor-specific application identifier,
>     but place it in Auth-Application-Id in order to avoid
>     the problem above.
> + The syntactic changes are minor, as in alt #1.
> - Placing a vendor specific application identifier to this
>   AVP seems incorrect.
> 
> In short, there are a number of approaches all of which seem
> to suffer from at least some problems. I think alt #3 is the
> most "correct", but it appeals to me only if it doesn't imply
> command code allocation.
> 
> Overall, there are two meta-issues in this problem. The first
> one is that when people attempt to use Diameter in a new
> context, they are running into extensibility rules that, imho,
> force them to diverge more from the original applications
> that would really be necessary. It looks like the extensibility
> rules may, in some cases, be working in favor of divergence
> rather than against it as originally intended. If it were up to
> me, I'd recommend alt #1.
> 
> The second meta-issue is how could we better instruct the
> community on what the right approach is. Is there an interest
> in taking on "aaa doctor reviews" of other SDO documents?
> 
> --Jari
> 
>