Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

From: "Christopher Richards" <[email-masked]>
Date: Thu, 6 Nov 2003 11:57:19 -0600

Hi Marco,

Thanks for the email. We're making excellent progress. I added my responses
below.

Cheers,
Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 11:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Diam CC re-authorization triggers

Hi Chris,

after the debate on your proposal whether triggers should be per G-S-U or
per CC command, as stated in a previous mail, I changed mindset and I see
now some value in defining those triggers per G-S-U.

I agree on adding triggers associated to each G-S-U but in somewhat simpler
form, I would propose some changes to your initial proposal in order to
integrate this new functionality seamlessly and consistently with all the
functionalities already defined in the draft 01.

The server may include one or more CC-Re-Auth-Triggers associated to the
G-S-U as in your proposal. Whenever one trigger event occurs the client
sends a CCR[Update]. The CCR[Update] includes as many U-S-U as many G-S-U
were received in a previous CCA command (i.e. all the quotas 
are reported to the server).

[Chris Richards]
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you
agreed above, it only makes sense to include the U-S-U associated to that
G-S-U which was triggered. Triggers are specific to the G-S-U in which they
are in. If all the G-S-U must send a U-S-U when any trigger event is
reached, it breaks the association - and effectively makes the trigger
session specific - not G-S-U specific.

Also note that the triggers do not have to cause a CCR[Update]. It may be
that an event causes the CC client to perform some other action that does
not immediately lead to a CCR[Update] for the G-S-U.
[End Chris Richards]

Taking into account the tariff changes the G-S-U would be

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

CC-Re-Auth-Trigger ::= < AVP Header: TBD > 
                       { Trigger-Id } 
                       [ Trigger-Value ]

[Chris Richards]
As well as a Trigger-Id and Trigger-Value, there seems to be a need for an
(optional) Trigger-Action since it m ay be that the CC Client might not
always need to re-auth for the trigger. For example, it may be to Unblock
the usage of a temporarily blocked G-S-U after a defined time period (Just
thinking aloud). The point is that the protocol should have the flexibility
for this. So, I propose:-

CC-Re-Auth-Trigger ::= < AVP Header: TBD > 
                       { Trigger-Id } 
                       [ Trigger-Value ]
                       [ Trigger-Action]

And start defining a set of basic actions. The first of which is:
Re-auth U-S-U (send a re-auth for a new quota for G-S-U)
Block usage of G-S-U and do not report.
....others TBD

With this we have the flexibility to enhance the triggers for future
requirements without changing the AVP.
[End Chris Richards]

The Trigger-Id (Enumerated) may be QoS-Change, Location-Change,
Idle-Timeout, Service-Specific etc. but we need to define them to enable
interoperability.

