Subject: RE: [AAA-WG]: CCA: Rating Input

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 6 Oct 2003 15:51:53 +0200

Hi Jari,

> > I thought that there may be existing application servers, 
> which already support 
> > some other data format for accounting data, e.g. ASN.1. If 
> these servers 
> > do not use any other Diameter application, it may be 
> simpler to re-use 
> > existing data format (embedded in the Service Parameter 
> Info AVP) for 
> > credit control as well. By using SPI one can also avoid CCA 
> protocol 
> 
> Such an AVP might be useful, yes, maybe even more generally
> than in CCA.

OK. We will keep the SPI AVP.

> Well, you need *some* AVP to carry the information. I think you had
> SHOULD for using existing AVPs, which I think is fine. *AVP is right
> too. In addition, you may need the other info carrier AVP. But I'd
> be happier if we could say something about its contents, e.g. at least
> that it is always in ASN.1 BER form or something like that.

It is rather difficult to say something exact about its content, e.g. that
it is ASN.1 BER format, since the content is really service specific.

Would this be better:

There are two ways for providing rating input to the credit control server, either by
using AVPs or by including them in the Service-Parameter-Info AVP. The general principle
for sending rating parameters is that the service SHOULD re-use existing AVPs, if the 
service can use AVPs defined by some Diameter application. Alternatively new AVPs can be
defined if the existing AVPs can not be re-used. The Service-Parameter-Info AVP MAY be used 
for instance when service already supports other data format (e.g. ASN.1 BER) for accounting
data and it doesn't support any other Diameter application. Then existing accounting data
encoding can be used for credit control as well. In this case the rating input is embedded
in the Service-Parameter-Info AVP as defined in the section 5.18 Service-Parameter-Info AVP.

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

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 8 Oct 2003 14:03:28 -0700

Hi,

  I am a bit puzzled by the SPI proposal here.
 
  It seems to me that Diameter defines an extensible information model
and means of encoding data into Diameter messages via AVP's.

  Having an escape hatch called SPI which says that effectively opaque
information can be sent seems to me to be something to be strongly
discouraged.

  Transformation of some information payload, whether it be ASN.1
encoded, or XML or something else is best done prior to sending
that information in a Diameter payload.  I.e. make the information
explicit as well defined AVP's that have some specific semantic
meaning.

  To get to the SPI, the application is already going to have
to tear apart lots of other well defined AVP's in the process and
interpret them.

  Maintain the separation of concern, and the explicitness of
the Diameter Information model!

Regards,

  Jeff Meyer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Harri Hakala (TU/LMF)
> Sent: Monday, October 06, 2003 6:52 AM
> To: 'Jari Arkko'
> Cc: [email-masked]'
> Subject: RE: [AAA-WG]: CCA: Rating Input
> 
> 
> Hi Jari,
>

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 9 Oct 2003 08:44:38 +0200

Hi Jeff,

I understand your concern and your arguments are valid as well.

The idea behind the SPI was that it is an alternative  way to transfer
rating input to credit control system. The controlling AVPs defined by 
CCA are generic enough for different services, but very often the rating input
varies to service to service.

If new AVPs are needed for rating to new service, then CC server must be 
also updated every time when new AVPs are introduced. The credit control 
system can contain separate rating engine(s) and these rating AVPs are actually 
destined to them. The SPI can be used to carry rating parameters to
the server, which can then transparently pass its content to rating system.

Regards.......Harri

> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]]
> Sent: 9. lokakuuta 2003 0:03
> To: Harri Hakala (TU/LMF); 'Jari Arkko'
> Cc: [email-masked]'

---

From: <[email-masked]>
Date: Thu, 9 Oct 2003 09:56:12 +0300

Hi Harri,

The SPI can be used to carry rating parameters to
> the server, which can then transparently pass its content to 

The SPI currently have the M bit set. According to the base,
if the server receives an AVP with M bit set and it doen't
understand the AVP it must reject the request with appropriate
Result-Code in the answer.
According to your explanation it seems the SPI is transparent
to the server, should then have the M bit cleared?

Another question is, what happen if the backhand rating server
does not understand the content of this AVP? Would it notify
somehow the CC server that would then send and error answer
with Resul-Code DIAMETER_RATING_FAILED?

Br
Marco  

