Wholesale Prescription Medications!

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?

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

Since we seems to agree with this, I would = discuss the=20 tariff time change with a separate thread.

Is that OK?

Regards

Marco

= ------_=_NextPart_001_01C39F95.47967CBC-- From owner-aaa-wg@merit.edu Fri Oct 31 11:39:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06619 for ; Fri, 31 Oct 2003 11:39:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB1D0912E5; Fri, 31 Oct 2003 03:18:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94189912E6; Fri, 31 Oct 2003 03:18:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04EB3912E5 for ; Fri, 31 Oct 2003 03:18:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9CF65DE22; Fri, 31 Oct 2003 03:17:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 156EA5DDB0 for ; Fri, 31 Oct 2003 03:17:59 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9V8HuG12718 for ; Fri, 31 Oct 2003 10:17:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Oct 2003 10:17:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Oct 2003 10:17:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Date: Fri, 31 Oct 2003 10:17:55 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Thread-Index: AcOfSjUKY1/fNL+lQcWW2CzEI5y+cQAPQk7w From: To: , X-OriginalArrivalTime: 31 Oct 2003 08:17:56.0498 (UTC) FILETIME=[7D1D4F20:01C39F87] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Christopher, > Credit control really is in both realms - accounting and = authorisation/authentication.=20 > Mixing applications is already described in the Diam CC draft (Adding = DCC AVPs to the AA=20 > messages). I'm only proposing the logical mirror of the existing = mixing. >=20 > To me, it seems cleaner than impacting an already existing protocol = with new features.=20 > 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 owner-aaa-wg@merit.edu Fri Oct 31 11:39:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06673 for ; Fri, 31 Oct 2003 11:39:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3B7F9121F; Thu, 30 Oct 2003 19:04:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9834912C9; Thu, 30 Oct 2003 19:04:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18BA59121F for ; Thu, 30 Oct 2003 19:04:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id E87D35DDD1; Thu, 30 Oct 2003 19:03:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id C7B835DE58 for ; Thu, 30 Oct 2003 19:03:58 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9V03qG21642; Thu, 30 Oct 2003 16:03:53 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Oct 2003 18:03:53 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8951@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , aaa-wg@merit.edu Cc: "Leena Mattila (TU/LMF)" , juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, Benni.Alexander@nokia.com, "Patrik Teppo (KA/EAB)" , "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Date: Thu, 30 Oct 2003 18:03:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39F42.76E31A9E" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39F42.76E31A9E Content-Type: text/plain 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:harri.hakala@ericsson.com] Sent: Monday, October 27, 2003 1:07 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Cc: Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); 'marco.stura@nokia.com' 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:crich@nortelnetworks.com] Sent: 24. lokakuuta 2003 23:48 To: aaa-wg@merit.edu Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@po.org 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 ------_=_NextPart_001_01C39F42.76E31A9E Content-Type: text/html Message

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:harri.hakala@ericsson.com]
Sent: Monday, October 27, 2003 1:07 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu
Cc: Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); 'marco.stura@nokia.com'
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:crich@nortelnetworks.com]
Sent: 24. lokakuuta 2003 23:48
To: aaa-wg@merit.edu
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@po.org
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

------_=_NextPart_001_01C39F42.76E31A9E-- From owner-aaa-wg@merit.edu Fri Oct 31 11:39:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06670 for ; Fri, 31 Oct 2003 11:39:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18CCD912E2; Fri, 31 Oct 2003 10:33:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2343912EF; Fri, 31 Oct 2003 10:33:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50A58912E2 for ; Fri, 31 Oct 2003 10:33:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C4C55DDBF; Fri, 31 Oct 2003 10:33:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 314EB5DDFB for ; Fri, 31 Oct 2003 10:33:00 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9VFWxY01569 for ; Fri, 31 Oct 2003 17:32:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Oct 2003 17:32:58 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 31 Oct 2003 17:32:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39FC4.42CFFC08" Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Date: Fri, 31 Oct 2003 17:32:57 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0324@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Thread-Index: AcOfveG1acBYHMGaQvOY4rizeJbbHAAATByQ From: To: , , Cc: , , , , , X-OriginalArrivalTime: 31 Oct 2003 15:32:58.0726 (UTC) FILETIME=[43413860:01C39FC4] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C39FC4.42CFFC08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 >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. =20 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. =20 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. =20 >Imagine how much easier it could be to do it all in one shot to one = functional entity. =20 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.... =20 Regards Marco =20 ------_=_NextPart_001_01C39FC4.42CFFC08 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