The Trigger-Value (UTF8String) defines the value of the trigger and we need
to define some of these as well for the same reason. 
For instance the value for QoS-Change may be bit rate or traffic class
or.....? the value for Location-Change may be cell change or LA change or
Foreign Agent change or....? But Service-Specific is really dependent on the
service in question (e.g for a certain game service-specific may be "game
level change", for another game service-specific may be "100 points" etc.).
So, we perhaps don't need to define the values for Service-Specific
trigger-id. 

In addition a CC-Re-Auth-Reason AVP (Grouped)  is included in the CCR to
indicate the cause for 
performing the credit re-authorization, and this is needed not only for the
triggers.

CC-Re-Auth-Reason :: < AVP Header: TBD >
                     { Reason-Code }
                     [ CC-Re-Auth-Trigger ]
                     [ Service-Identifier ]
                     [ Rating-Group ]

The Reason-Code (enumerated) indicates why the CCR[Update] has been sent,
may be

- Validity-Time expired
- quota limit reached
- Server initiated credit re-authorization (RAR received)
- client-driven update (i.e. the one known in draft-01 as 
 'spontaneous update')
- CC-Re-Auth-Trigger occured
- Final quota limit reached and GST started

If the Reason-Code is set to CC-Re-Auth-Trigger occured the
CC-Re-Auth-Trigger AVP is included to indicate what is the trigger that
caused the CCR[Update].

If multiple quotas were given, the Service-Identifier or Rating-Group AVP is
included to indicate what is the service or rating-group that caused the
CCR[Update].

[Chris Richards]
Thank you for including the Reason-Code. However, should it not be part of
the U-S-U to keep the association between the U-S-U. This way, all that is
needed is the Reason-Code itself since the other fields are already present
in the U-S-U.

It will also make implementations easier because the Reason is parsed at the
same time as the U-S-U - instead of separately in another part of the
message.
[End Chris Richards]

I believe this way we enable triggers per G-S-U according to your proposal
and in a form consistent with 
all the functionalities defined in the draft 01.

I hope we can all agree on this so that you can formulate the issue. 

Regards
Marco

---

From: <[email-masked]>
Date: Fri, 7 Nov 2003 14:02:03 +0200

[Chris Richards] 
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you agreed above, it only makes sense to include the U-S-U associated to that G-S-U which was triggered. Triggers are specific to the G-S-U in which they are in. If all the G-S-U must send a U-S-U when any trigger event is reached, it breaks the association - and effectively makes the trigger session specific - not G-S-U specific.

[Marco St.] 
Chris, the drawback of what you describe above is that it add a lot of complexity to the protocol and it is not consistent with the DCC functionalities. I already explained in some other mail that if you want to treat the G-S-U as independent entities you need one credit reservation for each of the G-S-U, thus you need CC sub-sessions and you already have this flexibility. If the G-S-Us are derived from the same credit reservation you cannot, and you must not, leave portion of the same reservation running in the client while another portion is reported to the server.  What you propose is breaking the DCC principles, the way I defined the CC-Re-Auth-Triggers are not session specific but service (or rating-group) specific and it doesn't break this association. What the client does is to initiate credit re-authorization when a defined trigger event for a specific service occurs (not when a session event occurs). The server gets granular information about the service (or rating group) and the trigger that caused the CCR, based on that it can make whatever decision about the service in question and it can manipulate the credit reservation accordingly, but it cannot work properly on the credit reservation if some portion of the reservation is still running in the client. Please note the structure of the reason code,  it just confirms the granularity I described.

[Chris Richards] 
Also note that the triggers do not have to cause a CCR[Update]. It may be that an event causes the CC client to perform some other action that does not immediately lead to a CCR[Update] for the G-S-U.

 [Chris Richards] 
As well as a Trigger-Id and Trigger-Value, there seems to be a need for an (optional) Trigger-Action since it m ay be that the CC Client might not always need to re-auth for the trigger. For example, it may be to Unblock the usage of a temporarily blocked G-S-U after a defined time period (Just thinking aloud). The point is that the protocol should have the flexibility for this. So, I propose:-
 
[Marco St.] 
The DCC is a credit control protocol, it only need to be concerned with triggers that affect the rating of the service and thus require a credit re-authorization to be performed. Whenever those triggers occur the action is always credit re-authorization, as I explained in some other mail as well, because this is why we have a credit control protocol. Other type of triggers, not rating related, and associated actions fall within a different category than credit control and need to be defined by other means, those means are not in the scope of this architecture and specification. For instance, we assume that service-identifiers and associated service description (whatever the service description is e.g. IP Filters) are provisioned by another entity (e.g. AAA server or a sort of Charging Policy server), this entity may also define associated triggers that cause some other action than credit re-authorization.
 
[Chris Richards] 
Thank you for including the Reason-Code. However, should it not be part of the U-S-U to keep the association between the U-S-U. This way, all that is needed is the Reason-Code itself since the other fields are already present in the U-S-U.

It will also make implementations easier because the Reason is parsed at the same time as the U-S-U - instead of separately in another part of the message.

[Marco St.] 
As you may have noticed, the CC-Re-Auth-Reason is needed also when multiple services in one CC session are not used at all and for events that are session specific (e.g. RAR received or Validity-Time expired). When multiple services in one CC session are used and a service specific trigger is causing the credit re-authorization, the structure of the CC-Re-Auth-Reason AVP enables for finer granularity than just session (as previously discussed). 
 
When the CC server receives a CCR message it need to parse all the parts of the message anyway.
 
Chris, I try now to draw some conclusion out of this discussion and how I see the way to proceed. 
We need capabilities to define credit re-authorization triggers on a per service (or rating group) basis, those triggers are events that affect the rating (cost) of the service other type of triggers and actions are not in the scope of this specification. Since the DCC is a general solution to the real-time cost and credit control,  multiple services in one CC session is just one part of it,  I have been striking a balance between your proposal and the DCC principles hoping to create something which would be relevant to the whole. Perhaps we may improve in some details but I really believe that the principle I described fits seamlessly and consistently, it also satisfies the requirements without adding too much complexity. I would then go ahead with this proposal, that has your proposal as solid base, and start to define what are these Trigger-Ids and their values.
 
Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]
Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Marco, 

Thanks for the email. We're making excellent progress. I added my responses below. 

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Chris, 

after the debate on your proposal whether triggers should be per G-S-U or per CC command, as stated in a previous mail, I changed mindset and I see now some value in defining those triggers per G-S-U.

I agree on adding triggers associated to each G-S-U but in somewhat simpler form, I would propose some changes to your initial proposal in order to integrate this new functionality seamlessly and consistently with all the functionalities already defined in the draft 01.

