Subject: [AAA-WG]: Issue: DCC Multiple services in a user's session, independent quo tas

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 9 Jan 2004 08:55:13 +0100

Multiple services in a user's session, independent quotas.

Submitter name: Harri Hakala
Submitter email address: [email-masked]
Date first submitted: 09.01.2004
Reference:
Document: Diameter CCA-02
Comment type: T
Priority: 2
Section:
Rationale/Explanation of issue:

Couple of mail threads took already place to discuss the multiple services 
support in one user's session. There has been a lot of confusion around the 
Issue 436 (Multiple services credit control in a single CC session) and 
consequent attempts to mirror all the command level functionalities to the 
G-S-U level in order to create independent credit control sub-sessions 
embedded in a credit control session. The idea behind Issue 436 (Multiple 
services credit control in a single CC session) was to avoid multiple credit 
control sub-sessions and use just ONE single quota for multiple services and 
thus avoid increased signalling load and resource usage in both the 
CC-client and in the CC-server as discussed in 
http://www.merit.edu/mail.archives/aaa-wg/msg00066.html. However, 
independent quotas concept for the support of multiple services credit 
control in a user's session is fully supported in the current DCC (draft 02) 
by using credit control sub-session according to the sub-session concept 
defined in RFC 3588. Therefore creating yet another option to support 
sub-sessions, not according RFC 3588, is not appropriate and, among other, 
would introduce interoperability concerns.
Requirements for independent quotas was brought in 
http://www.merit.edu/mail.archives/aaa-wg/msg00064.html, those requirements 
are already met by the DCC draft 02 as discussed in 
http://www.merit.edu/mail.archives/aaa-wg/msg00067.html.

There is need to clarify:

1- that the DCC standard doesn't mandate a client to implement one or the 
other approach.
2- that a server implementing multiple services credit control in a user's 
session should support cc sub-sessions as well as the approach described in 
issue 436.
3- how to use sub-sessions to handle independent quotas.

Proposed changed:

Change fifth paragraph in section 5
FROM

   When multiple services are used within one user session and each
   service or group of services are subject to different cost, making use
   of credit control sub-sessions will result in increased signaling load
   and resources usage in both the credit control client and the credit
   control server. For instance, during one network access session the
   end user may use several http-services subject to different access
   cost. To optimally support these scenarios, the credit control
   application enables for multiple services credit control in a single
   credit control session. It is possible to request and allocate
   multiple quotas as a credit pool that is shared between multiple
   services. The services can be further grouped into rating groups in
   order to achieve even further aggregation of credit allocation. It is
   also possible to request and allocate multiple quotas on a per service
   basis. The mechanism is illustrated in Appendix A (Flow X).

TO

   When multiple services are used within one user session and each
   service or group of services are subject to different cost, making use
   of credit control sub-sessions will result in increased signaling load
   and resources usage in both the credit control client and the credit
   control server. For instance, during one network access session the
   end user may use several http-services subject to different access
   cost. To optimally support these scenarios, the credit control
   application enables for multiple services credit control in a single
   credit control session. It is possible to request and allocate
   multiple quotas as a credit pool that is shared between multiple
   services. The services can be further grouped into rating groups in
   order to achieve even further aggregation of credit allocation. It is
   also possible to request and allocate multiple quotas on a per service
   basis. Note that this concept implies that one single credit reservation
   is kept and allocated to all the services/rating groups, all the quotas
   are derived from that credit reservation assuming a given service/rating
   group consume the whole amount. Therefore all the possible quotas
   conveyed to the Diameter Credit control client are not independent entities
   as such. An example of this mechanism is illustrated in Appendix A (Flow X).

   Implementations of a credit control client supporting  multiple services
   within one user session may want to request independent quotas
   to the credit control server. This is achieved through credit control
   sub-sessions, which enables for independent control of each of the
   allotted quotas at the cost, however, of increased signaling load and
   resource usage in both the client and the server. An example of
   credit control sub-sessions is illustrated in Appendix A (Flow XI).
   What mechanism a client supports is an implementation choice.
   A credit control server implementing multiple services credit control in
   one user's session SHOULD have capabilities to allocate independent
   quotas as well as derive all the possible quotas from one single credit
   reservation as discussed in the previous paragraph. The server deduces
   whether independent quotas are requested by the existence of
   sub-sessions.

ADD Flow XI in Appendix A

