Subject: [AAA-WG]: Diam CC questions

From: "Christopher Richards" <[email-masked]>
Date: Fri, 24 Oct 2003 15:47:41 -0500

Hello All,

I have a couple of questions regarding the Diameter Credit Control draft.

In clause 2 and 4.2, the document discusses the capability to combine credit
authorisation with service specific authorisation and authentication. (Note:
on page 20, clause 4.1.1 seems mis-numbered)

2. Architecture Models
[snip]
   In servive environments such as the Network Access Server (NAS) and 
   Mobile IP, it is a requirement to perform the first interrogation as 
   part of the authorization/authentication process for the sake of 
   protocol efficiency. Further credit authorizations after the first 
   interrogation took place are performed with credit control commands 
   defined in this specification. Implementations of credit-control 
   client operating in the mentioned environments SHOULD support this 
   method. In case the credit-control server and AAA server are separate 
   physical entities the service element send the request messages to 
   the AAA server, which then issue an appropriate request or proxy the 
   received request forward to the credit-control server. 
    
   In other service environments, such as the 3GPP network and some SIP 
   scenario, there is a substantial decoupling between 
   registration/access to the network and the actual service request 
   (i.e. the authentication/authorization is executed once at 
   registration/access to the network and is not executed for every 
   service event requested by the subscriber). In such environments it 
   is more appropriate to perform the first interrogation after the user 
   has been authenticated and authorized. The first interrogation as 
   well as intermediate and final interrogations is executed with credit 
   control commands defined in this specification. Implementations of 
   credit-control client operating in 3GPP environment SHOULD support 
   this method. In 3GPP environment the service element sends the 
   request message directly to the credit-control server. 
     
4.2 Authorization Messages for First Interrogation 
    
   In the second approach, the Diameter credit-control client in the 
   service element MUST actively contribute with the 
   authorization/authentication client in the construction of the AA 
   request by adding appropriate credit control AVPs. 
[snip]

I'm not sure that the assumption regarding different service environments
for MIP and 3GPP is true. At best this is an opinion which may or may not be
correct. Personally, I do not think that there will be a simple distinction
like this. Would it be best to remove this - if for no reason other brevity?

My main question: Is there an overriding technical reason why Diameter
credit-control AVPs are added to a AA request and not the other way around
when the initial AAA interrogation is made? I.e. Would it not be a cleaner
solution to add AA AVPs to the Diameter credit-control client request. In
this way, there is no "leakage" of the Diameter credit-control application
into existing AA applications. Instead, the AA applications actually can be
used to enhance the Diameter CC capabilities.

If there is no technical reason, then I would like to propose that either:-
(a) Replacing the existing text with text that states AA AVPs are added to
Diameter credit-control requests.
(b) Adding text that states AA AVPs are added to Diameter credit-control
requests as a third option for the combining of the initial AAA request.

On a different subject: Multi-quotas and Used-Service-Units &
Granted-Service-Unit structure.

The inclusion of trigger/action/trigger-value and cause fields within the
Granted-Service-Unit structure.

A Granted-Service-Unit is really the permission to use a resource until some
limit is reached or some other session properties change. The permission may
be granted only for the consumption of a particular resource or category of
resource.

The current draft has most of these attributes already defined for the
Granted-Service-Unit. However, it seems to be missing the ability to
instruct the CC client what actions to take in the event of certain session
events. I propose the addition of Triggers, trigger-actions and
trigger-values for the Granted-Service-Unit AVP.

Triggers are such things as: Time changes or changes to the QoS
characteristics of a session or a change in user location (for 3GPP) or
quota usage threshold or quota idle time.

Associated with these triggers are actions that should be taken upon the
trigger. Examples of actions could include: re-authorise quota, return quota
and block further traffic.