The server may include one or more CC-Re-Auth-Triggers associated to the G-S-U as in your proposal. Whenever one trigger event occurs the client sends a CCR[Update]. The CCR[Update] includes as many U-S-U as many G-S-U were received in a previous CCA command (i.e. all the quotas 

[Chris Richards] 
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you agreed above, it only makes sense to include the U-S-U associated to that G-S-U which was triggered. Triggers are specific to the G-S-U in which they are in. If all the G-S-U must send a U-S-U when any trigger event is reached, it breaks the association - and effectively makes the trigger session specific - not G-S-U specific.

Also note that the triggers do not have to cause a CCR[Update]. It may be that an event causes the CC client to perform some other action that does not immediately lead to a CCR[Update] for the G-S-U.

[End Chris Richards] 

[Chris Richards] 
As well as a Trigger-Id and Trigger-Value, there seems to be a need for an (optional) Trigger-Action since it m ay be that the CC Client might not always need to re-auth for the trigger. For example, it may be to Unblock the usage of a temporarily blocked G-S-U after a defined time period (Just thinking aloud). The point is that the protocol should have the flexibility for this. So, I propose:-

With this we have the flexibility to enhance the triggers for future requirements without changing the AVP. 
[End Chris Richards] 

The Trigger-Id (Enumerated) may be QoS-Change, Location-Change, Idle-Timeout, Service-Specific etc. but we need to define them to enable interoperability.

The Trigger-Value (UTF8String) defines the value of the trigger and we need to define some of these as well for the same reason. 

For instance the value for QoS-Change may be bit rate or traffic class or.....? the value for Location-Change may be cell change or LA change or Foreign Agent change or....? But Service-Specific is really dependent on the service in question (e.g for a certain game service-specific may be "game level change", for another game service-specific may be "100 points" etc.). So, we perhaps don't need to define the values for Service-Specific trigger-id. 

In addition a CC-Re-Auth-Reason AVP (Grouped)  is included in the CCR to indicate the cause for 
performing the credit re-authorization, and this is needed not only for the triggers. 

The Reason-Code (enumerated) indicates why the CCR[Update] has been sent, may be 

- Validity-Time expired 
- quota limit reached 

If the Reason-Code is set to CC-Re-Auth-Trigger occured the CC-Re-Auth-Trigger AVP is included to indicate what is the trigger that caused the CCR[Update].

If multiple quotas were given, the Service-Identifier or Rating-Group AVP is included to indicate what is the service or rating-group that caused the CCR[Update].

[Chris Richards] 
Thank you for including the Reason-Code. However, should it not be part of the U-S-U to keep the association between the U-S-U. This way, all that is needed is the Reason-Code itself since the other fields are already present in the U-S-U.

It will also make implementations easier because the Reason is parsed at the same time as the U-S-U - instead of separately in another part of the message.

[End Chris Richards] 

I believe this way we enable triggers per G-S-U according to your proposal and in a form consistent with 
all the functionalities defined in the draft 01. 

Regards 
Marco

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 10 Nov 2003 09:01:06 +0100

Hi Chris, Marco,
 
I agree with Marco regarding how to treat multiple services. The reason for Issue 436 was to combine a credit reservation for several services (tariff groups) into one, and treat it as one reservation. We should not start splitting this up into several independent reservations, thus creating a competing mechanism for sub-sessions and violating the principles in the base. I'd like to keep the application as simple as possible, without too many options because too much flexibility causes tricky and error-prone design. 
 
BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 7. marraskuuta 2003 14:02
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB); [email-masked]
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

[Chris Richards] 

[Marco St.] 
Chris, the drawback of what you describe above is that it add a lot of complexity to the protocol and it is not consistent with the DCC functionalities. I already explained in some other mail that if you want to treat the G-S-U as independent entities you need one credit reservation for each of the G-S-U, thus you need CC sub-sessions and you already have this flexibility. If the G-S-Us are derived from the same credit reservation you cannot, and you must not, leave portion of the same reservation running in the client while another portion is reported to the server.  What you propose is breaking the DCC principles, the way I defined the CC-Re-Auth-Triggers are not session specific but service (or rating-group) specific and it doesn't break this association. What the client does is to initiate credit re-authorization when a defined trigger event for a specific service occurs (not when a session event occurs). The server gets granular information about the service (or rating !
 group) and the trigger that caused the CCR, based on that it can make whatever decision about the service in question and it can manipulate the credit reservation accordingly, but it cannot work properly on the credit reservation if some portion of the reservation is still running in the client. Please note the structure of the reason code,  it just confirms the granularity I described.

[Chris Richards] 

 [Chris Richards] 
 
[Marco St.] 
 
[Chris Richards] 

[Marco St.] 

 
Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]
Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Marco, 

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Chris, 

[Chris Richards] 

[End Chris Richards] 

[Chris Richards] 

- Validity-Time expired 
- quota limit reached 

[Chris Richards] 

[End Chris Richards] 

Regards 
Marco

---

From: <[email-masked]>
Date: Mon, 10 Nov 2003 12:08:57 +0200

Hi Chris, Leena;
 
[Leena Mat.]
 
[Marco St.]
If we agree to include CC-Re-Auth-Triggers per service or rating-group and we allow multiple triggers per G-S-U, I'm wondering if we could lead in to situations where
more than one triggers are met at the same time. If such an event occurs what the client should do then? Should we define triggers priority or the client simply reports all the triggers that occured concurrently in the CCR[Update]?
 
If we want to report all the triggers, the CC-Re-Auth-Reason AVP structure I proposed it may not be good enough. Perhaps it could be something like this?
 
CC-Re-Auth-Reason :: < AVP Header: TBD > 
                     { Reason-Code } 
                   *[ CC-Re-Auth-Trigger-Event ] 
                     
CC-Re-Auth-Trigger-Event :: < AVP Header: TBD >
                     { CC-Re-Auth-Trigger }
                     [ Service-Identifier ] 
                     [ Rating-Group ] 
 
Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Leena Mattila (TU/LMF)
Sent: 10 November, 2003 10:01
To: [email-masked]'; Stura Marco (NET/Helsinki)
Cc: Harri Hakala (TU/LMF); Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo (KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Marco,

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 7. marraskuuta 2003 14:02
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB); [email-masked]
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

[Chris Richards] 

[Marco St.] 

[Chris Richards] 

 [Chris Richards] 
 
[Marco St.] 
 
[Chris Richards] 

[Marco St.] 

 
Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]
Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Marco, 

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Chris, 

[Chris Richards] 

[End Chris Richards] 

[Chris Richards] 

- Validity-Time expired 
- quota limit reached 

[Chris Richards] 

[End Chris Richards] 

Regards 
Marco

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 10 Nov 2003 12:02:53 +0100

Hi Marco,
 
