Subject: [AAA-WG]: DCC: Result-Code AVP in G-S-U

From: "Christopher Richards" <[email-masked]>
Date: Fri, 19 Dec 2003 16:03:14 -0600

Hello All,

Currently, the Result-Code AVP has the scope of the overall session.
However, with multiple quotas per CCA, where the credit-control server may
allow or deny usage to rating groups independently, there is a need to have
a per Granted-Service-Unit Result-Code AVP.

For example a user may request two quotas for two different services or
rating groups. The credit-control server, may issue quota for one of them
but deny the other. In the denied G-S-U AVP, we would expect to find the
following fields:- Result-Code, Rating-Group and Final-Unit-Indication.
 
I propose changing the G-S-U AVP from: 

         Granted-Service-Unit ::= < AVP Header: 431 > 
                                  [ Tariff-Time-Change ]   
                                  [ CC-Time ] 
                                  [ CC-Money ]   
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ] 
                                  [ Final-Unit-Indication ] 

To: 
         Granted-Service-Unit ::= < AVP Header: 431 > 
                                  { Result-Code }
                                  [ Tariff-Time-Change ]   
                                  [ CC-Time ] 
                                  [ CC-Money ]   
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ] 
                                  [ Final-Unit-Indication ] 

Best Regards, 
Chris.

---

From: "Stura Marco" <[email-masked]>
Date: Sat, 20 Dec 2003 11:20:50 +0200

Hi Chris,

I think before continue any such discussions it would be good if you clarify
with a concrete and clear example what is your credit allocation strategy
and your client reporting strategy, what is the resulting signaling load,
client logic and credit management complexity your solution would create.

I'm concerned that until you don't address the above mentioned issues
we are completely stuck  in an endless discussion.

Br
Marco

>From: "Christopher Richards" <[email-masked]>
>To: [email-masked]
>Subject: [AAA-WG]: DCC: Result-Code AVP in G-S-U
>Date: Fri, 19 Dec 2003 16:03:14 -0600
>
>Hello All,
>

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 22 Dec 2003 10:59:15 -0600

Hi Marco,

I'm using the assumptions that:
- Quotas (G-S-U's) allow an amount of resource usage for a particular
Rating-Group.
- Multiple G-S-U AVPs may be returned in a single CCA.
- The G-S-U resources for each Rating-Group are allocated independently of
any others.
- G-S-U resources may be requested by the client and allocated by the server
at any point in a session.
- Each G-S-U resource size (& unit) allocation is independent of any others.
It is a function of the server.
- A user may (probably will) use each resource at a different speed to
others.

It is not inconceivable that:
- One G-S-U resource allocation in the client may be exhausted more quickly
than another
- Some event may happen that affects the "cost" of one G-S-U resource
differently than another.

Therefore, it seems that:-
- The client may need to re-authorize G-S-U resource allocations
independently.
- The server may need to re-authorize & reallocate resources for each G-S-U
independently.
- The server may even deny one G-S-U resource while allowing others.
- Deny actions for one G-S-U resource may be different from others.

Given the above, it would appear that each G-S-U should contain enough
information in it to enable the above functionality.

As an example, a user may request two quotas for two different services or
rating groups.
The credit-control server, may issue quota for one of them but deny the
other.
In the allocated G-S-U AVP we would expect to find:- Result-Code (Success),
unit allocation, Rating-Group.
In the denied G-S-U AVP, we may expect to find the following fields:-
Result-Code (Denied-Insufficient funds), Rating-Group and
Final-Unit-Indication (Action: REDIRECT; Redirect-Server:...).

The Result-Code allows the client to differentiate different success, denied
& failure reasons for each G-S-U and potentially take different actions (In
addition to the Final-Unit-Indication AVP action) depending on the reason.

For example, here is first stab at a list of Result-Codes:
	Successful Auth of a new quota
	Successful Auth (Request return of other, idle quotas)
	Successful Re-auth for an existing quota
	Successful Re-auth (Request return of other, idle quotas)
	Denied - General Error (Terminate)
	Denied - Insufficient Funds (Request return of other, idle quotas)
	Denied - Too many quotas in use (Request return of idle quotas)
	Denied - Unknown Rating-Group requested
	Denied - Incompatible QoS
	Denied - Rate restricted from use for this session

Marco, to help answer one of your other concerns in another email
(Inter-operability between clients & servers), having the client and server
be able to supply each other with more granular information helps ensure
inter-operability. As I see it there are two ways to ensure
inter-operability:-

(1) Specify exactly how to handle every single event and case:- ensure that
none are missed or incorrect. 
(2) Provide enough information to each element so that each element can take
an informed decision.

If you decide to choose (1), you'd better make sure that you've not missed
any existing functionality, not made some incorrect assumptions and have
thought of all reasonable future functionality. Good luck!

Best Regards,
Chris.

-----Original Message-----
From: Stura Marco [mailto:[email-masked]] 
Sent: Saturday, December 20, 2003 3:21 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC: Result-Code AVP in G-S-U

Hi Chris,

I'm concerned that until you don't address the above mentioned issues we are
completely stuck  in an endless discussion.

Br
Marco

>However, with multiple quotas per CCA, where the credit-control server 
>may allow or deny usage to rating groups independently, there is a need 
>to have a per Granted-Service-Unit Result-Code AVP.
>
>rating groups. The credit-control server, may issue quota for one of 
>them but deny the other. In the denied G-S-U AVP, we would expect to 
>find the following fields:- Result-Code, Rating-Group and 
>Final-Unit-Indication.
>