> From: ext Harri Hakala (TU/LMF) [mailto:[email-masked]]
> Sent: 09 October, 2003 09:45
> To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Jari Arkko'
> Cc: [email-masked]'

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 9 Oct 2003 09:11:04 +0200

Hi Marco,

> to the server, should then have the M bit cleared?
Yes.

> Would it notify
Right as well.

Regards.......Harri

> From: [email-masked] [mailto:[email-masked]]
> Sent: 9. lokakuuta 2003 9:56
> To: Harri Hakala (TU/LMF)
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 9 Oct 2003 07:58:31 -0700

Harri,

  Thanks for the response.  It seems like the idea is simply
pushing the problem someplace else.

  I.e. a CC server can be written to flexibly recognize a 
growing set of AVP's and operate on them intelligently.  I 
speak from experience here.

  Alternatively something behind the CC server may or may
not flexibly grow to accomodate some mystery content hidden
in a SPI.

  What defining characteristics distinguish between a SPI which
is valid and understood by a system from one which is not?
If two clients of the CC using different SPI information talk to the
same CC how are their SPI's distinguished?  How 'bout when the third
is added?

-- Jeff

> From: Harri Hakala (TU/LMF) [mailto:[email-masked]]
> Sent: Wednesday, October 08, 2003 11:45 PM

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 10 Oct 2003 08:51:06 +0200

Hi Jeff,

The purpose is not to move the problem one place to other.
The idea is to minimize updates in the existing systems.

There are existing application servers, which transfer
accounting data in some other format than AVP to a backend
rating server via Accounting Server. The contents of this
accounting data may be specified in standards written by other
standardization body. In this case it may be attractive try to
re-use existing data format & backend rating server logic
for credit control as well. 

It is also self-evident when a new service is introduced, one cannot
avoid the updates of rating engine or client, but the updates in
CC server can be avoided.  

What comes to distinguish SPIs between services, I think that it
will not be a realistic case that someone just adds a client in the
network without knowing anything about the server. There must be an 
agreement between the client and the server in order to know who shall 
handle the billing of which services, which chargeable services are 
available when roaming, what rating input shall be used for rating of
services etc.

We have also stated in CCA draft that the service specific rating input AVPs 
or the contents of the Service-Parameter-Info AVP are not within 
the scope of CCA document and SHOULD be defined in another 
Diameter application, standards written by other standardization 
bodies, or service specific documentation. 

Regards.....Harri

> Sent: 9. lokakuuta 2003 17:59
> To: Harri Hakala (TU/LMF); MEYER,JEFFREY D (HP-Cupertino,ex1); 'Jari
> Arkko'
> Cc: [email-masked]'

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 10 Oct 2003 11:07:25 -0400

Harri,

  One of the roles in the CC server is to effectively
route inbound requests to appropriate functions such as rating and
balance management.

  As you state:

| What comes to distinguish SPIs between services, I think that it
| will not be a realistic case that someone just adds a client in the
| network without knowing anything about the server. There must be an 
| agreement between the client and the server in order to know who shall 
| handle the billing of which services, which chargeable services are 
| available when roaming, what rating input shall be used for rating of
| services etc.

  I agree that some clients when added will require changes on the
backend system, but if some clients can be added without requiring
changes on the backend, this would make operational aspects simpler.

  What I hear you saying is that there would be some mapping 
activity in the CC server based on either other AVP's or other 
properties of the inbound request (address?) which would then direct 
the SPI (and other AVPs) to some system which can consume it.

  Presumably then whenever a new client using a new SPI type is
added, then the CC server needs to be reconfigured to identify
whatever special combination of properties help it guide the SPI
to its new destination.

  It seems to me that this approach introduces ambiguity.  I.e. the 
distinguishing AVP's and properties may incorrectly lead me to assume 
that a SPI is of type A when it is really of type B.

  If there is some concrete use case out there which might 
illuminate this that would help me better understand if there
really is no alternative.

  If it really is deemed a critical feature, I would recommend
addressing the downside of the use of SPI's (e.g. ambiguity,
inconsistent handling, additional burden on CC server to route,
etc.) in the draft itself.  I.e. discourage its use before it
becomes a lazy shortcut which impedes interoperability.

Regards,

  Jeff Meyer