I think defining prioties between different triggers is  rather hard . Either the client reports the first event that causes the CCR to be sent, or then it lists them all. I'd prefer the first the option - this would follow the principles of how usually also errors are reported: even though multiple errors could be detected, only the first that is  encountered is reported.
BTW, if the second option is chosen (i.e. report them all) wouldn't it be possible that the Reason-Code would need to be repeated as well? It could happen that at the very same moment the validity-time expires, the quota limit is reached and the end-user changes location causing a QoS Change.... In that cases three Reason-Codes would be needed and two trigger-events. I'd in that case repeat the whole CC-Re-Auth-Reason in the CCR without introducing the CC-Re-Auth-Trigger-Event sub-structure.
 
BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10. marraskuuta 2003 12:09
To: Leena Mattila (TU/LMF); [email-masked]
Cc: Harri Hakala (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB); [email-masked]
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Leena;
 
[Leena Mat.]
 
[Marco St.]

                     
 
Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Leena Mattila (TU/LMF)
Sent: 10 November, 2003 10:01
To: [email-masked]'; Stura Marco (NET/Helsinki)
Cc: Harri Hakala (TU/LMF); Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo (KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Marco,

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 7. marraskuuta 2003 14:02
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB); [email-masked]
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

[Chris Richards] 

[Marco St.] 

[Chris Richards] 

 [Chris Richards] 
 
[Marco St.] 
 
[Chris Richards] 

[Marco St.] 

 
Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]
Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Marco, 

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Chris, 

[Chris Richards] 

[End Chris Richards] 

[Chris Richards] 

- Validity-Time expired 
- quota limit reached 

[Chris Richards] 

[End Chris Richards] 

Regards 
Marco

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 10 Nov 2003 11:40:59 +0100

Hi Chris, Marco & Leena,

>We need capabilities to define credit re-authorization triggers on
>a per service (or rating group) basis, those triggers are events 
>that affect the rating (cost) of the service other type of triggers 
>and actions are not in the scope of this specification. Since the DCC 
>is a general solution to the real-time cost and credit control,  multiple
>services in one CC session is just one part of it, I have been striking 
>a balance between your proposal and the DCC principles hoping to create
>something which would be relevant to the whole. Perhaps we may improve in 
>some details but I really believe that the principle I described fits 
>seamlessly and consistently, it also satisfies the requirements without
>adding too much complexity. I would then go ahead with this proposal, 
>that has your proposal as solid base, and start to define what are these 
>Trigger-Ids and their values.

I think that Marco and Leena have provided very well justified answers
why we should not spilt multiple service requests up into several 
independent reservations. If different quotas are wanted to be reported 
independently then sub-sessions should be used for that purpose. 

The Trigger-Actions shall only cause action credit re-authorization, i.e.
send a CCR[update] to server. It is then up to the server to decide further
actions: continue as normally or if the user's account runs out of money, the
server can terminate service or provide graceful service termination feature
as described in the cca-01, section 5.5 Graceful Service Termination.
Other actions than credit authorization are not in scope of credit control specification
and shall not be defined in the cca draft.

I also agree with Marco that it is reasonable to go ahead with the proposal below,
and start to define Trigger-Ids and their values.

regards.........Harri

-----Original Message-----
From: Leena Mattila (TU/LMF) 
Sent: 10. marraskuuta 2003 10:01
To: [email-masked]'; [email-masked]'
Cc: Harri Hakala (TU/LMF); [email-masked]'; [email-masked]'; [email-masked]'; Patrik Teppo (KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Marco,

BR,
Leena
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 7. marraskuuta 2003 14:02
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB); [email-masked]
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

[Chris Richards] 

[Chris Richards] 

 [Chris Richards] 

[Marco St.] 

[Chris Richards] 

Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]
Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Marco, 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Diam CC re-authorization triggers 

Hi Chris,

---

From: <[email-masked]>
Date: Mon, 10 Nov 2003 13:36:08 +0200

Hi,
 
[Leena Matt.]
Either the client reports the first event that causes the CCR to be sent, or then it lists them all. I'd prefer the first the option - this would follow the principles of how usually also errors are reported: even though multiple errors could be detected, only the first that is  encountered is reported.
 
[Marco St.]
I'm happy with the first option.
 
[Leena Matt.]
 
[Marco St.]
I think you are right Leena, it'd probably better to include multiple instances of the CC-Re-Auth-Reason AVP.
 
If Chris is of the same opinion to follow the principles of how usually errors are reported, I think we can then go with the single CC-Re-Auth-Reason AVP.

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 10 Nov 2003 05:55:54 -0600

Hi Harri, Leena, Marco,

Thanks for the responses over the weekend.

I think that without this ability, we'll severely limit the usefulness of
the Diam CC protocol. As it is, the protocol is very restricted. I think we
need to make it a bit more future proof. Otherwise, it will only solve
existing requirements and not address any of the new requirements for IP
flow charging, event charging, pre- post-paid integration, WLAN convergence
with 3GPP & 3GPP2, etc. And if we limit ourselves to solving existing
requirements only - then it would be better to stick with an existing
application - like RADIUS and not bother with Diam at all.

As for using sub-sessions, for 3GPP, isn't the intention of these to be used
for secondary PDP contexts? Using sub-sessions for the same user session
actually adds overhead - not just the additional transport overhead but also
the additional separate state maintenance that needs to be maintained for
what are logically linked entities.