Some trigger/actions require a trigger value. For example, the "Idle quota"
trigger, may have an action of "return quota" and a trigger value of "600
seconds". In other words, if this quota has not been used for 600 seconds,
return it to the Diameter CC server.

	 Trigger ::= < AVP Header: TBD >
	             { Trigger-Id }
	             { Trigger-Action }
	             [ Trigger-Value ]

	 Granted-Service-Unit ::= < AVP Header: TBD > 
	                          { Cause-Id }
	                          [ CC-Time ] 
	                          [ CC-Money ]
	                          [ CC-Total-Octets ]
	                          [ CC-Input-Octets ]
	                          [ CC-Output-Octets ]
	                          [ CC-Service-Specific-Units ]
	                         *[ Service-Identifier ]
	                          [ Rating-Group ]
	                         *[ Trigger ]

Cause fields are used in each Used-Service-Unit and Granted-Service-Unit AVP
response. E.g. When a client returns a quota to the server, the cause field
is used to indicate why the quota is being returned. In a
Granted-Service-Unit AVP response, the server indicates if the
Granted-Service-Unit is successfully requested and if not, why.

	 Cause-Id ::= < AVP Header: TBD >
	              { Cause-Value }

E.g.

	    Used-Service-Unit ::= < AVP Header: TBD > 
                                { Cause-Value }
	                          [ CC-Time ] 
	                          [ CC-Money ]
	                          [ CC-Total-Octets ]
	                          [ CC-Input-Octets ]
	                          [ CC-Output-Octets ]
	                          [ CC-Service-Specific-Units ]
	                         *[ Service-Identifier ]
	                          [ Rating-Group ]

For example, in the Used-Service-Units AVP, the cause may be set to "return
of idle quota". The Diameter CC server, would then know not to return any
more Granted-Service-Unit AVP for this Service-Identifier.  

In the Granted-Service-Unit, the cause may indicate that the request was
denied due to "too many Granted-Service-Units in use". The client could then
take action to return idle Granted-Service-Unit quotas. 

Please let me know your thoughts and suggestions regarding these proposals.
If you agree I will prepare a formal change.

Cheers,
Chris Richards.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 27 Oct 2003 08:07:19 +0100

Hi Christopher,
 
Thank you for your comments and suggestions.
For a start answers to your first questions.
 
I'm not sure that the assumption regarding different service environments for MIP and 3GPP is true. At best this is an opinion which may or may not be correct. Personally, I do not think that there will be a simple distinction like this. Would it be best to remove this - if for no reason other brevity?
I think that you are right. The CCA-01 version should fix this.
My main question: Is there an overriding technical reason why Diameter credit-control AVPs are added to  AA request and not the other way around when the initial AAA interrogation is made? I.e. Would it not be a cleaner solution to add AA AVPs to the Diameter credit-control client request. In this way, there is no "leakage" of the Diameter credit-control application into existing AA applications. Instead, the AA applications actually can be used to enhance the Diameter CC capabilities.

If there is no technical reason, then I would like to propose that either:- 
(a) Replacing the existing text with text that states AA AVPs are added to Diameter credit-control requests. 
(b) Adding text that states AA AVPs are added to Diameter credit-control requests as a third option for the combining of the initial AAA request.
The principle is to use the credit control messages only for credit authorization. The authentication and authorization is largely service specific that is why different Diameter applications have been required for authentication & authorization. I assume that it is not desired to use credit control messages also for service specific authentication and authorization, especially when the client doesn't necessarily know whether the user is 'prepaid' user prior to sending the CCR message. In circumstances where majority of the users are still 'postpaid' users, this may lead to situations where the initial credit control messages would be mostly used for authentication and service authorization.

Regards.........Harri

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 24. lokakuuta 2003 23:48
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [AAA-WG]: Diam CC questions

Hello All, 

In clause 2 and 4.2, the document discusses the capability to combine credit authorisation with service specific authorisation and authentication. (Note: on page 20, clause 4.1.1 seems mis-numbered)

2. Architecture Models 
[snip] 

    

I'm not sure that the assumption regarding different service environments for MIP and 3GPP is true. At best this is an opinion which may or may not be correct. Personally, I do not think that there will be a simple distinction like this. Would it be best to remove this - if for no reason other brevity?

My main question: Is there an overriding technical reason why Diameter credit-control AVPs are added to a AA request and not the other way around when the initial AAA interrogation is made? I.e. Would it not be a cleaner solution to add AA AVPs to the Diameter credit-control client request. In this way, there is no "leakage" of the Diameter credit-control application into existing AA applications. Instead, the AA applications actually can be used to enhance the Diameter CC capabilities.

