Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Wed, 9 Apr 2003 10:31:22 +0200

>   Any comments on the relationship of this application to Parlay
> section 12 and PayCircle?
> 
>   http://www.parlay.org/specs/3.2/es_20191512Charging.zip
> 
>   http://www.paycircle.org
> 
>   It seems that all of these are addressing the same basic issue of
> authorization of services with possible reservation of credit on
> the backend.

Isn't the applicability of OSA/Parlay charging API limited to services that
have been built using the OSA/Parlay framework?.
I foresee that there are services built using other mechanisms and are therefore
outside this framework. 

Our motivation is to define an IP-based accounting protocol to support credit
based accounting by using the AAA infrastructure. Because the Diameter base 
protocol provides several features, which are required from this kind of application
and because the Diameter and its accounting can be widely utilized we thought that
the AAA framework and Diameter is a good choice for this kind of IP-based accounting
protocol. 

I assume that there are several (and more and more are being developed) this kind of
applications focusing on online payments and credit reservations using quite similar
mechanisms, but having a bit different scope and framework. 

>   A harmonization of terminology, and ideally attribute names and
> data types would be worthwile.
> 
>   The IPDR.org (http://www.ipdr.org) group is looking at aspects of
> performing 
> this harmonization.  For some information on the separation 
> of information
> model, from encoding from transport see:
> 
>   http://www.circumference.org/circumference.ppt

A harmonization of terminology, etc, defined by different standardization bodies, 
would be helpful, although it might be quite challenging task.

It would be good if you can provide us with proposals for changed text in the draft.

Regards.........Harri

> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]]
> Sent: 9. huhtikuuta 2003 2:56
> To: Harri Hakala (LMF); [email-masked]
> Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt
> 
> 
> Harri,
> 
>   Any comments on the relationship of this application to Parlay
> section 12 and PayCircle?
> 
>   http://www.parlay.org/specs/3.2/es_20191512Charging.zip
> 
>   http://www.paycircle.org
> 
>   It seems that all of these are addressing the same basic issue of
> authorization of services with possible reservation of credit on
> the backend.
> 
>   A harmonization of terminology, and ideally attribute names and
> data types would be worthwile.
> 
>   The IPDR.org (http://www.ipdr.org) group is looking at aspects of
> performing 
> this harmonization.  For some information on the separation 
> of information
> model, from encoding from transport see:
> 
>   http://www.circumference.org/circumference.ppt
> 
> 
> Regards,
> 
>   Jeff Meyer
>   HP
>   http://www.hp.com/usage
> 
> 
> 
> > -----Original Message-----
> > From: Harri Hakala (LMF) [mailto:[email-masked]]
> > Sent: Friday, February 28, 2003 1:55 AM
> > To: [email-masked]
> > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt
> > 
> > 
> > Hi All,
> > 
> > We have submitted a new version of the Diameter credit control draft
> > to the IETF archive.
> > 
> > Until it shows up in the archive, it can be found:
> > http://standards.ericsson.net/harri/draft-hakala-diameter-cred
> it-control-06.txt
> 
> Here is a list of updates compared to draft -05:
> 1. A server or client is not required to implement all 
> functionality in 
> the CCA. The optionality has been clarified in the draft, the 
> modified 
> AVPs are the following:
> 
> 1a. Unknown/unsupported value responded with error:
>    - Subscription-Id-Type
> 
> 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table
>    - Accounting-Correlation-Id
>    - Abnormal-Termination-Reason
>    - Cost-Information
> 
> 2. New Result-Code value 'DIAMETER_RATING_FAILED'.
> 
> We would appreciate if you can read it and provide your comments.
> 
> Regards.......Harri
>

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 10 Apr 2003 10:18:52 -0700

Hi,

  I would draw a key distinction between prepay and postpay
scenarios.  I view postpay scenarios as needing only "accounting"
operations.  However, prepay scenarios, require some entity
to authorize the use of the service based not just on user
privileges, but also on whether they have sufficient funds.

  This implies that the authorization path now will likely
touch not just some relatively static LDAP store of users
and privileges, but also touch some "balance manager".

  I've tried to draw the distinction in a couple of sequence
diagrams available at:

  I would say it is an open question for an application 
developer as to how and when they distinguish between pre and
postpay users, assuming the service element will have a mix
of both.

  Another open question is whether there is a class of application
developers which would prefer to use an XML/WebServices style
prepay application vs. a binary protocol such as Diameter.
PayCircle is in the process of defining a similar XML/WebService
model for applications to provide credit control.

Regards,

  Jeff Meyer

> Sent: Thursday, April 10, 2003 3:09 AM
> To: [email-masked]'; 'Avi Lior'
> Hi Avi,
> (I assume that your mail was pointed to the aaa-mailing list.)
> 
> It is associated with accounting because of rating and billing. 
> The requested service must be rated before granting any quotas
> to the client. This is needed in order to decide whether the end
> user's account covers the requested service and to be able to grant
> right amount of quotas. So the rating itself that is needed for the
> decision is more related to accounting functionality than 
> authorization.
> And since the prepaid server will decrease the account during the 
> session in order to bill to user for the usage of the service the 
> billing as well is accounting related functionality.
> 
> In order to rate the service, rating input parameters are needed,
> that is the authorization commands would need to carry all the rating
> input parameters. The server also must return some control 
> parameters to
> the client (e.g. access device), so that the client can 
> monitor the service
> execution according to the instructions returned by the server.
> 
> Because the access device doesn't necessarily know if the user is 
> postpaid or prepaid, then all authentication and 
> authorization requests
> would need to carry rating input parameters, also in case of 
> postpaid users.
> Also there might be some existing service specific authentication and
> authorization protocols, which then need to be updated to 
> include these 
> parameters.
> 
> The client may need more quotas during the services and it may send 
> interim request to the server requesting more quotas and 
> reporting used
> quotas, i.e. session based credit control (or prepaid). The 
> Diameter base
> accounting supports session based accounting (start, interim 
> and stop) 
> and this suits very well for credit control as well. This is also one 
> reason why we want to associate the credit control 
> application with the 
> accounting, i.e. only few additional AVPs + new accounting 
> state machines
> (credit control session state machines) are needed. 
>  
> When session based credit control is used then credit control 
> server must
> maintain the session. If authorization commands would be used, then
> during initial authorization the authorization server should 
> establish the
> session towards credit control server in order to perform 'prepaid 
> authorization'. Then the re-authorization for additional 
> quotas during the
> session should flow through the AAA server to the prepaid 
> server, adding an 
> extra stateful hop (proxy, translator) in the signaling. When using 
> accounting commands the client can communicate directly with 
> the prepaid 
> server.
> 
> You are right the draft is not just for the 3GPP and of 
> course they also 
> authenticate and  authorize the subscriber for the network access and 
> for the services as well. For instance for multimedia services the
> Diameter Multimedia Application can be used.
> 
> Regards......Harri
> 
> > From: Avi Lior [mailto:[email-masked]]
> > Sent: 9. huhtikuuta 2003 22:18
> > To: Harri Hakala (LMF); [email-masked]'
> > Hi,
> > I have a question.  Why is Credit Application associated with 
> > accounting?
> > 
> > Seems to me that granting prepaid quotas is really an authorization
> > exercise. You are authorizing the subscriber to use a service 
> > for a period
> > of time.
> > 
> > This may seem like a petty philosophical point however it 
> > does have serious
> > technical ramification.  One of them that I have a huge 
> > concern over is a
> > timing issue.  In past implementations, for practical reasons 
> > we had to
> > solve these timing issues by combining Service Authorization 
> > and Prepaid
> > Authorization.
> > 
> > The home AAA during authentication discovers that the user 
> > requires prepaid
> > and then request prepaid authorization.  If all is 
> > successful, the prepaid
> > authorization(typically a quota) and the service 
> > authorization are sent to
> > the Access Device.
> > 
> > Making it an accounting activity decouples it from 
> > Authorization and creates
> > these problems.  My opinion is that accounting should be used 
> > for reporting
> > -- we still need real-time accounting.  But when we are 
> > applying controls
> > these should be related to Authentication and Authorization 
> commands.
> > 
> > I realize that in 3GPP this won't be an issue -- because you 
> > are not really
> > authenticating the subscriber.  But this is not just a 3GPP 
> > specification --
> > right?
> > 
> > Comments?
> > 
> > 
> > 
>

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Fri, 11 Apr 2003 08:35:53 +0200

> > So the rating itself that is needed for the
> Are we assuming that the accounting and authorizations servers are
> separate and that only the accounting server has access to the rating
> engine?

The accounting and authorization servers do not need to be separate,
but very often they are and only the accounting server or prepaid server
has access to the rating engine. 

> Is it possible for the rate to change unexpectedly, so that 
> the session
> time cannot be calculated at session initiation? In other words, is
> interim accounting required for this application?

Yes, the rate can change unexpectedly and interim request may be needed. 

> > input parameters.
> Since authorization and accounting commands contain the same 
> information,
> why wouldn't this be true for accounting commands, too?

It is true for accounting commands as well. But would it be better
to have just one prepaid (credit control) application to carry these parameters,
instead of updating all authentication and authorization protocols to carry 
service specific rating parameters. 
And because the rating is more related to accounting functionality than 
authorization would it then more logical to use accounting commands. 

> > would need to carry rating input parameters, also in case 
> of postpaid users.
> 
> Why wouldn't accounting requests also need those parameters?

Yes, the accounting request needs these parameter as well.
But are these parameters needed for *all* the authentication and 
authorization commands as well?. The result from authentication and 
authorization can be only postpaid (=accounting) and then only
accounting commands need carry these parameters.

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Fri, 11 Apr 2003 09:56:24 +0200

Hi,

You seem to forget the other aspect of prepaid: it's not only about
the credit check at the beginning of the service but also about *paying*
of the service, i.e. billing of the service in real-time. The accounting
is defined to be a process of collecting information for billing (among 
other things) done by a billing server. In credit control application we
collect the information for the same purpose (billing) but the process 
is done in real-time, not as a batch process in some back-end server.

I agree, the current credit control architecture might be too restricted
when it specifies that the dialogue can be only between the service node
and the credit control server. We could extend it to cover the (H)AAA
server as well so that the HAAA can use the credit control commands 
towards the prepaid server. The communication between the service node and
(H)AAA would be out of the scope of the draft.

Some further comments below.

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

N.B. You seem to have a problem with sending the messages to the aaa-wg-mailing
list since they don't appear in the mailing list. Have you subscribed to the
mailing list with the same id that you are using when posting the messages?

> > The requested service must be rated before granting any 
> > quotas to the client. This is needed in order to decide 
> > whether the end user's account covers the requested service 
> > and to be able to grant right amount of quotas. So the rating 
> > itself that is needed for the decision is more related to 
> > accounting functionality than authorization. And since the 
> > prepaid server will decrease the account during the 
> The above can happen during the Authentication and 
> Authorization phase.

Yes, it can happen during that *phase* but the rating and the billing
part is not part of Authentication and Authorization functionality.

> This is not a problem.  The HAAA can communicate the Service 
> requested right
> after it authenticated the user and determined what service 
> the user will
> get.  It can pass these to the Prepaid application.  All results
> (authorization parameters for both prepaid and service are 
> then passed back
> to the access device)

Wouldn't this mean that then all the authorization requests would have
to contain all the accounting parameters so that the HAAA can pass them
to the prepaid server for rating? Wouldn't you have to update all the
existing (and future) authentication & authorization applications to 
support online accounting (prepaid)?

> > authorization requests would need to carry rating input 
> > parameters, also in case of postpaid users. Also there might 
> > be some existing service specific authentication and 
> The HAAA knows what service the user wants.  The rating 
> engine will have the
> rating information anyway. So I don't see the problem here.

I would imagine that the rating input (at least most of it) would come
from the access device, not from HAAA. Therefore your authentication & 
authorizations commands should be able to carry those.

> Asking for more quotas can be achieved by authorization 
> requests.  After all
> it is a reauthorization operation.  You are authorizing the 
> user to continue
> to use the session. Infact, because in RADIUS accounting 
> messages are not
> acted on -- they are used for recording -- and in fact, they can be
> processed in batch by proxies (and hence are not real-time), 
> these operation
> really should be done using Access Request messages.

Might be true for RADIUS. I haven't seen any such statements for Diameter
accounting messages.

> Sent: 10. huhtikuuta 2003 18:42
> To: Harri Hakala (LMF); [email-masked]'; Avi Lior
> Hi Harri,
> I have comments inline as well as:
> 
> So first let me say this: lets not confuse the operation type 
> with the type
> of server that is performing the operation. Is the Prepaid server an
> accounting server -- lets say it is.  Should the messages be 
> accounting
> messages -- Not necessarily.  An accounting server should handle
> authorization type requests.  Just like a bank can handle an 
> authorization
> type requests.  But this is a minor issue.
> 
> The Credit Application in my opinion *must* be capable of 
> allowing me to
> authenticate a user and both authorize the user for a service 
> and authorize
> the user for prepaid in the *same* Access Request phase.
> 
> So an Access Device issues an Access Request advertizing the 
> its Prepaid
> Capabilities.  Since it doesn't know the apriori whether the user is a
> prepaid user or not it would issue the Prepaid Capabilities 
> in every Access
> Request.  The Home AAA will then Authenticate the user and 
> determine a)
> where the user is prepaid or not; and b) the type of service. 
>  If the user
> is prepaid it will then contact the Prepaid Server to further 
> authorize the
> subscriber.  If the prepaid authorization is successful, the 
> HAAA will then
> respond back to the access device with the service 
> authorization parameters
> and the prepaid authorization parameters.
> 
> Can this be done with the Diameter Credit Control application?
> 
> 
> > Sent: Thursday, April 10, 2003 6:09 AM
> > The requested service must be rated before granting any 
> > quotas to the client. This is needed in order to decide 
> > whether the end user's account covers the requested service 
> > and to be able to grant right amount of quotas. So the rating 
> > itself that is needed for the decision is more related to 
> > accounting functionality than authorization. And since the 
> > prepaid server will decrease the account during the 
> The above can happen during the Authentication and 
> Authorization phase.
>  
> > In order to rate the service, rating input parameters are 
> > needed, that is the authorization commands would need to 
> > carry all the rating input parameters. The server also must 
> > return some control parameters to the client (e.g. access 
> > device), so that the client can monitor the service execution 
> > according to the instructions returned by the server.
> 
> This is not a problem.  The HAAA can communicate the Service 
> requested right
> after it authenticated the user and determined what service 
> the user will
> get.  It can pass these to the Prepaid application.  All results
> (authorization parameters for both prepaid and service are 
> then passed back
> to the access device)
> 
> > authorization requests would need to carry rating input 
> > parameters, also in case of postpaid users. Also there might 
> > be some existing service specific authentication and 
> The HAAA knows what service the user wants.  The rating 
> engine will have the
> rating information anyway. So I don't see the problem here.
> 
> > 
> > reporting used quotas, i.e. session based credit control (or 
> > prepaid). The Diameter base accounting supports session based 
> > accounting (start, interim and stop) 
> > state machines (credit control session state machines) are needed. 
> 
> Asking for more quotas can be achieved by authorization 
> requests.  After all
> it is a reauthorization operation.  You are authorizing the 
> user to continue
> to use the session. Infact, because in RADIUS accounting 
> messages are not
> acted on -- they are used for recording -- and in fact, they can be
> processed in batch by proxies (and hence are not real-time), 
> these operation
> really should be done using Access Request messages.
> 
> > server must maintain the session. If authorization commands 
> > would be used, then during initial authorization the 
> > authorization server should establish the session towards 
> > credit control server in order to perform 'prepaid 
> > authorization'. 
> Well, in my opinion the Access Device talks to the HAAA. The 
> HAAA then talks
> to the Prepaid System.  Both results comeback to the Access Device.
> 
> This is a Diameter problem which in my opinion needs to be 
> fixed.  The HAAA
> should be able to communicate with a prepaid server using your
> specification.  Both the resutls need to be combined and sent 
> back to the
> Access Device.  Diameter should allow me to do that.  
> 
> >Then the re-authorization for additional 
> > quotas during the session should flow through the AAA server 
> > to the prepaid server, adding an 
> > for the services as well. For instance for multimedia 
> > services the Diameter Multimedia Application can be used.
> 
> If its not for 3GPP then I think my scenrio should be 
> considered.  3GPP2
> does it in one phase.  There are timing issues.  There is a 
> concern that to
> phases will take too long.
> 
> > Regards......Harri
> >