From the transport efficiency, think of mass events that may happen (e.g. a
node outage causing all active sessions to be closed gracefully). Now if
each user has to send multiple messages and there are many millions of users
active, the overhead on the network, client and server becomes the
bottleneck. 

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, November 10, 2003 4:41 AM
To: Leena Mattila (TU/LMF); Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; Patrik Teppo (KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Marco & Leena,

>[Marco St.]
>Chris, I try now to draw some conclusion out of this discussion and how 
>I see the way to proceed. We need capabilities to define credit 
>re-authorization triggers on a per service (or rating group) basis, 
>those triggers are events that affect the rating (cost) of the service 
>other type of triggers and actions are not in the scope of this 
>specification. Since the DCC is a general solution to the real-time 
>cost and credit control,  multiple services in one CC session is just 
>one part of it, I have been striking a balance between your proposal 
>and the DCC principles hoping to create something which would be 
>relevant to the whole. Perhaps we may improve in some details but I 
>really believe that the principle I described fits seamlessly and 
>consistently, it also satisfies the requirements without adding too 
>much complexity. I would then go ahead with this proposal, that has 
>your proposal as solid base, and start to define what are these 

I think that Marco and Leena have provided very well justified answers why
we should not spilt multiple service requests up into several 
independent reservations. If different quotas are wanted to be reported 
independently then sub-sessions should be used for that purpose. 

The Trigger-Actions shall only cause action credit re-authorization, i.e.
send a CCR[update] to server. It is then up to the server to decide further
actions: continue as normally or if the user's account runs out of money,
the server can terminate service or provide graceful service termination
feature as described in the cca-01, section 5.5 Graceful Service
Termination. Other actions than credit authorization are not in scope of
credit control specification and shall not be defined in the cca draft.

I also agree with Marco that it is reasonable to go ahead with the proposal
below, and start to define Trigger-Ids and their values.

regards.........Harri

-----Original Message-----
From: Leena Mattila (TU/LMF) 
Sent: 10. marraskuuta 2003 10:01
To: [email-masked]'; [email-masked]'
Cc: Harri Hakala (TU/LMF); [email-masked]';
[email-masked]'; [email-masked]'; Patrik Teppo
(KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Marco,

I agree with Marco regarding how to treat multiple services. The reason for
Issue 436 was to combine a credit reservation for several services (tariff
groups) into one, and treat it as one reservation. We should not start
splitting this up into several independent reservations, thus creating a
competing mechanism for sub-sessions and violating the principles in the
base. I'd like to keep the application as simple as possible, without too
many options because too much flexibility causes tricky and error-prone
design. 

BR,
Leena
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 7. marraskuuta 2003 14:02
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF);
[email-masked]; [email-masked];
[email-masked]; Patrik Teppo (KA/EAB); [email-masked]
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

[Chris Richards] 
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you
agreed above, it only makes sense to include the U-S-U associated to that
G-S-U which was triggered. Triggers are specific to the G-S-U in which they
are in. If all the G-S-U must send a U-S-U when any trigger event is
reached, it breaks the association - and effectively makes the trigger
session specific - not G-S-U specific. [Marco St.] 
Chris, the drawback of what you describe above is that it add a lot of
complexity to the protocol and it is not consistent with the DCC
functionalities. I already explained in some other mail that if you want to
treat the G-S-U as independent entities you need one credit reservation for
each of the G-S-U, thus you need CC sub-sessions and you already have this
flexibility. If the G-S-Us are derived from the same credit reservation you
cannot, and you must not, leave portion of the same reservation running in
the client while another portion is reported to the server.  What you
propose is breaking the DCC principles, the way I defined the
CC-Re-Auth-Triggers are not session specific but service (or rating-group)
specific and it doesn't break this association. What the client does is to
initiate credit re-authorization when a defined trigger event for a specific
service occurs (not when a session event occurs). The server gets granular
information about the service (or rating !
 group) and the trigger that caused the CCR, based on that it can make
whatever decision about the service in question and it can manipulate the
credit reservation accordingly, but it cannot work properly on the credit
reservation if some portion of the reservation is still running in the
client. Please note the structure of the reason code,  it just confirms the
granularity I described.

[Chris Richards] 

 [Chris Richards] 

[Marco St.] 
The DCC is a credit control protocol, it only need to be concerned with
triggers that affect the rating of the service and thus require a credit
re-authorization to be performed. Whenever those triggers occur the action
is always credit re-authorization, as I explained in some other mail as
well, because this is why we have a credit control protocol. Other type of
triggers, not rating related, and associated actions fall within a different
category than credit control and need to be defined by other means, those
means are not in the scope of this architecture and specification. For
instance, we assume that service-identifiers and associated service
description (whatever the service description is e.g. IP Filters) are
provisioned by another entity (e.g. AAA server or a sort of Charging Policy
server), this entity may also define associated triggers that cause some
other action than credit re-authorization.

[Chris Richards] 
Thank you for including the Reason-Code. However, should it not be part of
the U-S-U to keep the association between the U-S-U. This way, all that is
needed is the Reason-Code itself since the other fields are already present
in the U-S-U. It will also make implementations easier because the Reason is
parsed at the same time as the U-S-U - instead of separately in another part
of the message. [Marco St.] 
As you may have noticed, the CC-Re-Auth-Reason is needed also when multiple
services in one CC session are not used at all and for events that are
session specific (e.g. RAR received or Validity-Time expired). When multiple
services in one CC session are used and a service specific trigger is
causing the credit re-authorization, the structure of the CC-Re-Auth-Reason
AVP enables for finer granularity than just session (as previously
discussed). 

When the CC server receives a CCR message it need to parse all the parts of
the message anyway.

Chris, I try now to draw some conclusion out of this discussion and how I
see the way to proceed. 
We need capabilities to define credit re-authorization triggers on a per
service (or rating group) basis, those triggers are events that affect the
rating (cost) of the service other type of triggers and actions are not in
the scope of this specification. Since the DCC is a general solution to the
real-time cost and credit control,  multiple services in one CC session is
just one part of it,  I have been striking a balance between your proposal
and the DCC principles hoping to create something which would be relevant to
the whole. Perhaps we may improve in some details but I really believe that
the principle I described fits seamlessly and consistently, it also
satisfies the requirements without adding too much complexity. I would then
go ahead with this proposal, that has your proposal as solid base, and start
to define what are these Trigger-Ids and their values.

Regards
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen
Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni
(NET/Helsinki); [email-masked]; [email-masked]
Subject: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Marco, 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked];

