Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 31 Oct 2003 12:33:41 +0100

Hi Christopher,

>Mixing applications is already described in the Diam CC draft (Adding DCC AVPs to the AA messages). 
>I'm only proposing the >logical mirror of the existing mixing.
>To me, it seems cleaner than impacting an already existing protocol with new features. Better to build
>existing features & functionality into the new protocol.

We have defined a scenario, as you said, where the initial credit control request is performed as
part of the authentication/authorization for the sake of protocol efficiency. After the initial request, 
following credit control requests are done with credit control messages, likewise following 
(re-)authentication & authorization requests are done with AA messages.

It is true that some credit control specific AVPs (e.g. Requested-Service-Unit or some Rating Input AVPs)
may be added to initial service specific AA message, but I assume that *[AVP] notation makes this possible
without any major impact to the existing protocols. But also vice versa approach, i.e. AA AVPs added to the
CCR message causes some impacts to existing AA implementations, since then AA servers shall support initial
authentication and authorisation with the CCR message.

Regards........Harri

---

From: "Mark Grayson (mgrayson)" <[email-masked]>
Date: Fri, 31 Oct 2003 01:41:44 +0100

Christopher

as I understand, RFC 3588 explicitly differentiates between new
accounting applications and authentication applications. Therefore I
would not be in favour of mixing the two, otherwise we will end up
overloading DCC with NASREQ issues, EAP issues and the like.

Cheers,
Mark
-----Original Message-----
From: Christopher Richards [mailto:[email-masked]] 
Sent: 31 October 2003 00:04
To: 'Harri Hakala (TU/LMF)'; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];
[email-masked]; [email-masked]; Patrik Teppo
(KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

Thank you Harri for your response.

I would like to propose modifications to allow the Diameter CC client to
include AA authentication and authorisation parameters in the initial
CCR.

In fact, the existing figure 1 (page 9) has exactly this scenario.

Whether a AA server is fitted out with a CC client or a CC server has
the capability to perform AA functions is fairly arbitrary. I could
argue that in the case where a subscriber has a centralized account, it
makes sense that the same function performing the credit control also
performs the authentication & authorisation (session / access control). 

From a technical point of view - I would say that it is better to try to
not impact any existing interfaces (AA) by adding new AVPs and
functionality. Instead, build the functionality existing in existing
protocols into the new one. I.e. Have Diameter CC application perform AA
roles.

The beauty of this is that is more easily enables a merging of both pre-
and post-paid services in the future - removing the artificial
separation of pre-paid and post-paid accounts. And brings 3GPP and 3GPP2
closer together. 

At the very least, the option should be allowed and described in the
document.

I propose changing the text on page 17 from:-

    Two different approaches are defined for the first interrogation to 
    suit properly in all the possible architectures. The first approach 
    uses credit-control messages after user's authorization and 
    authentication took place. The second approach uses service specific

    authorization messages to perform the first interrogation during the

    user's authorization/authentication phase, and credit-control 
    messages for the intermediate and the final interrogations. 
    In case an implementation of the credit-control client supports both

    the methods, it SHOULD be configurable what method to use. 

to:-

    Three different approaches are defined for the first interrogation
to 
    suit properly in all the possible architectures. The first approach 
    uses credit-control messages after user's authorization and 
    authentication took place. The second approach uses service specific

    authorization messages to perform the first interrogation during the

    user's authorization/authentication phase, and credit-control 
    messages for the intermediate and the final interrogations. 
    The third approach uses AA specific AVPs in the initial Diameter
Credit
    Control Request message.
    In case an implementation of the credit-control client supports two
or
    more of the methods, it SHOULD be configurable what method to use. 

Add sub clause 5.1.3:- 

 5.1.3 Authorization In First Credit Control Interrogation 
     
    The Diameter credit-control client in the service element MAY
    include the authorization/authentication functionality in 
    the construction of the CC request by adding appropriate AA
    AVPs to the CCR message. The credit-control client MUST add
    the AA AVPs to indicate authorization/authentication is requested.
    The Diameter CC server determines whether or not 
    subscriber authentication / authorization is required. Subscriber
    authorization/authentication MAY be performed by the CC server
    or may be forwarded to the home AA server as necessary.       
          
    The following diagram illustrates the use of authorization / 
    authentication AVPs in the first Credit Control Request. The 
    parallel accounting stream is not shown in the figure. 
     
    End-User        Service Element        CC Server           AAA
Server 
                     (CC Client)                         
       | Service Request   | CC Request (AA AVPs)                    | 
       |------------------>|------------------->|                    | 
       |                   |                    | AAR (Initial, AA AVPs)

       |                   |                    |------------------->| 
       |                   |                    |    AAA (AA AVPs)   |
       |                   |                    |<-------------------| 
       |                   | CC Answer(Granted-Units, AA AVPs)       | 
       | Service Delivery  |<-------------------|                    | 
       |<----------------->|                    |                    | 
       |         :         |                    |                    | 
       |         :         |                    |                    | 
       |         :         |                    |                    | 
       |                   |                    |                    | 
       |                   | CCR(Update,Used-Units)                  | 
       |                   |------------------->| 
       |                   |                    | 
       |                   |                    |  
       |                   |  CCA(Granted-Units)|
       |                   |<-------------------|                     
       |         :         |                    |                     
       |         :         |                    |                    
       | End of Service    |                    |                     
       |------------------>| CCR(Termination,Used-Units)             
       |                   |------------------->| 
       |                   |                    |
       |                   |                    |                
       |                   |                CCA |
       |                   |<-------------------|               
     
                 Figure 5: Protocol example with use of the CCR
             messages for the first authorization interrogation. 

 5.2 Intermediate Interrogation  

Please let me know if this is OK.

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: Monday, October 27, 2003 1:07 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];
[email-masked]; [email-masked]; Patrik Teppo
(KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: Diam CC questions

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, 
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: "Christopher Richards" <[email-masked]>
Date: Fri, 31 Oct 2003 08:53:29 -0600

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Friday, October 31, 2003 5:34 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; 'Mark Grayson (mgrayson)';
[email-masked]; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];
[email-masked]; [email-masked]; Patrik Teppo (KA/EAB)
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