---

From: <[email-masked]>
Date: Fri, 11 Apr 2003 13:37:07 +0300

> (H)AAA would be out of the scope of the draft.

I would agree with this.

> authorizations commands should be able to carry those.

I think we are focusing too much on access prepaid where it is obvious
that the requested service is "network access". The intent of the CCA
is a generic application to cover also other needs, we have also e.g.
application servers that might implement a number of different applications 
then it is not so evident anymore for the HAAA to know what service the user
wants if we don't have rating input in the request.
Therefore the result is that all the authorization&authentication
commands must be updated to carry those parameters.

> Might be true for RADIUS. I haven't seen any such statements 

I haven't seen either.

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 11 Apr 2003 13:53:37 -0700

Harri,

  I see prepay as an interesting mix of Authorization AND Accounting.

  The sequence diagram on slide 4 of the powerpoint slides at:

  Show this mix.  I view the initial request (the Diameter "START"
message) as effectively being an "authorization" request, with
a response either granting some capability or denying.

  Based on the response the service element will then "account"
for the delivered service in a subsequent message.

  I prefer the standard UML Sequence diagram of this slide as
opposed to the prose based state tables, as I think it is a
bit easier to visualize.  Unfortunately the RFC editorial policy
restricts things to ASCII art, which can be a real pain to
edit.