Hi Chris, 
after the debate on your proposal whether triggers should be per G-S-U or
per CC command, as stated in a previous mail, I changed mindset and I see
now some value in defining those triggers per G-S-U. I agree on adding
triggers associated to each G-S-U but in somewhat simpler form, I would
propose some changes to your initial proposal in order to integrate this new
functionality seamlessly and consistently with all the functionalities
already defined in the draft 01. The server may include one or more
CC-Re-Auth-Triggers associated to the G-S-U as in your proposal. Whenever
one trigger event occurs the client sends a CCR[Update]. The CCR[Update]
includes as many U-S-U as many G-S-U were received in a previous CCA command
(i.e. all the quotas 
are reported to the server). 
[Chris Richards] 
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you
agreed above, it only makes sense to include the U-S-U associated to that
G-S-U which was triggered. Triggers are specific to the G-S-U in which they
are in. If all the G-S-U must send a U-S-U when any trigger event is
reached, it breaks the association - and effectively makes the trigger
session specific - not G-S-U specific. Also note that the triggers do not
have to cause a CCR[Update]. It may be that an event causes the CC client to
perform some other action that does not immediately lead to a CCR[Update]
for the G-S-U. [End Chris Richards] 
Taking into account the tariff changes the G-S-U would be 
Granted-Service-Unit ::= < AVP Header: 431 > 
                         [ Tariff-Time-Change ] 
                        *[CC-Re-Auth-Trigger ] 
                         [ CC-Time ] 
                         [ CC-Money ] 
                         [ CC-Total-Octets ] 
                         [ CC-Input-Octets ] 
                         [ CC-Output-Octets ] 
                         [ CC-Service-Specific-Units ] 
                        *[ Service-Identifier ] 
                         [ Rating-Group ] 
CC-Re-Auth-Trigger ::= < AVP Header: TBD > 
                       { Trigger-Id } 
                       [ Trigger-Value ] 
[Chris Richards] 
As well as a Trigger-Id and Trigger-Value, there seems to be a need for an
(optional) Trigger-Action since it m ay be that the CC Client might not
always need to re-auth for the trigger. For example, it may be to Unblock
the usage of a temporarily blocked G-S-U after a defined time period (Just
thinking aloud). The point is that the protocol should have the flexibility
for this. So, I propose:- CC-Re-Auth-Trigger ::= < AVP Header: TBD > 
                       { Trigger-Id } 
                       [ Trigger-Value ] 
                       [ Trigger-Action] 