A.11 Flow XI

                Service Element
 End-User           (CC client)                              CC Server
 |(1)User logon      |                                         |
 |------------------>|(2)CCR(initial, Service-Id(access))      |        
 |                   |---------------------------------------->|
 |                   |(3)CCA(Granted-Units(Time))              |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(4)Service-Request (Service 1)                               |
 |------------------>|(5)CCR(initial,sub-session 1,            |
 |                   |       Requested-Units(Rating-Group 1))  |
 |                   |---------------------------------------->|
 |                   |(6)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(7)Service-Request (Service 2)                               |
 |------------------>|                                         |
 :                   :                                         :
 :                   :                                         :
 |                   |(8)CCR(update,Service-Id(access),        |
 |                   |       Used-Units(Time,                  |
 |                   |                  Service-Id(access))    |  
 |                   |---------------------------------------->|
 |                   |(9)CCA(Granted-Units(Time))              |
 |                   |<----------------------------------------|
 |       +----------------------+                              |
 |       | (10)Validity-Time    |                              |
 |       | sub-session 1 expires|                              |
 |       +----------------------+                              |
 |                   |(11)CCR(update,sub-session 1,            |
 |                   |              Used-Units(Input-Octets,   |
 |                   |                         Output-Octets,  |
 |                   |                         Service-Id 1,   |
 |                   |                         Rating-Group 1),|
 |                   |              Used-Units(Input-Octets,   |
 |                   |                         Output-Octets,  |
 |                   |                         Service-Id 2,   |
 |                   |                         Rating-Group 1),|
 |                   |         Requested-Units(Rating-Group 1))|
 |                   |---------------------------------------->|
 |                   |                (12)CCA(Result-Code 4010)|
 |                   |<----------------------------------------|
 :                   :                                         :
 |(13) User logoff   |                                         |
 |------------------>|(14)CCR(term, Used-Units(Time,           |
 |                   |              Service-Id(access)))       |   
 |                   |---------------------------------------->|
 |                   |(15)CCA(term)                            |
 |                   |<----------------------------------------|

   Figure A.11: Credit Control for Multiple Services in One User's
                session, credit control sub-sessions.

Figure A.11 is an example of credit control for multiple services in one user's session making use of credit control sub-sessions. In contrast with flow x, the credit control client is requesting independent quotas per each of the services. In order to avoid allocation of resources to unused services, the client triggers credit authorization and starts a credit control sub-session only when the end-user requests a service that belongs to a rating group for which quota has not been authorized. The server sets the Validity-Time to a suitable value to control unused units.

It is assumed that the Service-Identifiers and the Rating-Groups are locally configured in the Service Element or provisioned by another entity than the credit control server.      

The user logs onto the network (1). The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization for the access (e.g. internet access) and to establish a credit control session (2). In this message credit authorization is requested for the access by including the Service-Identifier AVP equal to "[email-masked]". The Diameter credit-control server checks the end user's account balance, based on Service-Identifier, rates the request and may reserve credit from the end user's account if the access fee as such is chargeable.
A quota can be returned to the Service Element (3). The user now start using Service 1 (4) that belongs to a non-authorized rating group (Rating-Group 1), thus the credit control client initiates a sub-session to request an individual quota for Rating-Group 1 (5). A quota is returned to the Service Element (6).
The user uses Service 2 as well, that belongs to Rating-Group 1 (7). The client utilizes then credit resources allocated in step 6. 
When the user has consumed the credit allocated to the access, the Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit control server (8). This message contains the units used for the internet access in the Used-Service-Unit AVP and the Service-Identifier AVP to request credit re-authorization for the main credit control session. The Diameter credit-control server debits the used units from the end user's account and reserves a new amount of credit that is returned to the Service Element in the Diameter Credit-Control-Answer (9). 

Since the end-user is not consuming resources from Rating-Group 1 anymore, the Validity-Time of the credit control sub-session expires (10). The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit control server (11). This message contains the units consumed by each of the used services in the Used-Service-Unit AVPs. The used units are associated with the relevant Service-Identifier and Rating-Group. In this message credit re-authorization is requested for Rating-Group 1 by including the Requested-Service-Unit AVP.  The Diameter credit-control server debits the used units to the user's account and, based on server specific policy, determines that credit re-authorization for Rating-Group 1 is denied because of user inactivity. The server returns then a failed Diameter Credit-Control-Answer with Result-Code AVP set to the value 4010 (DIAMETER_END_USER_SERVICE_DENIED) to deny all the traffic related to Rating-Group 1 !
 and close the sub-session (12).

The end user logs off from the network (13). To debit the used units from the end user's account and to stop the credit control session, the Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the credit control server (14). This message contains the units consumed by the main credit control session in the Used-Service-Unit AVP. The used units are associated with the relevant Service-Identifier. The Diameter credit-control server debits the used units to the user's account and acknowledges the session termination by sending a Diameter Credit-Control-Answer to the Service Element (15).