Hi Christopher,

>existing features & functionality into the new protocol.

We have defined a scenario, as you said, where the initial credit control
request is performed as part of the authentication/authorization for the
sake of protocol efficiency. After the initial request, 
following credit control requests are done with credit control messages,
likewise following 
(re-)authentication & authorization requests are done with AA messages.

It is true that some credit control specific AVPs (e.g.
Requested-Service-Unit or some Rating Input AVPs) may be added to initial
service specific AA message, but I assume that *[AVP] notation makes this
possible without any major impact to the existing protocols. But also vice
versa approach, i.e. AA AVPs added to the CCR message causes some impacts to
existing AA implementations, since then AA servers shall support initial
authentication and authorisation with the CCR message.

[Chris Richards] Great. Since the mechanisms for one approach are described,
it makes sense to describe the mirror approach - just for consistency and
clarity. It is still completely up to vendors/implementers to choose which
mechanism to provide. What we're aiming for is a good, flexible and
efficient protocol definition that can accommodate future requirements.

Cheers, Chris.

Regards........Harri

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 30 Oct 2003 18:58:17 -0600

Hi Mark,

Credit control really is in both realms - accounting and
authorisation/authentication. 

Mixing applications is already described in the Diam CC draft (Adding DCC
AVPs to the AA messages). I'm only proposing the logical mirror of the
existing mixing.

To me, it seems cleaner than impacting an already existing protocol with new
features. Better to build existing features & functionality into the new
protocol.

Cheers,
Chris.

-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 6:42 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]; Harri Hakala (TU/LMF);
[email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];
[email-masked]; [email-masked]; Patrik Teppo (KA/EAB);
[email-masked]
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

Christopher

as I understand, RFC 3588 explicitly differentiates between new accounting
applications and authentication applications. Therefore I would not be in
favour of mixing the two, otherwise we will end up overloading DCC with
NASREQ issues, EAP issues and the like.

Cheers,
Mark
-----Original Message-----
From: Christopher Richards [mailto:[email-masked]] 
Sent: 31 October 2003 00:04
To: 'Harri Hakala (TU/LMF)'; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];
[email-masked]; [email-masked]; Patrik Teppo (KA/EAB);
[email-masked]'
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