Hi=20 Chris,

>By=20 maintaining RADIUS for the initial interrogation, you are forcing new CC = server=20 implementations to support both RADIUS >and Diameter stacks, or force = each=20 session setup to perform two sets of requests/responses or force the = network=20 RADIUS >server to perform Diameter proxy functions --- none of these = options=20 are particularly attractive - it adds complexity, setup >latency and = cost to=20 provide the service.

I never said that we use RADIUS for the = initial=20 interrogation, rather I was referring to the RADIUS model of=20 including

credit control information in the = Access-Request=20 message that is maintained in the Diam CC for the first interrogation = with=20 Diameter AA commands.

DIAMETER/RADIUS interworking is described in = the draft=20 01 (section 2 and section 11), there is also a flow example in the = appendix A.=20 You may want to check this information.

>Imagine how much easier it could be to do = it all in one=20 shot to one functional entity.

The service specific authorization/authentication is specific = to the=20 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=20 approach you propose is to require to the Diam CC to support all = existing and=20 future service specific authorization

and=20 authentication mechanisms and tasks as well as mixing up the command's = semantic=20 because, according to

your=20 proposal, Credit-Control-Request now means network access = authentication=20 and authorization is requested, authorization and authentication = for a=20 mobile node using MIP is requested, credit authorization is requested = etc. etc.=20 Well, it doesn't look so easy and=20 clean....

Regards

Marco