Regards,

  Jeff Meyer

> Sent: Friday, April 11, 2003 12:56 AM

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Mon, 14 Apr 2003 08:48:07 +0200

Hi Jeff,

> for the delivered service in a subsequent message.

I agree, with the accounting[start] message one does the 'prepaid
authorization' - credit control is on the border of authorization
and accounting. But when using Diameter it is not possible to start
a session with an authorization command and then continue it with 
the accounting[interim] command and terminate the session with the 
accounting[stop] command. The accounting session has to be started 
with accounting[start], which is missing from your sequence.

Since the authorization process in this case is tightly coupled with
the prepaid account in the prepaid server and you can't skip the
accounting[start] record then the accounting[start] will serve as 
combination of 'prepaid authorization' and 'reservation of credit from
prepaid account'. And because the Diameter base accounting suits so well
for prepay too, we decided to reuse it for credit control by adding the
prepay aspect to it, i.e. real-time rating, credit check, credit-reservation,
grating of credit, etc. In fact the Session Based Credit Control (section 3.1)
defines same functionality what you proposed.

Regards.........Harri

> Sent: 11. huhtikuuta 2003 23:54
> To: Harri Hakala (LMF); [email-masked]'; 'Avi Lior'
> > > > Subject: RE: [AAA-WG]: 
> draft-hakala-diameter-credit-control-06.txt
> > > > 
> > > > 
> > > > Hi Avi,
> > > >