And start defining a set of basic actions. The first of which is: 
Re-auth U-S-U (send a re-auth for a new quota for G-S-U) 
Block usage of G-S-U and do not report. 
....others TBD 
With this we have the flexibility to enhance the triggers for future
requirements without changing the AVP. 
[End Chris Richards] 
The Trigger-Id (Enumerated) may be QoS-Change, Location-Change,
Idle-Timeout, Service-Specific etc. but we need to define them to enable
interoperability. The Trigger-Value (UTF8String) defines the value of the
trigger and we need to define some of these as well for the same reason. 
For instance the value for QoS-Change may be bit rate or traffic class
or.....? the value for Location-Change may be cell change or LA change or
Foreign Agent change or....? But Service-Specific is really dependent on the
service in question (e.g for a certain game service-specific may be "game
level change", for another game service-specific may be "100 points" etc.).
So, we perhaps don't need to define the values for Service-Specific
trigger-id. 
In addition a CC-Re-Auth-Reason AVP (Grouped)  is included in the CCR to
indicate the cause for 
performing the credit re-authorization, and this is needed not only for the
triggers. 
CC-Re-Auth-Reason :: < AVP Header: TBD > 
                     { Reason-Code } 
                     [ CC-Re-Auth-Trigger ] 
                     [ Service-Identifier ] 
                     [ Rating-Group ] 
The Reason-Code (enumerated) indicates why the CCR[Update] has been sent,
may be 
- Validity-Time expired 
- quota limit reached 
- Server initiated credit re-authorization (RAR received) 
- client-driven update (i.e. the one known in draft-01 as 
 'spontaneous update') 
- CC-Re-Auth-Trigger occured 
- Final quota limit reached and GST started 
If the Reason-Code is set to CC-Re-Auth-Trigger occured the
CC-Re-Auth-Trigger AVP is included to indicate what is the trigger that
caused the CCR[Update]. If multiple quotas were given, the
Service-Identifier or Rating-Group AVP is included to indicate what is the
service or rating-group that caused the CCR[Update]. [Chris Richards] 
Thank you for including the Reason-Code. However, should it not be part of
the U-S-U to keep the association between the U-S-U. This way, all that is
needed is the Reason-Code itself since the other fields are already present
in the U-S-U. It will also make implementations easier because the Reason is
parsed at the same time as the U-S-U - instead of separately in another part
of the message. [End Chris Richards] 
I believe this way we enable triggers per G-S-U according to your proposal
and in a form consistent with 
all the functionalities defined in the draft 01. 
I hope we can all agree on this so that you can formulate the issue. 
Regards 
Marco

---

From: <[email-masked]>
Date: Mon, 10 Nov 2003 14:39:06 +0200

Hi Chris,
 
[Chris Richards]
I think that without this ability, we'll severely limit the usefulness of the Diam CC protocol. As it is, the protocol is very restricted. I think we need to make it a bit more future proof. Otherwise, it will only solve existing requirements and not address any of the new requirements for IP flow charging, event charging, pre- post-paid integration, WLAN convergence with 3GPP & 3GPP2, etc. And if we limit ourselves to solving existing requirements only - then it would be better to stick with an existing application - like RADIUS and not bother with Diam at all.
 
If you look to the Flow X of the draft 01, the flexibility you are talking about is already there and it addresses IP flow charging for all the future scenarios you have listed.
Flow X is a simple example, you could have more sofisticated examples as well (e.g. on demand etc.). But the key is to derive all the quotas from the same credit reservation to avoid bottlenecks in the account management system and the account it self. If you request 20 services from the same CC session, why would you perform 20 times a credit reservation and maintain states for all of those? It doesn't seem very optimized. Could you kindly explain what is your credit reservation strategy and concretely explain what is the scenario not covered in the draft?
 
[Chris Richards]
As for using sub-sessions, for 3GPP, isn't the intention of these to be used for secondary PDP contexts? Using sub-sessions for the same user session actually adds overhead - not just the additional transport overhead but also the additional separate state maintenance that needs to be maintained for what are logically linked entities.
 
Secondary PDP Contexts are one example where you could use sub-sessions. Multiple services within the same user session and differentiated charging of those is supported in draft 01 as I explained above and doesn't require sub-sessions, perhaps we just have different views and beliefs on the approach to use.
 
[Chris Richards]
From the transport efficiency, think of mass events that may happen (e.g. a node outage causing all active sessions to be closed gracefully). Now if each user has to send multiple messages and there are many millions of users active, the overhead on the network, client and server becomes the bottleneck. 
 
Transport is not handled by the DCC application at all, the DCC just uses the Diameter transport according to RFC 3539 and RFC 3588.
 
Regards
Marco.

 -----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 10 November, 2003 13:56
To: 'Harri Hakala (TU/LMF)'; Leena Mattila (TU/LMF); Stura Marco (NET/Helsinki)
Cc: Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo (KA/EAB); [email-masked]'
Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Harri, Leena, Marco, 

I think that without this ability, we'll severely limit the usefulness of the Diam CC protocol. As it is, the protocol is very restricted. I think we need to make it a bit more future proof. Otherwise, it will only solve existing requirements and not address any of the new requirements for IP flow charging, event charging, pre- post-paid integration, WLAN convergence with 3GPP & 3GPP2, etc. And if we limit ourselves to solving existing requirements only - then it would be better to stick with an existing application - like RADIUS and not bother with Diam at all.

As for using sub-sessions, for 3GPP, isn't the intention of these to be used for secondary PDP contexts? Using sub-sessions for the same user session actually adds overhead - not just the additional transport overhead but also the additional separate state maintenance that needs to be maintained for what are logically linked entities.

From the transport efficiency, think of mass events that may happen (e.g. a node outage causing all active sessions to be closed gracefully). Now if each user has to send multiple messages and there are many millions of users active, the overhead on the network, client and server becomes the bottleneck. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: Harri Hakala (TU/LMF) [ mailto:[email-masked]] 
Sent: Monday, November 10, 2003 4:41 AM 
To: Leena Mattila (TU/LMF); Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]' 
Cc: [email-masked]'; [email-masked]'; [email-masked]'; Patrik Teppo (KA/EAB); [email-masked]'

Hi Chris, Marco & Leena, 

>Trigger-Ids and their values. 

I think that Marco and Leena have provided very well justified answers why we should not spilt multiple service requests up into several 

The Trigger-Actions shall only cause action credit re-authorization, i.e. send a CCR[update] to server. It is then up to the server to decide further

actions: continue as normally or if the user's account runs out of money, the server can terminate service or provide graceful service termination feature as described in the cca-01, section 5.5 Graceful Service Termination. Other actions than credit authorization are not in scope of credit control specification and shall not be defined in the cca draft.

I also agree with Marco that it is reasonable to go ahead with the proposal below, and start to define Trigger-Ids and their values.

regards.........Harri 

-----Original Message----- 
From: Leena Mattila (TU/LMF) 
Sent: 10. marraskuuta 2003 10:01 
To: [email-masked]'; [email-masked]' 
Cc: Harri Hakala (TU/LMF); [email-masked]'; [email-masked]'; [email-masked]'; Patrik Teppo (KA/EAB); [email-masked]'

Hi Chris, Marco, 