------_=_NextPart_001_01C39FC4.42CFFC08-- From owner-aaa-wg@merit.edu Fri Oct 31 11:39:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06728 for ; Fri, 31 Oct 2003 11:39:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 36072912E6; Fri, 31 Oct 2003 03:23:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03611912E7; Fri, 31 Oct 2003 03:23:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A0E4912E6 for ; Fri, 31 Oct 2003 03:23:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B8725DE7A; Fri, 31 Oct 2003 03:23:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id B95765DE77 for ; Fri, 31 Oct 2003 03:23:47 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9V8NkSs017786; Fri, 31 Oct 2003 09:23:46 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 09:23:52 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Christopher Richards'" Cc: "Harri Hakala (TU/LMF)" , juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, Benni.Alexander@nokia.com, "Patrik Teppo (KA/EAB)" , aaa-wg@merit.edu Subject: FW: [AAA-WG]: Diam CC Quota Triggers Date: Fri, 31 Oct 2003 09:22:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, I agree with you, there are still some things missing in the DCC. However, I think we have different views on the usage of the quota in some places. See more comments inline. Cheers, Leena >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 ] [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. [Chris Richards ] The problem with the current definition is that it forces all events to all quotas for all subscribers to be the same. However, for some subscribers using some quotas, only some events need to be acted upon. E.g. Not all QoS changes for all quotas should need to trigger a mid call re-auth of the quota - it should be on a subscriber, quota and event - basis. [Leena Mattila] I agree with both of you to some extent. I think we need to define a Trigger to allow the server to control what events are significant from credit control point of view but I would not go further than that. That is, the only action for each Trigger would be 'send CCR(update) to CC server'. The CC Server can then decide what action to take, continue as normal, terminate service, redirect etc. Those mechanisms exist already in the DCC, I would not mix the action with the Trigger and complicate things too much. [Leena Mattila] I would also keep the principle that when a CCR(update) is sent then _all_ quotas are reported to the CC server, not only a few of them while keeping the others running in the client, otherwise we create kind of hidden sub-sessions with different quotas in one CC session. If one necessarily wants to report different quotas asynchoronously then sub-sessions should be used for this purpose. [Chris Richards ] The Validity-time has a different usage to the "Idle-Time" trigger I gave as an example. The Validity-time seems to apply to the entire session. However, the quota Idle-time is per-quota. It is a means of ensuring that a subscribers account balance is not all allocated to a session in many quotas when some of the quotas may no longer be needed and the quota can be returned to the subscribers account for use elsewhere. Again, Idle-time is just one example of the many quota-specific triggers -- events that are specific to a particular quota (Granted-Service-Unit). [Leena Mattila] I'd define a basic set of events in the DCC as the Triggers e.g. change of location, QoS change, and leave the rest to be service specific. [MSt] 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? [Chris Richards ] Because it is specific to each quota (Granted-Service-Unit). [Leena Mattila] OK, but as mentioned earlier I'd keep the rule that all quotas should be reported in the CCR(update) whatever and where ever the trigger is. [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" [Chris Richards ] The intention was to define a per-quota cause value. Since each quota (Granted-Service-Unit) is an independent entity, each needs to be able to inform the client why it was or was not successful. Having a single cause at the message (session) level is not fine enough granularity. [Leena Mattila] Why is this granularity needed in the client? [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. [Chris Richards ] For example, subscriber wishes to use some service for which he currently has no Granted-Service-unit. CC Client requests a quota for this use from the server using the Requested-Service-Unit AVP. If the users account is barred from using that service, the server can return a cause indicating "quota declined for session duration" saving the CC client from requesting the same quota again. [Leena Mattila] If one wants to ask separate quota for separate services, still having one credit control session then I think the sub-session mechanism should be used. I don't see big difference between the sub-sessions and the mechanism you propose here. If different quotas should be reported and treated asynchronously then sub-sessions should be used. [Chris Richards ] Also when a Reported-Service-Unit is returned to the CC server, it can indicate what action the server should take based on the cause for return value - "returning idle quota" will instruct the server not to re-authorise this quota. Since more than one quota can now exist in a single CC message, each needs to indicate independently why it is there. [Leena Mattila] I don't see a need for any modifications due to that. The client can report the used units that the service has consumed and if it does not need any more units of this type any more it can request 0 units as Requested-Service-Units. From owner-aaa-wg@merit.edu Fri Oct 31 11:39:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06730 for ; Fri, 31 Oct 2003 11:39:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35341912E4; Fri, 31 Oct 2003 03:01:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85CF4912E5; Fri, 31 Oct 2003 03:01:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 429B9912E4 for ; Fri, 31 Oct 2003 03:01:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id A64D05DE0C; Fri, 31 Oct 2003 03:01:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B25AA5DDB2 for ; Fri, 31 Oct 2003 03:01:15 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9V81BG17902 for ; Fri, 31 Oct 2003 10:01:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Oct 2003 10:01:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 31 Oct 2003 10:01:08 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Oct 2003 10:01:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39F85.23ECB1C0" Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Date: Fri, 31 Oct 2003 10:01:07 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B031D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Thread-Index: AcOfSjTKb4o3NeMBSWusenqZVbyOVQAN+YlQ From: To: , , Cc: , , , , , X-OriginalArrivalTime: 31 Oct 2003 08:01:08.0457 (UTC) FILETIME=[24467590:01C39F85] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C39F85.23ECB1C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Christopher Richards wrote: Credit control really is in both realms - accounting and = authorisation/authentication.=20 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. =20 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. =20 Regards Marco ------_=_NextPart_001_01C39F85.23ECB1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diam CC (AA interrogation in initial CC = request)

Hi,

Christopher Richards wrote:

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

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

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

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

Mark=20 Grayson wrote:

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

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

As a=20 conclusion I wouldn't like to see yet another option, rather I = would stick=20 on the existing RADIUS model for

performing the first interrogation.

Regards

Marco

