Subject: [AAA-WG]: Question about Diameter CCA Interoperability

From: [email-masked]
Date: Tue, 4 Nov 2003 11:55:53 +0000

Hi All,

I've been starting to study how CCA could be used.  I'm using a scenario 
where it would be used between a service node and a balance management 
node for a pre-paid mobile phone subscribers.  I've a question on 
inter-operability, which may be a niave one (in which case please accept 
my apologies).

As far as I can work out, much of the information for charging would have 
to be included in the Service-Parameter-Info AVP.  It therefore looks as 
though the content of this grouped AVP would have to be defined locally 
between the vendor of the two nodes and defined for that specific purpose. 

The issue comes into play if we imagine a situation where a second vendor 
is used to supply one of those nodes.  The second vendor could quite 
honestly claim to support Diameter CCA, but their definition of 
Service-Parameter-Info could be very different.  It seems to me that there 
would be no way that the new node could easily be made to inter-operate 
with the existing nodes.  Effectively, the implementations would be close 
to being proprietary.

What are the mechanisms within CCA to avoid this sort of problem?

Regards,

John.

******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message 
(or responsible for delivery of the message to such person), 
you may not copy or deliver this message to anyone. In such 
case, you should destroy this message and kindly notify the 
sender and [email-masked] by reply email.  Please
note that in such circumstances any review, dissemination, 
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited 
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages 
of this kind.  The opinions, conclusions and other information 
in this message are of the author and shall be understood as 
neither given nor endorsed by Vodafone Ireland Limited 
unless it is otherwise indicated by an authorised representative 
independent of this message.  Internet e-mail is
transmitted over the public internet over which Vodafone 
Ireland Limited has no control.  As such, there is no guarantee that 
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender 
(iii) this e-mail has not been intercepted by a third party 
(iv) the contents of this e-mail are unaltered from the time of
transmission.  The presence of this footnote indicates that this 
message (including its attachments) has been processed by an 
automated anti-virus system; however it is the responsibility of 
the recipient to ensure that the message (and attachments) 
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Number 326967 VAT Reg No. IE6346967G

******************************************************************************

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 4 Nov 2003 14:29:36 +0100

Hi John,

We have got some comments related to this problem and we have tried
to emphasize this issue in the CCA-01 version by adding own section
how to send rating input to credit control servers, section 4.1 Rating 
input.

Primarily applications should re-use existing AVPs defined by some Diameter 
application. New AVPs can be also defined if the existing AVPs can not be 
re-used. The Service-Parameter-Info AVP may be used to pass legacy 
rating information in its original encoded form. But to simplify 
interoperability, it is recommended to use of explicitly defined AVP's.

We also expect that there is some sort of agreement between the service 
providers of the credit control client and the credit control server. Part of
this agreement is also to agree the rating input with the providers according 
to the service documentation.

Regards.........Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: 4. marraskuuta 2003 13:56
To: [email-masked]
Subject: [AAA-WG]: Question about Diameter CCA Interoperability

Hi All, 

I've been starting to study how CCA could be used.  I'm using a scenario where it would be used between a service node and a balance management node for a pre-paid mobile phone subscribers.  I've a question on inter-operability, which may be a niave one (in which case please accept my apologies). 

As far as I can work out, much of the information for charging would have to be included in the Service-Parameter-Info AVP.  It therefore looks as though the content of this grouped AVP would have to be defined locally between the vendor of the two nodes and defined for that specific purpose.   

The issue comes into play if we imagine a situation where a second vendor is used to supply one of those nodes.  The second vendor could quite honestly claim to support Diameter CCA, but their definition of Service-Parameter-Info could be very different.  It seems to me that there would be no way that the new node could easily be made to inter-operate with the existing nodes.  Effectively, the implementations would be close to being proprietary. 

Regards, 

John.

---

From: [email-masked]
Date: Tue, 4 Nov 2003 15:24:16 +0000

Hi Harri,

Thank you for your response.  I had been working from draft 00 and have 
now got CCA-01.

I am afraid I have quite a few more questions resulting from this.  Please 
feel free to direct me towards the appropriate section of the draft if 
I've overlooked it.

