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

From: "Christopher Richards" <[email-masked]>
Date: Fri, 9 Jan 2004 13:22:19 -0600

Happy New Year, all.

I'm not sure we can assume that all the resources given to a user originate
from the same resource account. As you suggested, they may be completely
independent. But that should not require the use of a sub-session. 

Besides, how will a client know that a resource may be provided from a
different pool and so know to use a new sub-session? If the server has the
knowledge of what resources come from what pools, the use of the sub-session
can only be done after the request has been made by the client.

Alternatively, instead of treating independent quotas as independent
sub-sessions (Thus achieving quota independence), it seems simpler and
easier and more efficient to treat quotas independently within the same
sub-session.

By that I mean each quota should include all the information relative to it
(result code, redirect info, tariff time change, etc). Also saves the extra
messaging.

Sub-sessions have a different meaning in the 3G world. A single user session
may have a number of (sub) secondary sessions.  

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Friday, January 09, 2004 1:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; Leena Mattila (TU/LMF)
Subject: [AAA-WG]: Issue: DCC Multiple services in a user's session,
independent quo tas

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).

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 12 Jan 2004 14:58:50 +0100

Hi Chris,

>I'm not sure we can assume that all the resources given to a user originate from
>the same resource account. As you suggested, they may be completely independent. 
>But that should not require the use of a sub-session.

>Besides, how will a client know that a resource may be provided from a different 
>pool and so know to use a new sub-session? If the server has the knowledge of what
>resources come from what pools, the use of the sub-session can only be done after 
>the request has been made by the client.

We have stated that the Service-Identifiers and Rating-Groups are locally 
configured in the Service Element or provisioned by some other entity. That is,
all the services subject to the same rating type and account shall be part of
the same Rating-Group and all the services subject to the same Rating-Group
can use same sub-session.

Alternatively the client can start an own sub-session for each service, and 
thus let the server to handle the combination of the quotas, if needed. 

>Alternatively, instead of treating independent quotas as independent sub-sessions
>(Thus achieving quota independence), it seems simpler and easier and more efficient
>to treat quotas independently within the same sub-session.
>

I disagree that it is simpler and easier to treat quotas independently within the 
same "sub"-session. This means that you should report/request quotas also independently,
i.e. to handle these quotas by using independent CCR/CCA commands, and thus having sort of
sub-session within sub-session and/or session. For instance in fault situations, e.g. 
transport failure, to handle these independent quotas would make the procedures and state 
machines very complicated.

In addition, creating sort of sub-session within sub-session and/or session introduces
yet another option to support sub-sessions and increases the complexity of the system.
The way of supporting sub-sessions in Diameter is outlined in RFC3588, we just need to 
align with RFC3588. This is exactly what the issue does.

As already discussed many times you are proposing to create sub-sessions embedded in
a Diameter session, but isn't it much better and cleaner also for the service handling
to explicitly signal sub-sessions according RFC3588 without re-inventing the
wheel. 

>Sub-sessions have a different meaning in the 3G world. A single user session may have
>a number of (sub) secondary sessions.  

I guess you are referring to secondary PDP Contexts. Secondary PDP contexts
would just trigger a DCC sub-session carrying different QoS attributes for 
rating purposes etc (just another service) that would close when the secondary
PDP context close. 

Regards......Harri

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 15 Jan 2004 11:58:59 -0600

Hi Harri,

I added some comments about this issue below.

Cheers,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Monday, January 12, 2004 7:59 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; Leena Mattila (TU/LMF)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quo tas

Hi Chris,

>I'm not sure we can assume that all the resources given to a user 
>originate from the same resource account. As you suggested, they may be 
>completely independent. But that should not require the use of a 
>sub-session.

>different

We have stated that the Service-Identifiers and Rating-Groups are locally 
configured in the Service Element or provisioned by some other entity. That
is, all the services subject to the same rating type and account shall be
part of the same Rating-Group and all the services subject to the same
Rating-Group can use same sub-session.

[CR]
So the current proposal is to provision on each client node, which services
WILL use resources from the same  resource pool? 
Therefore each client node must know in advance exactly what resource pools
exist for all potential users and service providers? 
And, that this grouping is not dynamic or expected to change too often?

Sounds a bit unrealistic to me. Each time a new resource pool is created, it
may mean going to each client node and re-assigning existing groupings. 

Imagine a tariff architecture where the resource pools available to users is
constantly being modified (Special offers from operator or 3rd party service
providers, etc) - each time this happens, the operator must go into each
client and modify the entire rating groups? 

Sounds unworkable to me. I do not think that the DCC client should know in
advance what resource pool some rated service usage should come from - which
is what the document currently suggests. That's the domain of the charging
system (OCS, etc).
[End CR]

>By that I mean each quota should include all the information relative 
>to it (result code, redirect info, tariff time change, etc). Also saves 
>the extra messaging.

I disagree that it is simpler and easier to treat quotas independently
within the 
same "sub"-session. This means that you should report/request quotas also
independently, i.e. to handle these quotas by using independent CCR/CCA
commands, and thus having sort of sub-session within sub-session and/or
session. For instance in fault situations, e.g. 
transport failure, to handle these independent quotas would make the
procedures and state 
machines very complicated.

[CR]
Do not think of different rated services as different sub-sessions. This is
not correct. An operator may specify many thousands of rated services. Leave
it up to the Charging system (OCS) to determine where and how the resources
for some traffic. It is not the job of the client to have this information.
[End CR]

In addition, creating sort of sub-session within sub-session and/or session
introduces yet another option to support sub-sessions and increases the
complexity of the system. The way of supporting sub-sessions in Diameter is
outlined in RFC3588, we just need to 
align with RFC3588. This is exactly what the issue does.

As already discussed many times you are proposing to create sub-sessions
embedded in a Diameter session, but isn't it much better and cleaner also
for the service handling to explicitly signal sub-sessions according RFC3588
without re-inventing the wheel. 

[CR]
I'm not proposing re-inventing the wheel. With DCC, we have a chance to
specify a flexible and extensible (And usable) protocol. I do not think the
current draft is either a better or cleaner solution by using sub-sessions
in this way.
[End CR]

>Sub-sessions have a different meaning in the 3G world. A single user 
>session may have a number of (sub) secondary sessions.

I guess you are referring to secondary PDP Contexts. Secondary PDP contexts
would just trigger a DCC sub-session carrying different QoS attributes for 
rating purposes etc (just another service) that would close when the
secondary PDP context close. 

[CR]
But with the current scheme, a single PDP context may have multiple
sub-sessions. Adding secondary PDP contexts for the same session, we end up
with many sub-sessions: some for the same PDP context and some for the other
PDP context. It will make trying to correlate all these sub-sessions with
each other and with the user session a whole lot more complicated.
[End CR]

Regards......Harri