I would like to propose modifications to allow the Diameter CC client to
include AA authentication and authorisation parameters in the initial CCR.

Whether a AA server is fitted out with a CC client or a CC server has the
capability to perform AA functions is fairly arbitrary. I could argue that
in the case where a subscriber has a centralized account, it makes sense
that the same function performing the credit control also performs the
authentication & authorisation (session / access control). 

From a technical point of view - I would say that it is better to try to not
impact any existing interfaces (AA) by adding new AVPs and functionality.
Instead, build the functionality existing in existing protocols into the new
one. I.e. Have Diameter CC application perform AA roles.

The beauty of this is that is more easily enables a merging of both pre- and
post-paid services in the future - removing the artificial separation of
pre-paid and post-paid accounts. And brings 3GPP and 3GPP2 closer together. 

to:-

    Three different approaches are defined for the first interrogation to 
    suit properly in all the possible architectures. The first approach 
    uses credit-control messages after user's authorization and 
    authentication took place. The second approach uses service specific

    user's authorization/authentication phase, and credit-control 
    messages for the intermediate and the final interrogations. 
    The third approach uses AA specific AVPs in the initial Diameter Credit
    Control Request message.
    In case an implementation of the credit-control client supports two or
    more of the methods, it SHOULD be configurable what method to use. 

Add sub clause 5.1.3:- 

          

     

Cheers, 
Chris. 
-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Monday, October 27, 2003 1:07 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];
[email-masked]; [email-masked]; Patrik Teppo (KA/EAB);
[email-masked]'
Subject: RE: [AAA-WG]: Diam CC questions

Hi Christopher,

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, 
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

     
    
   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: "Christopher Richards" <[email-masked]>
Date: Fri, 31 Oct 2003 08:46:29 -0600

Hi Marco, all,
 
I was not suggesting making this approach mandatory - just another optional
mechanism.
 
If we agree that it is very inefficient to do 2 sets of requests/responses
for every call setup - and that including CC information in an initial AA
request is OK, I cannot see why including AA information (Whether that be
RADIUS or NASREQ or whatever) in the Diameter CC request is so bad.
 
The message flow already exists. Most of the AVPs already exist. I am
proposing adding just user name/password/PAP/CHAP information.
 
By maintaining RADIUS for the initial interrogation, you are forcing new CC
server implementations to support both RADIUS and Diameter stacks, or force
each session setup to perform two sets of requests/responses or force the
network RADIUS server to perform Diameter proxy functions --- none of these
options are particularly attractive - it adds complexity, setup latency and
cost to provide the service.
 
Imagine how much easier it could be to do it all in one shot to one
functional entity.

Cheers, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 31, 2003 2:01 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

Hi,
 
Christopher Richards wrote:

This has been extensilvely discussed before the CCA was accepted as a AAA WG
item, the conclusion has been that credit control is definitely in the
authorization space. This is why the CCA is an authorization application and
I would stick on this.

Mark Grayson wrote:

I strongly agree with Mark. Please note that we are not mixing applications
with the current approach, while with Chris approach we would do. The
mechanism described is heavily relying on the service specific
authentication/authorization applications to perform the tasks they are
designed for. The only addition in the AA command (and AA here doesn't mean
NASREQ only), is an indication of credit control capabilities, the mechanism
is mirrored from the RADIUS model and also facilitate RADIUS/DIAMETER IOP.

As a conclusion I wouldn't like to see yet another option, rather I would
stick on the existing RADIUS model for
performing the first interrogation.
 
Regards
Marco

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 31 Oct 2003 08:48:19 -0600

Thanks John,

I'll take a look at the thread.

I'm not saying that the current proposal is broken - just lacking and
inefficient.

Since we're at the draft stage now, it seems like a good time to propose
making improvements to the existing mechanism. It's not too late for that I
trust?

Cheers,
Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 31, 2003 2:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

Hi Christopher,

> Mixing applications is already described in the Diam CC draft (Adding DCC
AVPs to the AA 
> messages). I'm only proposing the logical mirror of the existing mixing.
> 
> To me, it seems cleaner than impacting an already existing protocol 
> with new features.
> Better to build existing features & functionality into the new protocol.