I can certainly see the advantage of explicitly defined AVPs rather than 
Service-Parameter-Info, but I'm not sure I clearly understand all the 
implications of section 4.1.  Does this mean that in practice there will 
be other applications effectively sitting on top of CCA?  Will these 
applications be defined within the framework of the AAA-WG?  Or will they 
be vendor-specific?  I guess in this situation the application identifier 
that is advertised will be that of the 'other application' rather than 
that of CCA.  Would the other application have the option of adding new 
commands?

Have I also understood the concept correctly that a Command can use any 
AVPs defined within any Diameter application, or the base, not just those 
defined within the same application as the command?  Could AVPs be defined 
without an application?  If so, is there a 'home' for these AVPs - in 
other words, if we did defined new AVPs where would we document them?

I also notice in 4.1 that Mandatory AVPs can be ignored if considered 
irrelevant by the server.  Would a client have the option of missing out 
mandatory AVPs if it knew the server didn't need them?

Regards,

John.

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Wed, 5 Nov 2003 09:03:17 +0100

Hi John.

>Does this mean that in practice there will be other applications effectively 
>sitting on top of CCA?  Will these applications be defined within the framework
>of the AAA-WG?  Or will they be vendor-specific?  I guess in this situation the
>application identifier that is advertised will be that of the 'other application'
>rather than that of CCA.  Would the other application have the option of adding
>new commands?
The controlling AVPs and credit control mechanisms defined by CCA are generic enough
for different services, but very often the rating input varies from one service to
another. It is not reasonable to define these service specific rating input AVPs 
(or the contents of the SPI AVP) in the cca draft, but these AVPs should be defined 
in some other application or document.

You can run the cca together with some other diameter application (e.g. NASREQ, vendor specific)
or you can use it alone, but then you should use service specific rating input AVPs defined 
in somewhere else. If just rating AVPs are added to CCR command then you can use 
application identifier of cca. 

Diameter expandability is discussed in Diam Base, section 1.2 Approach to Extensibility. 
That section describes when creating new AVPs are enough or when you need to create a 
new diameter application.

>Have I also understood the concept correctly that a Command can use any AVPs defined
>within any Diameter application, or the base, not just those defined within the same
>application as the command? 
Yes, this is true.

>Could AVPs be defined without an application?  If so, is
>there a 'home' for these AVPs - in other words, if we did defined new AVPs where would
>we document them? 
Usually you define AVPs for the diameter application. If you need for instance rating input
AVPs for vendor specific service, then use cca application. If you have standard diameter 
application and you need a new AVP for it, then use that application. 

The cca draft recommends that rating input AVPs are documented in another Diameter 
application, standards written by other standardization bodies, or service specific 
documentation.  

>I also notice in 4.1 that Mandatory AVPs can be ignored if considered irrelevant by the
>server.  Would a client have the option of missing out mandatory AVPs if it knew the 
>server didn't need them? 
I think that it would be good to send always mandatory AVPs ('M'-bit set) to server and 
let it then ignore them, if needed.

Regards..........Harri 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 4. marraskuuta 2003 17:24
To: Harri Hakala (TU/LMF)
Cc: [email-masked]
Subject: RE: [AAA-WG]: Question about Diameter CCA Interoperability

Hi Harri, 

Thank you for your response.  I had been working from draft 00 and have now got CCA-01. 

I am afraid I have quite a few more questions resulting from this.  Please feel free to direct me towards the appropriate section of the draft if I've overlooked it. 

I can certainly see the advantage of explicitly defined AVPs rather than Service-Parameter-Info, but I'm not sure I clearly understand all the implications of section 4.1.  Does this mean that in practice there will be other applications effectively sitting on top of CCA?  Will these applications be defined within the framework of the AAA-WG?  Or will they be vendor-specific?  I guess in this situation the application identifier that is advertised will be that of the 'other application' rather than that of CCA.  Would the other application have the option of adding new commands? 

Have I also understood the concept correctly that a Command can use any AVPs defined within any Diameter application, or the base, not just those defined within the same application as the command?  Could AVPs be defined without an application?  If so, is there a 'home' for these AVPs - in other words, if we did defined new AVPs where would we document them? 

I also notice in 4.1 that Mandatory AVPs can be ignored if considered irrelevant by the server.  Would a client have the option of missing out mandatory AVPs if it knew the server didn't need them? 

Regards, 

John.