If there is no technical reason, then I would like to propose that either:- 
(a) Replacing the existing text with text that states AA AVPs are added to Diameter credit-control requests. 
(b) Adding text that states AA AVPs are added to Diameter credit-control requests as a third option for the combining of the initial AAA request.

On a different subject: Multi-quotas and Used-Service-Units & Granted-Service-Unit structure. 

The inclusion of trigger/action/trigger-value and cause fields within the Granted-Service-Unit structure. 

A Granted-Service-Unit is really the permission to use a resource until some limit is reached or some other session properties change. The permission may be granted only for the consumption of a particular resource or category of resource.

The current draft has most of these attributes already defined for the Granted-Service-Unit. However, it seems to be missing the ability to instruct the CC client what actions to take in the event of certain session events. I propose the addition of Triggers, trigger-actions and trigger-values for the Granted-Service-Unit AVP.

Triggers are such things as: Time changes or changes to the QoS characteristics of a session or a change in user location (for 3GPP) or quota usage threshold or quota idle time.

Associated with these triggers are actions that should be taken upon the trigger. Examples of actions could include: re-authorise quota, return quota and block further traffic.

Some trigger/actions require a trigger value. For example, the "Idle quota" trigger, may have an action of "return quota" and a trigger value of "600 seconds". In other words, if this quota has not been used for 600 seconds, return it to the Diameter CC server.

Cause fields are used in each Used-Service-Unit and Granted-Service-Unit AVP response. E.g. When a client returns a quota to the server, the cause field is used to indicate why the quota is being returned. In a Granted-Service-Unit AVP response, the server indicates if the Granted-Service-Unit is successfully requested and if not, why.

E.g. 

For example, in the Used-Service-Units AVP, the cause may be set to "return of idle quota". The Diameter CC server, would then know not to return any more Granted-Service-Unit AVP for this Service-Identifier.  

In the Granted-Service-Unit, the cause may indicate that the request was denied due to "too many Granted-Service-Units in use". The client could then take action to return idle Granted-Service-Unit quotas. 

Please let me know your thoughts and suggestions regarding these proposals. If you agree I will prepare a formal change.

Cheers, 
Chris Richards. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: <[email-masked]>
Date: Mon, 27 Oct 2003 14:37:06 +0200

Hi Christopher,
 
thank you for your valuable comments.  
 
Harri already gave some answer to some of your questions, I try to address the others. 
 
I think you have some good point here,  my comments in line.
 
Regards
Marco 
 
P.S.: In general I would suggest you review the draft 01, that should soon appear in the IETF database, and continue the discussion based on this new version of the credit control application. Let me know if you want the draft 01 immediately, in that case I 'll send the document directly to you. Hope this is fine with you.

>On a different subject: Multi-quotas and Used-Service-Units & Granted-Service-Unit structure. 
 
 [MSt]: I guess you refer to  enhancing  the issue I posted last week, right?  Or at least to the multiple quotas in general. 

>A Granted-Service-Unit is really the permission to use a resource until some limit is reached or
> some other session  properties change. The permission may be granted only for the consumption of a particular resource 
>or category of resource.

[MSt]: The CC server grant permission to use resources according to the funds available in the user account. If the server determines that usage of certain resource or category of resource need not to be granted it won't return quota associated to it.

>The current draft has most of these attributes already defined for the Granted-Service-Unit. However, it seems to be missing 
>the ability to instruct the CC client what actions to take in the event of certain session events. I propose the addition of 
>Triggers, trigger-actions and trigger-values for the Granted-Service-Unit AVP.
 
>Triggers are such things as: Time changes or changes to the QoS characteristics of a session or a change in user location
> (for 3GPP) or quota usage threshold or quota idle time.
 
>Associated with these triggers are actions that should be taken upon the trigger. Examples of actions could include: re-
>authorise quota, return quota and block further traffic.
 