> Sent: Thursday, October 09, 2003 11:51 PM
> To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'
> Cc: [email-masked]'; 'Jari Arkko'

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 13 Oct 2003 10:58:04 +0200

Hi Jeff,

> whatever special combination of properties help it guide the SPI

The SPI is just a container of rating input, which the server can
transparently pass to the rating system. I don't think that some extra 
mapping activity is needed.

> becomes a lazy shortcut which impedes interoperability.

It is not a critical feature, I just thought that it can be an alternative
way (in addition to *AVP) to send rating input. But if that cause major 
problem or violate the Diameter Information model, of course we can skip it.

Regards........Harri

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 13 Oct 2003 11:36:17 -0700

Harri,

  I don't see a problem with SPI in addition to AVP* as long as 
its use is discouraged in favor of adding AVP's.  SPI's don't violate
the information model, but due to their opaque nature, they limit
what one can explicitly determine from the Info Model.  I would
argue that more explicit is better.

  Perhaps the following wording:

   "The SPI enables legacy rating information to be passed in its
  original encoded form.  CC Application developers SHOULD restrict
  its use to situations where legacy applications are being ported
  to Diameter CC.  New applications SHOULD favor the use of explicitly
  defined AVP's, to simplify interoperability."

Regards,

  Jeff Meyer

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]]
Sent: Monday, October 13, 2003 1:58 AM
To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'
Cc: [email-masked]'
Subject: RE: [AAA-WG]: CCA: Rating Input

Hi Jeff,

Regards........Harri

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 14 Oct 2003 08:13:42 +0200

Hi Jeff,

>   defined AVP's, to simplify interoperability."

Thank you for your feedback.
Your proposal sounds good.

Regards.....Harri

> Sent: 13. lokakuuta 2003 21:36
> To: Harri Hakala (TU/LMF); MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: [email-masked]'

---

From: <[email-masked]>
Date: Mon, 20 Oct 2003 13:33:23 +0300

Hi all,

I have added Jeff's text to the AVP def.

thanks,
JOhn

> Sent: 14 October, 2003 09:14

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 20 Oct 2003 12:45:39 +0200

Hi John,

if I remember correctly the original proposal was to add a new section in the draft discussing how to handle rating input
http://www.merit.edu/mail.archives/aaa-wg/msg05106.html
Wouldn't this addition belong to this section as well?

BR,
Leena

> From: [email-masked] [mailto:[email-masked]]
> Sent: 20. lokakuuta 2003 13:33
> To: Harri Hakala (TU/LMF); [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Mon, 20 Oct 2003 13:58:40 +0300

You are correct, I have added it to the correct place.

> From: ext Leena Mattila (TU/LMF) [mailto:[email-masked]]
> Sent: 20 October, 2003 13:46
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; Harri Hakala (TU/LMF); [email-masked]
> if I remember correctly the original proposal was to add a 
> new section in the draft discussing how to handle rating input

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 21 Oct 2003 07:57:45 +0200

Hi,

It may be good to merge Jeff's text into the second paragraph in the Rating input
section, where is described the ways to send rating input to the credit control server.
How about following formulation:
"There are two ways for providing rating input to the credit control server, either by
using AVPs or by including them in the Service-Parameter-Info AVP. The general principle
for sending rating parameters is that the service SHOULD re-use existing AVPs, if the 
service can use AVPs defined by some Diameter application. Alternatively new AVPs can be
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 (e.g. ASN.1 BER). In that
case the rating input is embedded in the Service-Parameter-Info AVP as defined in the
section 5.18 Service-Parameter-Info AVP. New applications SHOULD favor the use of explicitly
defined AVP's, to simplify interoperability."

Regards........Harri

> Sent: 20. lokakuuta 2003 13:59
> To: Leena Mattila (TU/LMF)

---

From: <[email-masked]>
Date: Thu, 23 Oct 2003 03:40:30 +0300

Hi Harri,

Thanks for the text, I've updated the draft.

John

> ext Harri Hakala (TU/LMF)
> Sent: 21 October, 2003 08:58
> To: Loughney John (NRC/Helsinki); Leena Mattila (TU/LMF);
> [email-masked]
> Cc: [email-masked]
> case the rating input is embedded in the 
> Service-Parameter-Info AVP as defined in the