BR, 
Leena 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: 7. marraskuuta 2003 14:02 
To: [email-masked] 
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB); [email-masked]

[Chris Richards] 
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you agreed above, it only makes sense to include the U-S-U associated to that G-S-U which was triggered. Triggers are specific to the G-S-U in which they are in. If all the G-S-U must send a U-S-U when any trigger event is reached, it breaks the association - and effectively makes the trigger session specific - not G-S-U specific. [Marco St.] 

[Chris Richards] 

 [Chris Richards] 

[Marco St.] 

[Chris Richards] 
Thank you for including the Reason-Code. However, should it not be part of the U-S-U to keep the association between the U-S-U. This way, all that is needed is the Reason-Code itself since the other fields are already present in the U-S-U. It will also make implementations easier because the Reason is parsed at the same time as the U-S-U - instead of separately in another part of the message. [Marco St.] 

Regards 
Marco 

 -----Original Message----- 
From: [email-masked] [ mailto:[email-masked]]On Behalf Of ext Christopher Richards 
Sent: 06 November, 2003 19:57 
To: Stura Marco (NET/Helsinki) 
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]

Hi Marco, 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 11:35 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Chris, 
after the debate on your proposal whether triggers should be per G-S-U or per CC command, as stated in a previous mail, I changed mindset and I see now some value in defining those triggers per G-S-U. I agree on adding triggers associated to each G-S-U but in somewhat simpler form, I would propose some changes to your initial proposal in order to integrate this new functionality seamlessly and consistently with all the functionalities already defined in the draft 01. The server may include one or more CC-Re-Auth-Triggers associated to the G-S-U as in your proposal. Whenever one trigger event occurs the client sends a CCR[Update]. The CCR[Update] includes as many U-S-U as many G-S-U were received in a previous CCA command (i.e. all the quotas 

are reported to the server). 
[Chris Richards] 
But since CC-Re-Auth-Triggers are associated to the specific G-S-U as you agreed above, it only makes sense to include the U-S-U associated to that G-S-U which was triggered. Triggers are specific to the G-S-U in which they are in. If all the G-S-U must send a U-S-U when any trigger event is reached, it breaks the association - and effectively makes the trigger session specific - not G-S-U specific. Also note that the triggers do not have to cause a CCR[Update]. It may be that an event causes the CC client to perform some other action that does not immediately lead to a CCR[Update] for the G-S-U. [End Chris Richards] 

As well as a Trigger-Id and Trigger-Value, there seems to be a need for an (optional) Trigger-Action since it m ay be that the CC Client might not always need to re-auth for the trigger. For example, it may be to Unblock the usage of a temporarily blocked G-S-U after a defined time period (Just thinking aloud). The point is that the protocol should have the flexibility for this. So, I propose:- CC-Re-Auth-Trigger ::= < AVP Header: TBD > 

                       { Trigger-Id } 
                       [ Trigger-Value ] 
                       [ Trigger-Action] 
The Trigger-Id (Enumerated) may be QoS-Change, Location-Change, Idle-Timeout, Service-Specific etc. but we need to define them to enable interoperability. The Trigger-Value (UTF8String) defines the value of the trigger and we need to define some of these as well for the same reason. 

If the Reason-Code is set to CC-Re-Auth-Trigger occured the CC-Re-Auth-Trigger AVP is included to indicate what is the trigger that caused the CCR[Update]. If multiple quotas were given, the Service-Identifier or Rating-Group AVP is included to indicate what is the service or rating-group that caused the CCR[Update]. [Chris Richards] 

Thank you for including the Reason-Code. However, should it not be part of the U-S-U to keep the association between the U-S-U. This way, all that is needed is the Reason-Code itself since the other fields are already present in the U-S-U. It will also make implementations easier because the Reason is parsed at the same time as the U-S-U - instead of separately in another part of the message. [End Chris Richards]

---

From: <[email-masked]>
Date: Mon, 10 Nov 2003 15:44:51 +0200

Hi Chris,

> I think that without this ability, we'll severely limit the usefulness of the Diam CC 
> protocol. As it is, the protocol is very restricted. I think we need to make it a bit more 
> future proof. Otherwise, it will only solve existing requirements and not address any of the 
> new requirements for IP flow charging, event charging, pre- post-paid integration, WLAN 
> convergence with 3GPP & 3GPP2, etc. And if we limit ourselves to solving existing 
> requirements only - then it would be better to stick with an existing application - like 
> RADIUS and not bother with Diam at all.

There seems to be a difference for opinion on this topic.  I guess what is needed would be 
detailed reasoning how the usefulness of the CC app is limited.  Additionally, future extentions to CCA via new AVPs, etc. are always possible.

> As for using sub-sessions, for 3GPP, isn't the intention of these to be used for secondary 
> PDP contexts? Using sub-sessions for the same user session actually adds overhead - not just 
> the additional transport overhead but also the additional separate state maintenance that 
> needs to be maintained for what are logically linked entities.

As far as intentions go, it may be good for 3GPP to state exact needs/requirements, otherwise 
it is quite hard to hit a moving target.

> From the transport efficiency, think of mass events that may happen (e.g. a node outage 
> causing all active sessions to be closed gracefully). Now if each user has to send multiple 
> messages and there are many millions of users active, the overhead on the network, client and > server becomes the bottleneck. 

The transport behavior is handled in the Diameter base specification, not in the CC application.

thanks,
John