>Some trigger/actions require a trigger value. For example, the "Idle quota" trigger, may have an action of "return quota" 
>and  a trigger value of "600 seconds". In other words, if this quota has not been used for 600 seconds, return it to the 
>Diameter CC server.

[MSt]: this feature concerning the QoS changes or other mid-session events is already supported. The assumption is that, if mid-session events occur, the granted quota(s) is(are) not valid anymore and the credit control client need to perform credit re-authorization to the CC server, this is visible in the state machine as well as in section 4. I would not introduce any separate action: the client should send a CCR (update) when such events occur. Concerning the quota idle time we have defined the Validity-time that is used exactly for that purpose (i.e. return quota if not consumed within Validity-Time). Validity-time applies to the whole credit reservation, that is the asset to control. When thinking to multi-quotas, a single credit reservation is kept for the credit control session and rating for all the requested Rating-Groups and Service-Identifiers is performed against the reserved credit (of course according to the cost of a given service or rating group). Many of the issues you listed are already covered in the current draft.

BTW, We have stated that 'a change in rating condition' may trigger a spontaneous update but this has been left totally for the client implementation to decide what kind of change should be regarded important from rating point of view. So, guidance from the CC server should be allowed as well and you have a point here.  Why not to defne the Trigger AVP (maybe in somewhat simpler format) in the CCA message level instead of embedding that in the GSU AVP?

 Also, I agree with you that at least one of the things you listed is not well covered yet , and you have another good point here as well . I'm thinking to the time changes. While QoS changes and location changes occur according to some sort of statistic model, thus a huge storm of CCR messages due to such events is not likely to happen, the time change case may occur for all the active subscribers at the same time. But I'm not sure the Trigger AVP you propose cover my concern related to time changes, it seems the CC client would potentially generate a huge storm of CCR. I think tariff changes can be handled by including tariff-change time in the CCA (but would not treat this as 'trigger') and by reporting used units twice (before and after t-ch, for that we would need a new avp in the USU).  

>Cause fields are used in each Used-Service-Unit and Granted-Service-Unit AVP response. E.g. When a client returns 
>quota to the server, the cause field is used to indicate why the quota is being returned. In a Granted-Service-Unit AVP
> response, the server indicates if the Granted-Service-Unit is successfully requested and if not, why.

[MSt]: I think diameter result codes should be used instead of tailored cause-id avp. There are few  cases  why the client would perform credit re-authorization, but the reason is always "credit re-authorization":
 
1- The credit reservation has been consumed. This is determined by the fact that no units are in possession of the CC client anymore (example for  multiple  quotas can be found in my issue at Flow xxx).
 
2- Mid-session event has occured. The CCR message would include the mid-session event to be rated, the non-consumed reservation will be returned to the user's account. The CC server can determine  the mid-session event from the rating AVPs.
 
3- Validity-Time expires. The CC server is in control of this parameter, it can determine whether the Validity-Time has expired and what to do next.
 
>For example, in the Used-Service-Units AVP, the cause may be set to "return of idle quota". The Diameter CC server, 
>would then know not to return any more Granted-Service-Unit AVP for this Service-Identifier. 
 
>In the Granted-Service-Unit, the cause may indicate that the request was denied due to "too many Granted-Service-Units in
> use". The client could then take action to return idle Granted-Service-Unit quotas. 
 
 [MSt]:  If the client terminates the end-user service and the CC session, it would include the Termination-Cause AVP indicating the  reason. If the CC server determines some error in the CCR message, it would return an appropriate Result-Code AVP value.   In the multi-quota case, I don't see needs to determine credit re-authorization upon a single G-S-U since the asset to control is always the whole credit reservation.

>Please let me know your thoughts and suggestions regarding these proposals. If you agree I will prepare a formal change. 

 [MSt]: I think it would be nice to address the following issues: tariff- time  changes in both the single quota and  the multiple quotas cases;  guidance from the CC server concerning the mid-session events.
 
As I say, I'm not sure your current proposal is perfectly tailored to solve these issues. I would see those as separate issues to be  addressed with different AVPs. Perhaps you could define an AVP for the CC-ReAuth-Trigger and some other mechanism for the tariff-time-change?  It would be great if you can help find a solution to these issues.