The issue of accounting vs authorization has been discussed on the mailing
list, there are two issues filed about this already, which can be found
here:

http://www.drizzle.com/~aboba/AAA/issues.html

Unless you can find some reasons why the current model the CCA has proposed
is broken, I suggest we don't revisit this issue.

thanks,
John

---

From: <[email-masked]>
Date: Fri, 31 Oct 2003 10:17:55 +0200

Hi Christopher,

> Credit control really is in both realms - accounting and authorisation/authentication. 
> Mixing applications is already described in the Diam CC draft (Adding DCC AVPs to the AA 
> To me, it seems cleaner than impacting an already existing protocol with new features. 

The issue of accounting vs authorization has been discussed on the mailing list, there are two issues filed about this already, which can be found here:

Unless you can find some reasons why the current model the CCA has proposed is broken, I suggest we don't revisit this issue.

thanks,
John

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 30 Oct 2003 18:03:50 -0600

to:-

Add sub clause 5.1.3:- 

          
     
    End-User        Service Element        CC Server           AAA Server 
                     (CC Client)                         

 
Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Monday, October 27, 2003 1:07 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked];

Hi Christopher,

used to enhance the Diameter CC capabilities.

If there is no technical reason, then I would like to propose that either:- 

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

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] 

    

used to enhance the Diameter CC capabilities.

If there is no technical reason, then I would like to propose that either:- 

resource.

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.

E.g. 

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: Fri, 31 Oct 2003 17:32:57 +0200

Hi Chris,
 
>By maintaining RADIUS for the initial interrogation, you are forcing new CC server implementations to support both RADIUS >and Diameter stacks, or force each session setup to perform two sets of requests/responses or force the network RADIUS >server to perform Diameter proxy functions --- none of these options are particularly attractive - it adds complexity, setup >latency and cost to provide the service.
 
I never said that we use RADIUS for the initial interrogation, rather I was referring to the RADIUS model of including
credit control information in the Access-Request message that is maintained in the Diam CC for the first interrogation with Diameter AA commands.
 
DIAMETER/RADIUS interworking is described in the draft 01 (section 2 and section 11), there is also a flow example in the appendix A. You may want to check this information.
 
>Imagine how much easier it could be to do it all in one shot to one functional entity.
 
The service specific authorization/authentication is specific to the service, that's why different authorization
application exist (e.g. NASREQ, DIAMMIP) which define their own mechanisms and tasks. What you are doing with
the approach you propose is to require to the Diam CC to support all existing and future service specific authorization
and authentication mechanisms and tasks as well as mixing up the command's semantic because, according to
your proposal, Credit-Control-Request now means network access authentication and authorization is requested, authorization and authentication for a mobile node using MIP is requested, credit authorization is requested etc. etc.  Well, it doesn't look so easy and clean....
 
Regards
Marco

---

From: <[email-masked]>
Date: Fri, 31 Oct 2003 10:01:07 +0200

Hi,

This has been extensilvely discussed before the CCA was accepted as a AAA WG item, the conclusion has been that credit control is definitely in the authorization space. This is why the CCA is an authorization application and I would stick on this.

Mixing applications is already described in the Diam CC draft (Adding DCC AVPs to the AA messages). I'm only proposing the logical mirror of the existing mixing.

To me, it seems cleaner than impacting an already existing protocol with new features. Better to build existing features & functionality into the new protocol.

Mark Grayson wrote:

as I understand, RFC 3588 explicitly differentiates between new accounting applications and authentication applications. Therefore I would not be in favour of mixing the two, otherwise we will end up overloading DCC with NASREQ issues, EAP issues and the like.

I strongly agree with Mark. Please note that we are not mixing applications with the current approach, while with Chris approach we would do. The mechanism described is heavily relying on the service specific authentication/authorization applications to perform the tasks they are designed for. The only addition in the AA command (and AA here doesn't mean NASREQ only), is an indication of credit control capabilities, the mechanism is mirrored from the RADIUS model and also facilitate RADIUS/DIAMETER IOP.

As a conclusion I wouldn't like to see yet another option, rather I would stick on the existing RADIUS model for
performing the first interrogation.
 
Regards
Marco