------_=_NextPart_001_01C39F85.23ECB1C0-- From owner-aaa-wg@merit.edu Fri Oct 31 11:39:26 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06774 for ; Fri, 31 Oct 2003 11:39:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 541969127C; Fri, 31 Oct 2003 04:47:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FC71912E3; Fri, 31 Oct 2003 04:47:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83D709127C for ; Fri, 31 Oct 2003 04:47:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6381A5DE2E; Fri, 31 Oct 2003 04:47:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 96F335DE1B for ; Fri, 31 Oct 2003 04:47:18 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9V9lHB21575 for ; Fri, 31 Oct 2003 11:47:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Oct 2003 11:47:16 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 31 Oct 2003 11:47:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diam CC Quota Triggers Date: Fri, 31 Oct 2003 11:47:15 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0320@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diam CC Quota Triggers Thread-Index: AcOfiIwt3OIwFczoSMatA3l3N+/bfgAAOZmg From: To: , Cc: , , , , , X-OriginalArrivalTime: 31 Oct 2003 09:47:16.0757 (UTC) FILETIME=[F813EC50:01C39F93] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, in my mind all this discussion is tightly coupled with the credit = reservation, that is what the CCA need to control. One single credit reservation maps one-to-one to a credit control = session, what Chris describes seems to assume that you have different credit reservations = per each quotas hiding a sub-session within a session. If quotas are computed = from different reservations, and thus need to be treated independently, then CC = sub-sessions SHOULD be used. And CC sub-sessions are supported in the current draft. More comments in line. Regards Marco > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Leena Mattila (TU/LMF) > Sent: 31 October, 2003 10:23 > To: 'Christopher Richards' > Cc: Harri Hakala (TU/LMF); Koskinen Juha-Pekka (NET/Tampere); Loughney > John (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo > (KA/EAB); aaa-wg@merit.edu > Subject: FW: [AAA-WG]: Diam CC Quota Triggers >=20 >=20 > Hi Chris, >=20 > I agree with you, there are still some things missing in the DCC. > However, I think we have different views on the usage of the quota > in some places. See more comments inline. >=20 > Cheers, > Leena >=20 > >Some trigger/actions require a trigger value. For example, the > >"Idle quota" trigger, may have an action of "return quota"=20 > >and a trigger value of "600 seconds". In other words, if this quota > >has not been used for 600 seconds, return it to the=20 > >Diameter CC server. > > > >Trigger ::=3D < AVP Header: TBD >=20 > > { Trigger-Id }=20 > > { Trigger-Action }=20 > > [ Trigger-Value ]=20 > > Granted-Service-Unit ::=3D < AVP Header: TBD >=20 > > { Cause-Id }=20 > > [ CC-Time ]=20 > > [ CC-Money ]=20 > > [ CC-Total-Octets ]=20 > > [ CC-Input-Octets ]=20 > > [ CC-Output-Octets ]=20 > > [ CC-Service-Specific-Units ]=20 > > *[ Service-Identifier ]=20 > > [ Rating-Group ]=20 > > *[ Trigger ]=20 >=20 > [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. >=20 > [Chris Richards ] The problem with the current definition is that it > forces all events to all quotas for all subscribers to be the same. > However, for some subscribers using some quotas, only some events need > to be acted upon. E.g. Not all QoS changes for all quotas should need > to trigger a mid call re-auth of the quota - it should be on=20 > a subscriber, > quota and event - basis. >=20 > [Leena Mattila] I agree with both of you to some extent. I think we > need to define a Trigger to allow the server to control what events > are significant from credit control point of view but I would not go > further than that. That is, the only action for each Trigger would > be 'send CCR(update) to CC server'. The CC Server can then decide what > action to take, continue as normal, terminate service, redirect etc. > Those mechanisms exist already in the DCC, I would not mix the action > with the Trigger and complicate things too much. >=20 [MSt]: to define a server controllable triggers is what I meant. The = triggers action is always "credit re-authorization" means that CCR[Update] to the = CC server is to be sent. > [Leena Mattila] I would also keep the principle that when a=20 > CCR(update) > is sent then _all_ quotas are reported to the CC server, not=20 > only a few > of them while keeping the others running in the client, otherwise we > create kind of hidden sub-sessions with different quotas in=20 > one CC session. > If one necessarily wants to report different quotas asynchoronously > then sub-sessions should be used for this purpose.=20 [MSt]: Agree. >=20 > [Chris Richards ] The Validity-time has a different usage to=20 > the "Idle-Time" > trigger I gave as an example. The Validity-time seems to apply to the=20 > entire session. However, the quota Idle-time is per-quota. It=20 > is a means > of ensuring that a subscribers account balance is not all=20 > allocated to a > session in many quotas when some of the quotas may no longer be needed > and the quota can be returned to the subscribers account for=20 > use elsewhere. > Again, Idle-time is just one example of the many=20 > quota-specific triggers > -- events that are specific to a particular quota=20 > (Granted-Service-Unit). >=20 > [Leena Mattila] I'd define a basic set of events in the DCC=20 > as the Triggers > e.g. change of location, QoS change, and leave the rest to be service > specific.=20 >=20 > [MSt] Why not to defne the Trigger AVP (maybe > in somewhat simpler format) in the CCA message level instead=20 > of embedding > that in the GSU AVP? > [Chris Richards ] Because it is specific to each quota=20 > (Granted-Service-Unit). >=20 > [Leena Mattila] OK, but as mentioned earlier I'd keep the=20 > rule that all > quotas should be reported in the CCR(update) whatever and=20 > where ever the trigger is. >=20 [MSt]: OK Leena, but the trigger should be then at the command level. Keeping the rule that a credit re-authorization is performed (i.e. all quotas are reported), it doesn't require for triggers at the G-S-U level. > [MSt]: I think diameter result codes should be used instead=20 > of tailored > cause-id avp. There are few cases why the client would=20 > perform credit > re-authorization, but the reason is always "credit re-authorization" > > [Chris Richards ] The intention was to define a per-quota cause value. > Since each quota (Granted-Service-Unit) is an independent entity, each > needs to be able to inform the client why it was or was not=20 > successful. > Having a single cause at the message (session) level is not=20 > fine enough > granularity. >=20 [MSt]: if the one single credit reservation is done for the CC session, = each quota is not an independent entity as such. If you see quotas as = independent entities, then you need one credit reservation for each quota and you = should use sub-sessions. > [Leena Mattila] Why is this granularity needed in the client? >=20 > [MSt]: If the client terminates the end-user service and the=20 > CC session, > it would include the Termination-Cause AVP indicating the =20 > 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. > [Chris Richards ] For example, subscriber wishes to use some service > for which he currently has no Granted-Service-unit. CC Client > requests a quota for this use from the server using the > Requested-Service-Unit AVP. If the users account is barred from > using that service, the server can return a cause indicating "quota > declined for session duration" saving the CC client from requesting > the same quota again. [MSt]: the assumption is that the services a user is allowed for are = provisioned by another entity than the CC server. If a given service is barred for a = given user, the Service-Identifier pointing to that service won't be = provisioned=20 to the Service Element. The CC client won't send any request for that = service, simply would deny the user's service request. > [Leena Mattila] If one wants to ask separate quota for separate > services, still having one credit control session then I think > the sub-session mechanism should be used. I don't see big difference > between the sub-sessions and the mechanism you propose here. > If different quotas should be reported and treated asynchronously > then sub-sessions should be used.=20 >=20 > [Chris Richards ] Also when a Reported-Service-Unit is=20 > returned to the CC server, > it can indicate what action the server should take based on the > cause for return value - "returning idle quota" will instruct the=20 > server not to re-authorise this quota. Since more than one quota can > now exist in a single CC message, each needs to indicate independently > why it is there. > [Leena Mattila] I don't see a need for any modifications due to that. > The client can report the used units that the service has consumed > and if it does not need any more units of this type any more it can > request 0 units as Requested-Service-Units. >=20 [MSt]: I don't see need for modification either. What you, Leena, = describe is one of the supported option (client driven). Another option is to = report 0 used-units for a service that didn't consume any and let the server=20 decide what to do (server driven). Both are supported.