From aaa-admin@ietf.org Sat Nov 1 06:28:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04265 for ; Sat, 1 Nov 2003 06:28:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFtvF-0002GB-KI; Sat, 01 Nov 2003 06:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFtuR-0002Dm-Kc for aaa@optimus.ietf.org; Sat, 01 Nov 2003 06:27:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04253 for ; Sat, 1 Nov 2003 06:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFtuN-0000KO-00 for aaa@ietf.org; Sat, 01 Nov 2003 06:27:07 -0500 Received: from h118n2fls35o806.telia.com ([217.210.9.118] helo=217.210.9.118) by ietf-mx with smtp (Exim 4.12) id 1AFtuM-0000KK-00 for aaa@ietf.org; Sat, 01 Nov 2003 06:27:06 -0500 Date: Sat, 01 Nov 2003 14:27:26 -0500 From: 240259@msn.com X-Mailer: AspMail 3.53 (SMTP6F169C) Reply-To: 240259@yahoo.com Organization: 362724402 X-Priority: 3 (Normal) To: aaa@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Subject: [Aaa] The 30 Hour Wonder! 162936328 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Cyalus comes in smaller doses and produces fewer side effects. Cyalus also works much faster than Sildenafil-based medications. In clinical trials, the majority of men who took the drug were able to engage in sexual intercourse within 30 minutes or less. The studies also indicated that Cyalus stays in the system for up to 30 hours. That's 26 hours longer than the traditional Sildenafil-based medications treatment. Test results showed that out of 700 participants at least 88 percent of men experienced improvement with their erections. More info http://www.hostvy.com/ 5C04D9F6-30F7D93B-41B2F87C-1917A9B4-4AAF05F6 115E3261-56482D51-1BFA66E-5E1FE1B8-5E78BFE6 54D48E7D-EDCDE1F-17E53BB1-73527B7-3418AC6 _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Nov 1 06:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04280 for ; Sat, 1 Nov 2003 06:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFtvT-0002Jy-Uq for aaa-archive@odin.ietf.org; Sat, 01 Nov 2003 06:28:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1BSFIM008916 for aaa-archive@odin.ietf.org; Sat, 1 Nov 2003 06:28:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFtvT-0002Jj-QO for aaa-web-archive@optimus.ietf.org; Sat, 01 Nov 2003 06:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04259 for ; Sat, 1 Nov 2003 06:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFtvP-0000Kc-00 for aaa-web-archive@ietf.org; Sat, 01 Nov 2003 06:28:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFtvP-0000KX-00 for aaa-web-archive@ietf.org; Sat, 01 Nov 2003 06:28:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFtvF-0002GB-KI; Sat, 01 Nov 2003 06:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFtuR-0002Dm-Kc for aaa@optimus.ietf.org; Sat, 01 Nov 2003 06:27:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04253 for ; Sat, 1 Nov 2003 06:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFtuN-0000KO-00 for aaa@ietf.org; Sat, 01 Nov 2003 06:27:07 -0500 Received: from h118n2fls35o806.telia.com ([217.210.9.118] helo=217.210.9.118) by ietf-mx with smtp (Exim 4.12) id 1AFtuM-0000KK-00 for aaa@ietf.org; Sat, 01 Nov 2003 06:27:06 -0500 Date: Sat, 01 Nov 2003 14:27:26 -0500 From: 240259@msn.com X-Mailer: AspMail 3.53 (SMTP6F169C) Reply-To: 240259@yahoo.com Organization: 362724402 X-Priority: 3 (Normal) To: aaa@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Subject: [Aaa] The 30 Hour Wonder! 162936328 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Cyalus comes in smaller doses and produces fewer side effects. Cyalus also works much faster than Sildenafil-based medications. In clinical trials, the majority of men who took the drug were able to engage in sexual intercourse within 30 minutes or less. The studies also indicated that Cyalus stays in the system for up to 30 hours. That's 26 hours longer than the traditional Sildenafil-based medications treatment. Test results showed that out of 700 participants at least 88 percent of men experienced improvement with their erections. More info http://www.hostvy.com/ 5C04D9F6-30F7D93B-41B2F87C-1917A9B4-4AAF05F6 115E3261-56482D51-1BFA66E-5E1FE1B8-5E78BFE6 54D48E7D-EDCDE1F-17E53BB1-73527B7-3418AC6 _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Nov 3 02:46:50 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 CAA22925 for ; Mon, 3 Nov 2003 02:46:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FC509125B; Mon, 3 Nov 2003 02:45:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6562C9125E; Mon, 3 Nov 2003 02:45:35 -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 0805D9125B for ; Mon, 3 Nov 2003 02:45:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBE035DDE0; Mon, 3 Nov 2003 02:45:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 4C9545DD9E for ; Mon, 3 Nov 2003 02:45:33 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA37jQI2008565; Mon, 3 Nov 2003 08:45:27 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Nov 2003 08:45:44 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , "'Mark Grayson (mgrayson)'" , aaa-wg@merit.edu, marco.stura@nokia.com Cc: "Leena Mattila (TU/LMF)" , juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, Benni.Alexander@nokia.com, "Patrik Teppo (KA/EAB)" Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Date: Mon, 3 Nov 2003 08:44:21 +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 Christopher, >[Chris Richards] Great. Since the mechanisms for one approach are described, it makes sense to describe the mirror approach >- just for consistency and clarity. It is still completely up to vendors/implementers to choose which mechanism to provide. >What we're aiming for is a good, flexible and efficient protocol definition that can accommodate future requirements. The cca draft describes mechanisms for credit authorization only. This mirror approach would mean that credit control messages would be used to request service specific authentication and/or authorization, which are not in scope of cca draft. AA messages explicitly indicates, which AA mechanisms shall be used for authentication & authorization. If the CCR message carries AA AVPs, it would be more complex task to server to find out what authentication & authorization should be used. Note that there is one to many relationship between credit control authorization and service specific authentication&authorization, i.e. there is only one credit control application (that could be added on top of existing auth commands) but many AA applications that could be included in the credit control messages. regards........Harri -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 31. lokakuuta 2003 16:53 To: Harri Hakala (TU/LMF); 'Mark Grayson (mgrayson)'; aaa-wg@merit.edu; marco.stura@nokia.com Cc: Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB) Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Friday, October 31, 2003 5:34 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'Mark Grayson (mgrayson)'; aaa-wg@merit.edu; marco.stura@nokia.com Cc: Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB) Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Hi Christopher, >Mixing applications is already described in the Diam CC draft (Adding >DCC AVPs to the AA messages). >I'm only proposing the >logical mirror of the existing mixing. >To me, it seems cleaner than impacting an already existing protocol with new features. Better to build >existing features & functionality into the new protocol. We have defined a scenario, as you said, where the initial credit control request is performed as part of the authentication/authorization for the sake of protocol efficiency. After the initial request, following credit control requests are done with credit control messages, likewise following (re-)authentication & authorization requests are done with AA messages. It is true that some credit control specific AVPs (e.g. Requested-Service-Unit or some Rating Input AVPs) may be added to initial service specific AA message, but I assume that *[AVP] notation makes this possible without any major impact to the existing protocols. But also vice versa approach, i.e. AA AVPs added to the CCR message causes some impacts to existing AA implementations, since then AA servers shall support initial authentication and authorisation with the CCR message. [Chris Richards] Great. Since the mechanisms for one approach are described, it makes sense to describe the mirror approach - just for consistency and clarity. It is still completely up to vendors/implementers to choose which mechanism to provide. What we're aiming for is a good, flexible and efficient protocol definition that can accommodate future requirements. Cheers, Chris. Regards........Harri From owner-aaa-wg@merit.edu Mon Nov 3 03:32:13 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 DAA23644 for ; Mon, 3 Nov 2003 03:32:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E31B291270; Mon, 3 Nov 2003 03:31:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5796F9126D; Mon, 3 Nov 2003 03:31:03 -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 C86029125F for ; Mon, 3 Nov 2003 03:30:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACFF65DE29; Mon, 3 Nov 2003 03:30:57 -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 B00F95DE16 for ; Mon, 3 Nov 2003 03:30:56 -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 hA38UtF25176 for ; Mon, 3 Nov 2003 10:30:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 10:30:54 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 10:30:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Nov 2003 10:30:53 +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: Mon, 3 Nov 2003 10:30:53 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diam CC (AA interrogation in initial CC request) Thread-Index: AcOfvjI+GvUimcxFROaNnYynPkVwMACJmbKw From: To: , X-OriginalArrivalTime: 03 Nov 2003 08:30:54.0140 (UTC) FILETIME=[CBDD4FC0:01C3A1E4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, > I'll take a look at the thread.=20 Please do, if you find problems with it, please try to address the = problems you see. > I'm not saying that the current proposal is broken - just lacking=20 > and inefficient.=20 > Since we're at the draft stage now, it seems like a good time to=20 > propose making improvements to the existing mechanism. It's not too = late=20 > for that I trust? As there has been discussion on the topic, I don't want to go back and forth too much, but if you can find improvements, that's OK. John From owner-aaa-wg@merit.edu Tue Nov 4 06:56:04 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 GAA10507 for ; Tue, 4 Nov 2003 06:56:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D7E39129A; Tue, 4 Nov 2003 06:56:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE2069129B; Tue, 4 Nov 2003 06:56:00 -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 8D11F9129A for ; Tue, 4 Nov 2003 06:55:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 705E25DE33; Tue, 4 Nov 2003 06:55:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id 72ADC5DD94 for ; Tue, 4 Nov 2003 06:55:58 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 4 Nov 2003 11:59:20 +0000 To: aaa-wg@merit.edu Subject: [AAA-WG]: Question about Diameter CCA Interoperability MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.ie Date: Tue, 4 Nov 2003 11:55:53 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 11/04/2003 11:55:54 AM, Serialize complete at 11/04/2003 11:55:54 AM Content-Type: multipart/alternative; boundary="=_alternative 0041886D80256DD4_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0041886D80256DD4_= Content-Type: text/plain; charset="us-ascii" Hi All, I've been starting to study how CCA could be used. I'm using a scenario where it would be used between a service node and a balance management node for a pre-paid mobile phone subscribers. I've a question on inter-operability, which may be a niave one (in which case please accept my apologies). As far as I can work out, much of the information for charging would have to be included in the Service-Parameter-Info AVP. It therefore looks as though the content of this grouped AVP would have to be defined locally between the vendor of the two nodes and defined for that specific purpose. The issue comes into play if we imagine a situation where a second vendor is used to supply one of those nodes. The second vendor could quite honestly claim to support Diameter CCA, but their definition of Service-Parameter-Info could be very different. It seems to me that there would be no way that the new node could easily be made to inter-operate with the existing nodes. Effectively, the implementations would be close to being proprietary. What are the mechanisms within CCA to avoid this sort of problem? Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 0041886D80256DD4_= Content-Type: text/html; charset="us-ascii"
Hi All,

I've been starting to study how CCA could be used.  I'm using a scenario where it would be used between a service node and a balance management node for a pre-paid mobile phone subscribers.  I've a question on inter-operability, which may be a niave one (in which case please accept my apologies).

As far as I can work out, much of the information for charging would have to be included in the Service-Parameter-Info AVP.  It therefore looks as though the content of this grouped AVP would have to be defined locally between the vendor of the two nodes and defined for that specific purpose.  

The issue comes into play if we imagine a situation where a second vendor is used to supply one of those nodes.  The second vendor could quite honestly claim to support Diameter CCA, but their definition of Service-Parameter-Info could be very different.  It seems to me that there would be no way that the new node could easily be made to inter-operate with the existing nodes.  Effectively, the implementations would be close to being proprietary.

What are the mechanisms within CCA to avoid this sort of problem?

Regards,

John.


******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
 --=_alternative 0041886D80256DD4_=-- From owner-aaa-wg@merit.edu Tue Nov 4 08:31:56 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 IAA13892 for ; Tue, 4 Nov 2003 08:31:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13DA0912A4; Tue, 4 Nov 2003 08:30:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D597B912A7; Tue, 4 Nov 2003 08:30:52 -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 8CA8D912A4 for ; Tue, 4 Nov 2003 08:30:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72E395DDC8; Tue, 4 Nov 2003 08:30:51 -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 CA5725DDB8 for ; Tue, 4 Nov 2003 08:30:50 -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 hA4DUnSs017100; Tue, 4 Nov 2003 14:30:49 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 14:30:49 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'John.Prudhoe@vodafone.ie'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question about Diameter CCA Interoperability Date: Tue, 4 Nov 2003 14:29:36 +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 John, We have got some comments related to this problem and we have tried to emphasize this issue in the CCA-01 version by adding own section how to send rating input to credit control servers, section 4.1 Rating input. Primarily applications should re-use existing AVPs defined by some Diameter application. New AVPs can be also defined if the existing AVPs can not be re-used. The Service-Parameter-Info AVP may be used to pass legacy rating information in its original encoded form. But to simplify interoperability, it is recommended to use of explicitly defined AVP's. We also expect that there is some sort of agreement between the service providers of the credit control client and the credit control server. Part of this agreement is also to agree the rating input with the providers according to the service documentation. Regards.........Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.ie Sent: 4. marraskuuta 2003 13:56 To: aaa-wg@merit.edu Subject: [AAA-WG]: Question about Diameter CCA Interoperability Hi All, I've been starting to study how CCA could be used. I'm using a scenario where it would be used between a service node and a balance management node for a pre-paid mobile phone subscribers. I've a question on inter-operability, which may be a niave one (in which case please accept my apologies). As far as I can work out, much of the information for charging would have to be included in the Service-Parameter-Info AVP. It therefore looks as though the content of this grouped AVP would have to be defined locally between the vendor of the two nodes and defined for that specific purpose. The issue comes into play if we imagine a situation where a second vendor is used to supply one of those nodes. The second vendor could quite honestly claim to support Diameter CCA, but their definition of Service-Parameter-Info could be very different. It seems to me that there would be no way that the new node could easily be made to inter-operate with the existing nodes. Effectively, the implementations would be close to being proprietary. What are the mechanisms within CCA to avoid this sort of problem? Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** From owner-aaa-wg@merit.edu Tue Nov 4 10:29:01 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 KAA18464 for ; Tue, 4 Nov 2003 10:29:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF66791341; Tue, 4 Nov 2003 10:25:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99FEA91337; Tue, 4 Nov 2003 10:25:56 -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 43EB291347 for ; Tue, 4 Nov 2003 10:24:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 279365DE14; Tue, 4 Nov 2003 10:24:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id A80705DD94 for ; Tue, 4 Nov 2003 10:24:22 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Tue, 4 Nov 2003 15:27:42 +0000 To: "Harri Hakala (TU/LMF)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question about Diameter CCA Interoperability MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.ie Date: Tue, 4 Nov 2003 15:24:16 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 11/04/2003 03:24:17 PM, Serialize complete at 11/04/2003 03:24:17 PM Content-Type: multipart/alternative; boundary="=_alternative 00549C5D80256DD4_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00549C5D80256DD4_= Content-Type: text/plain; charset="us-ascii" Hi Harri, Thank you for your response. I had been working from draft 00 and have now got CCA-01. I am afraid I have quite a few more questions resulting from this. Please feel free to direct me towards the appropriate section of the draft if I've overlooked it. I can certainly see the advantage of explicitly defined AVPs rather than Service-Parameter-Info, but I'm not sure I clearly understand all the implications of section 4.1. Does this mean that in practice there will be other applications effectively sitting on top of CCA? Will these applications be defined within the framework of the AAA-WG? Or will they be vendor-specific? I guess in this situation the application identifier that is advertised will be that of the 'other application' rather than that of CCA. Would the other application have the option of adding new commands? Have I also understood the concept correctly that a Command can use any AVPs defined within any Diameter application, or the base, not just those defined within the same application as the command? Could AVPs be defined without an application? If so, is there a 'home' for these AVPs - in other words, if we did defined new AVPs where would we document them? I also notice in 4.1 that Mandatory AVPs can be ignored if considered irrelevant by the server. Would a client have the option of missing out mandatory AVPs if it knew the server didn't need them? Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 00549C5D80256DD4_= Content-Type: text/html; charset="us-ascii"
Hi Harri,

Thank you for your response.  I had been working from draft 00 and have now got CCA-01.

I am afraid I have quite a few more questions resulting from this.  Please feel free to direct me towards the appropriate section of the draft if I've overlooked it.

I can certainly see the advantage of explicitly defined AVPs rather than Service-Parameter-Info, but I'm not sure I clearly understand all the implications of section 4.1.  Does this mean that in practice there will be other applications effectively sitting on top of CCA?  Will these applications be defined within the framework of the AAA-WG?  Or will they be vendor-specific?  I guess in this situation the application identifier that is advertised will be that of the 'other application' rather than that of CCA.  Would the other application have the option of adding new commands?

Have I also understood the concept correctly that a Command can use any AVPs defined within any Diameter application, or the base, not just those defined within the same application as the command?  Could AVPs be defined without an application?  If so, is there a 'home' for these AVPs - in other words, if we did defined new AVPs where would we document them?

I also notice in 4.1 that Mandatory AVPs can be ignored if considered irrelevant by the server.  Would a client have the option of missing out mandatory AVPs if it knew the server didn't need them?

Regards,

John.


 

 



******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
 --=_alternative 00549C5D80256DD4_=-- From owner-aaa-wg@merit.edu Tue Nov 4 10:46:35 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 KAA19307 for ; Tue, 4 Nov 2003 10:46:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84AFF91316; Tue, 4 Nov 2003 10:45:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33914912B0; Tue, 4 Nov 2003 10:45:36 -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 B39EC91313 for ; Tue, 4 Nov 2003 10:45:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id B8C275DDC8; Tue, 4 Nov 2003 10:45:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id D82055DDDB for ; Tue, 4 Nov 2003 10:45:25 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 130E46A904; Tue, 4 Nov 2003 17:45:09 +0200 (EET) Message-ID: <3FA7C886.1070109@kolumbus.fi> Date: Tue, 04 Nov 2003 17:40:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Updated security considerations for Diameter EAP References: <052E0C61B69C3741AFA5FE88ACC775A6010C385B@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C385B@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pasi, Sorry for responding to this so late, but was behind in e-mail... I like your new text. I do have a few nits below, and two technical suggestions: > Updated security considerations for Diameter EAP > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: October 22, 2003 > Reference: > Document: EAP-02 > Comment type: T/E > Priority: 1 > Section: 8 > Rationale/Explanation of issue: > > The current security considerations section has a lot of text that > doesn't really belong there (e.g. about certificates and > authorization), and some text unnecessarily duplicating issues that > are already well presented in 2284bis and the new EAP key management > framework document. > > Suggested change: Replace section 8 with the following text. > > 8. Security Considerations > > 8.1 Overview > > Diameter peer-to-peer connections can be protected with IPsec or TLS. > These mechanisms are believed to provide sufficient protection under > the normal Internet threat model--that is, assuming the authorized > nodes engaging in the protocol have not been compromised, but the > attacker has complete control over the communication channels between > them. This includes eavesdropping, message modification, insertion, > man-in-the-middle and replay attacks. The details and related > security considerations are discussed in [BASE]. > > In addition to authentication provided by IPsec or TLS, authorization > is also required. Authorization here means the act of determining if > a Diameter message received from an authenticated Diameter peer > should be accepted (and not authorization of users requesting network > access from a NAS). In other words, when a Diameter server receives > a Diameter-EAP-Request, it has to decide if the client is authorized > to act as a NAS for the specific user, service type, and so on. > Correspondingly, when a NAS contacts a server to send a > Diameter-EAP-Request, it has to determine whether the server is > authorized to act as home server for the realm in question. > > Authorization can involve local Access Control Lists (ACLs), > information contained in certificates, or some other means. See > [BASE] for more discussion and related security considerations. Here I would still add/keep a bit of discussion about the impacts of redirect to authorization, since I don't see that being discussed in the keying draft. Here's a suggestion: Authorization issues are particularly relevant when Diameter redirects are used. While redirection reduces the number of nodes which have access to the cleartext Diameter messages, a compromised Diameter agent may not supply the right home server's address. If the Diameter client is unable to tell whether this particular server is authorized to act as the home server for this particular user, the security of the communications rests on the agent, even if redirects are used. > The hop-by-hop security mechanisms (IPsec and TLS) combined with > proper authorization provide good protection against "outside" > attackers (denial-of-service is, of course, possible). The remaining > part of this section deals with attacks by nodes that have been > properly authorized (to function as a NAS, Diameter agent, or > Diameter server) but abuse their authorization or have been > compromised. In general, it is not possible to completely protect > against attacks by compromised nodes, but this section offers some > advice that can be used to limit the extent of the damage. > > Attacks involving eavesdropping or modification of EAP messages are > beyond the scope of these document. See [RFC2284bis] for discussion > of these security considerations (including method negotation, > dictionary attacks, and privacy issues). While these attacks can be > carried out by an attacker between the client and the NAS, > compromised NASes and Diameter agents are naturally also in a good > position to modify and eavesdrop the EAP messages. > > Similarly, attacks involving whatever link layer protocol is used > between the client and the NAS, such as PPP or IEEE 802.11, are > beyond the scope of this document. > > 8.2 AVP editing > > Diameter agents can modify, insert, and delete AVPs. Diameter agents > are usually meant to modify AVPs, and the protocol in general cannot > distinguish well-intentioned and malicious modifications (see > [RFC2607] for more discussion). Similarly, a compromised NAS or > server can naturally include different set of AVPs than expected. > > The question is thus "what can an attacker who compromises an > authorized NAS, agent, or server do using Diameter EAP messages?" > Some of the consequences are rather obvious--for instance, a Diameter > agent can give access to unauthorized users by changing the > Result-Code to DIAMETER_SUCCESS. Other consequences are less obvious, > and are discussed below (authentication method negotiation attacks > are discussed in the next section). > > By including suitable AVPs in an AA-Answer/Diameter-EAP-Answer > messages an attacker (depending on implementation and configuration > details) may be able to: > > o Give unauthorized users access, or deny access to authorized users > (Result-Code). > > o Give attacker a login session to a host otherwise protected by > firewalls, or redirect an authorized user's login session to a > host controlled by the attacker (Login-Host). > > o Route an authorized user's traffic through a host controlled by > the attacker (various tunneling AVPs). > > o Redirect an authorized user's DNS requests to a malicious DNS > server (various vendor-specific AVPs). > > o Modify routing tables at the NAS and thus redirect packets > destined for someone else (Framed-Route, Framed-Routing). > > o Remove packet filters and other restrictions for user (Filter, > Callback, various vendor-specific AVPs). > > o Cause the NAS to call some number, possibly expensive toll number > controlled by the attacker (callback AVPs) > > o Execute Command Line Interface (CLI) commands on the NAS (various > vendor-specific attributes). > > By modifying an AA-Request/Diameter-EAP-Request, an attacker may be > able to: > > o Change NAS-Identifier/NAS-Port/Origin-Host (or something) so that > a valid user appears to be accessing the network from a different > NAS than in reality. > > o Modify Calling-Station-ID (either to hide the true value, gain > access, or frame someone else). > > o Modify password change messages (some vendor-specific attributes) > > o Modify usage information in accounting messages. > > o Modify contents of Class/State AVPs? > > Some of these attacks can be prevented if the NAS or server can be > configured not to accept some particular AVPs, or accepting them only > from some nodes. Hmm... I agree with the above. But I wonder if we should also talk about the explicit authorization AVPs for users vs. current implicit "its ok if I don't complain" approach in RADIUS/Diameter. I thought the plan was to add some new authz AVPs in this draft, and we should say something about their security here. > 8.3 Negotiation attacks > > This section deals with attacks where the NAS, any Diameter agents, > or Diameter server attempts to cause the authenticating user to > choose some authentication method other than EAP, such as PAP or CHAP > (negotiation attacks within EAP are discussed in [RFC2284bis], > Section 7.8). > > The vulnerability can be mitigated via implementation of > per-connection policy on the part of the authenticating peer, and > per-peer policy on the part of the Diameter server. For the s/per-peer/per-user/? the latter term appears to be used below. > authenticating peer, authentication policy should be set on a > per-connection basis. > > With per-connection policy, an authenticating peer will only attempt > to negotiate EAP for a session in which EAP support is expected. As > a result, there is a presumption that an authenticating peer > selecting EAP requires that level of security. If it cannot be > provided, it is likely that there is some kind of misconfiguration, > or even that the authenticating peer is contacting the wrong server. > In this case, the authenticating peer simply disconnects. > > Similarly, with a per-user policy, the home server will not accept > authentication methods other than EAP for users for which EAP support > is expected. > > For a NAS, it may not be possible to determine whether a peer is > required to authenticate with EAP until the peer's identity is known. > For example, for shared-uses NASes it is possible for one reseller to > implement EAP while another does not. Alternatively, some peer might > be authenticated locally by the NAS while other peers are > authenticated via Diameter. In such cases, if any peers of the NAS > MUST do EAP, then the NAS MUST attempt to negotiate EAP for every > session. This avoids forcing a peer to support more than one > authentication type, which could weaken security. > > 8.4 Session key distribution > > Since there are currently no end-to-end (NAS-to-home server) security > mechanisms specified for Diameter, any agents that process > Diameter-EAP-Answer messages can see the contents of the > EAP-Session-Key AVP. For this reason, this specification strongly > recommends avoiding Diameter agents when they cannot be trusted to > keep the keys secret. > > In environments where agents are present, several factors should be > considered when deciding whether the agents that are authorized (and > considered "trustworthy enough") to grant access to users and specify > various authorization and tunneling AVPs are also "trustworthy > enough" to handle the session keys. These factors include (but are > not limited to) the type of access provided (e.g., public Internet or > corporate internet), security level of the agents, and the > possibilities for attacking user's traffic after it has been > decrypted by the NAS. > > Note that the keys communicated in Diameter messages are usually > short-term session keys (or short-term master keys that are used to > derive session keys). To actually cause any damage, those session > keys must end with some malicious party; that party must be able to > eavesdrop, modify, or insert traffic between the user and the NAS > during the lifetime of those keys (e.g., in 802.11i the attacker must > also eavesdrop the "four-way handshake"); and that eavesdropping or > modification must cause some damage. > > 8.5 Privacy issues > > Diameter messages can contain AVPs that can be used to identify the > user (e.g., User-Name) and approximate location of the user (e.g. > Origin-Host for WLAN access points, Calling-Station-Id for fixed > phone lines). Thus, any Diameter nodes that process the messages may > be able to determine the geographic location of users. > > Note that in many cases, the user identity is also sent in clear > inside EAP-Payload AVPs, and it may be possible to eavesdrop this > between the user and the NAS. > > This can mitigated somewhat by using EAP methods that provide > identity protection (see [RFC2284bis], Section 7.3), and using > Session-Id or pseudonyms for accounting. > > 8.6 Note about EAP and impersonation > > If the EAP method used does not provide mutual authentication, > obviously anyone can impersonate as the network to the user. Even > when EAP mutual authentication is used, it occurs between the user > and the Diameter home server. See for an extensive discussion about > the details and their implications. Reference missing. > However, one issue is worth pointing out here. As described in > [EAPKey], the current EAP architecture does not allow the home server > to restrict what service parameters or identities (such as SSID or > BSSID in 802.11 wireless LANs) are advertised by the NAS to the > client. That is, a compromised NAS can change its BSSID or SSID, thus > appearing to offer a different service than intended. Even if these > parameters are included in Diameter-EAP-Request messages, the NAS can > tell different values to the client. > > Thus, the possession of the session keys by the NAS proves that the > user is talking to *some* authorized NAS, but a compromised NAS can > lie about its exact identity. See [EAPKey] for discussion how > individual EAP methods can provide authentication of NAS service > parameters and identities. > > Note that the usefulness of such authentication may be rather limited > in many environments. For instance, in wireless LANs the user does > not usually securely know the identity (such as BSSID) of the "right" > access point--it's simply picked from a beacon message that has the > correct SSID and good signal strength (something that's easy to > spoof). Thus, simply authenticating the identity may not allow the > user to distinguish the "right" access point from all other ones. --Jari From owner-aaa-wg@merit.edu Tue Nov 4 10:54:21 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 KAA19891 for ; Tue, 4 Nov 2003 10:54:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72653912E0; Tue, 4 Nov 2003 10:51:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DF3991343; Tue, 4 Nov 2003 10:51:08 -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 C9294912E0 for ; Tue, 4 Nov 2003 10:49:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFCEA5DEAC; Tue, 4 Nov 2003 10:49:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 762535DDB4 for ; Tue, 4 Nov 2003 10:49:50 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D08266A904; Tue, 4 Nov 2003 17:49:49 +0200 (EET) Message-ID: <3FA7C99F.1060208@kolumbus.fi> Date: Tue, 04 Nov 2003 17:45:35 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Use Framed-MTU instead of EAP-MTU AVP? References: <052E0C61B69C3741AFA5FE88ACC775A6010C384E@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C384E@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Use Framed-MTU instead of EAP-MTU AVP? > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: October 14, 2003 > Reference: > Document: EAP-02 > Comment type: T > Priority: 1 > Section: various > Rationale/Explanation of issue: > > I proposed adding EAP-MTU AVP to version -02, but now I've come > to think that actually this is not absolutely necessary, and > complicates RADIUS translation. Any other opinions? (I'm OK > with either choice) > > Requested change: > > To simplify things, remove the EAP-MTU AVP. Instead of it, use > Framed-MTU as described in RFC3579 (and borrow some text from > there). Yet another old e-mail. This issue looks ok, and I've taken a look at -03 text which is ok too. --Jari From owner-aaa-wg@merit.edu Wed Nov 5 03:04:35 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 DAA25082 for ; Wed, 5 Nov 2003 03:04:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7DB1A912C6; Wed, 5 Nov 2003 03:04:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5138B912C7; Wed, 5 Nov 2003 03:04:29 -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 BDB83912C6 for ; Wed, 5 Nov 2003 03:04:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id A11E45DDCF; Wed, 5 Nov 2003 03:04:27 -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 E49875DDCA for ; Wed, 5 Nov 2003 03:04:26 -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 hA584PSs026868; Wed, 5 Nov 2003 09:04:25 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 09:04:27 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'John.Prudhoe@vodafone.ie'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question about Diameter CCA Interoperability Date: Wed, 5 Nov 2003 09:03:17 +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 John. >Does this mean that in practice there will be other applications effectively >sitting on top of CCA? Will these applications be defined within the framework >of the AAA-WG? Or will they be vendor-specific? I guess in this situation the >application identifier that is advertised will be that of the 'other application' >rather than that of CCA. Would the other application have the option of adding >new commands? The controlling AVPs and credit control mechanisms defined by CCA are generic enough for different services, but very often the rating input varies from one service to another. It is not reasonable to define these service specific rating input AVPs (or the contents of the SPI AVP) in the cca draft, but these AVPs should be defined in some other application or document. You can run the cca together with some other diameter application (e.g. NASREQ, vendor specific) or you can use it alone, but then you should use service specific rating input AVPs defined in somewhere else. If just rating AVPs are added to CCR command then you can use application identifier of cca. Diameter expandability is discussed in Diam Base, section 1.2 Approach to Extensibility. That section describes when creating new AVPs are enough or when you need to create a new diameter application. >Have I also understood the concept correctly that a Command can use any AVPs defined >within any Diameter application, or the base, not just those defined within the same >application as the command? Yes, this is true. >Could AVPs be defined without an application? If so, is >there a 'home' for these AVPs - in other words, if we did defined new AVPs where would >we document them? Usually you define AVPs for the diameter application. If you need for instance rating input AVPs for vendor specific service, then use cca application. If you have standard diameter application and you need a new AVP for it, then use that application. The cca draft recommends that rating input AVPs are documented in another Diameter application, standards written by other standardization bodies, or service specific documentation. >I also notice in 4.1 that Mandatory AVPs can be ignored if considered irrelevant by the >server. Would a client have the option of missing out mandatory AVPs if it knew the >server didn't need them? I think that it would be good to send always mandatory AVPs ('M'-bit set) to server and let it then ignore them, if needed. Regards..........Harri -----Original Message----- From: John.Prudhoe@vodafone.ie [mailto:John.Prudhoe@vodafone.ie] Sent: 4. marraskuuta 2003 17:24 To: Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question about Diameter CCA Interoperability Hi Harri, Thank you for your response. I had been working from draft 00 and have now got CCA-01. I am afraid I have quite a few more questions resulting from this. Please feel free to direct me towards the appropriate section of the draft if I've overlooked it. I can certainly see the advantage of explicitly defined AVPs rather than Service-Parameter-Info, but I'm not sure I clearly understand all the implications of section 4.1. Does this mean that in practice there will be other applications effectively sitting on top of CCA? Will these applications be defined within the framework of the AAA-WG? Or will they be vendor-specific? I guess in this situation the application identifier that is advertised will be that of the 'other application' rather than that of CCA. Would the other application have the option of adding new commands? Have I also understood the concept correctly that a Command can use any AVPs defined within any Diameter application, or the base, not just those defined within the same application as the command? Could AVPs be defined without an application? If so, is there a 'home' for these AVPs - in other words, if we did defined new AVPs where would we document them? I also notice in 4.1 that Mandatory AVPs can be ignored if considered irrelevant by the server. Would a client have the option of missing out mandatory AVPs if it knew the server didn't need them? Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** From owner-aaa-wg@merit.edu Thu Nov 6 14:03:29 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 OAA23148 for ; Thu, 6 Nov 2003 14:03:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A631B91220; Thu, 6 Nov 2003 12:57:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71FED91225; Thu, 6 Nov 2003 12:57:29 -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 6851891220 for ; Thu, 6 Nov 2003 12:57:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D51F5DF1B; Thu, 6 Nov 2003 12:57:27 -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 BC1B95DF07 for ; Thu, 6 Nov 2003 12:57:26 -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 hA6HvH702843; Thu, 6 Nov 2003 09:57:18 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Nov 2003 11:57:19 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E89D5@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: harri.hakala@ericsson.com, leena.mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, Benni.Alexander@nokia.com, patrik.teppo@ericsson.com, aaa-wg@merit.edu Subject: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Thu, 6 Nov 2003 11:57:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A48F.6B8D1EB8" 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_01C3A48F.6B8D1EB8 Content-Type: text/plain Hi Marco, Thanks for the email. We're making excellent progress. I added my responses below. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, November 06, 2003 11:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu 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 ------_=_NextPart_001_01C3A48F.6B8D1EB8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Thursday, November 06, 2003 11:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: harri.hakala@ericsson.com; = leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; = john.loughney@nokia.com; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com; aaa-wg@merit.edu

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 ::=3D < AVP Header: 431 > =
          &nb= sp;           &nb= sp;  [ Tariff-Time-Change ]
          &nb= sp;           &nb= sp; *[CC-Re-Auth-Trigger ]
          &nb= sp;           &nb= sp;  [ CC-Time ]
          &nb= sp;           &nb= sp;  [ CC-Money ]
          &nb= sp;           &nb= sp;  [ CC-Total-Octets ]
          &nb= sp;           &nb= sp;  [ CC-Input-Octets ]
          &nb= sp;           &nb= sp;  [ CC-Output-Octets ]
          &nb= sp;           &nb= sp;  [ CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp; *[ Service-Identifier ]
          &nb= sp;           &nb= sp;  [ Rating-Group ]

CC-Re-Auth-Trigger ::=3D < AVP Header: TBD > =
          &nb= sp;            { = Trigger-Id }
          &nb= sp;            [ = 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 ::=3D < AVP Header: TBD > =
          &nb= sp;            { = Trigger-Id }
          &nb= sp;            [ = Trigger-Value ]
          &nb= sp;            [ = 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 >
          &nb= sp;          { Reason-Code = }
          &nb= sp;          [ = CC-Re-Auth-Trigger ]
          &nb= sp;          [ = Service-Identifier ]
          &nb= sp;          [ = 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





------_=_NextPart_001_01C3A48F.6B8D1EB8-- From owner-aaa-wg@merit.edu Thu Nov 6 14:03:27 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 OAA23149 for ; Thu, 6 Nov 2003 14:03:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1ECAB91213; Thu, 6 Nov 2003 11:19:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEC2B912CD; Thu, 6 Nov 2003 11:19:15 -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 D50E391213 for ; Thu, 6 Nov 2003 11:19:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE07E5DDDF; Thu, 6 Nov 2003 11:19:13 -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 9F3665DDD4 for ; Thu, 6 Nov 2003 11:19:12 -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 hA6GJBY11949 for ; Thu, 6 Nov 2003 18:19:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 18:19:09 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 18:19:09 +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_01C3A481.B4EAFA44" Subject: [AAA-WG]: RE: Diam CC Tariff time changes Date: Thu, 6 Nov 2003 18:19:08 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0332@esebe016.ntc.nokia.com> Thread-Topic: Diam CC Tariff time changes Thread-Index: AcOkf0wuVzDiMXtPSXmZh5JTgvwTVAAAEBng From: To: Cc: , , , , , , X-OriginalArrivalTime: 06 Nov 2003 16:19:09.0036 (UTC) FILETIME=[B4F77AC0:01C3A481] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A481.B4EAFA44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 Sorry for not replying earlier - I'm out of the office this week and = only have occasional email access.=20 =20 No problem at all. =20 I really think that Tariff change is part of a larger set of events that = each G-S-U (quota) is associated with. And each G-S-U may be associated = with 0+ of these events. Each event set that the G-S-U is associated = with is independent of the other G-S-Us. That may be in a CC message. =20 I think it is fine to add triggers associated to the G-S-U but would = treat the tariff change with a different AVP since it doesn't need to = trigger the credit re-authorization. =20 I had some re-thinking about the triggers and I see some value in adding = triggers associated to the G-S-U as long as whenever one trigger event = occurs the client always initiate the credit re-authorization whithout leaving = quotas running in it (i.e. all quotas are reported to the server). So, I think it is fine to add triggers associated to the G-S-U but would = treat the tariff change as logically different funbtionality with a = different AVP. For that reason I would keep the two discussion separated. =20 Regards Marco =20 -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 06 November, 2003 18:02 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen = Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni = (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: RE: Diam CC Tariff time changes Hi Marco,=20 Sorry for not replying earlier - I'm out of the office this week and = only have occasional email access.=20 I really think that Tariff change is part of a larger set of events that = each G-S-U (quota) is associated with. And each G-S-U may be associated = with 0+ of these events. Each event set that the G-S-U is associated = with is independent of the other G-S-Us. That may be in a CC message. This is why I was proposing to add a generic event AVP to the G-S-U (I = called it a "trigger" - but the name is not important). Some examples I = gave are: G-S-U idleness, location change, QoS change, threshold usage = level. But there are many more. Each G-S-U should be able to have a different set of events (and = actions, values to use when the event occurs) to other G-S-U in use. Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Thursday, November 06, 2003 8:45 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: Diam CC Tariff time changes=20 Hi Chris,=20 I think we agreed on the tariff changes issue and principles.=20 I had some thought on how to implement this support of tariff time = changes in the Diam CC, I would like to know your opinion whether you = agree on the approach. I guess we need tariff change at the G-S-U level since it may not apply = to all the services or rating groups. The server would grant quota = according to the worst case (i.e. the highest price)=20 and the client would report units used before and after the tariff = change. This would result in two U-S-U (eventually associated to the = same Service-Identifier or Rating-Group if applicable) in a CCR command, = one USU includes the units consumed before the tariff time change and = the other USU includes the units consumed after the tariff time change. = This mechanism would be optional for client and server and would not be = used for time quotas since=20 the server is in full control of the time. A client not supporting the = tariff time change mechanism would terminate the service and send a = CCR[Termination] to the server with an appropriate Termination-Cause = (e.g. DIAMETER_BAD_ANSWER) since this affect the cost of the service. Do = we need to indicate to the server more precise reason (e.g. Tariff-time = not supported)? Granted-Service-Unit ::=3D < AVP Header: TBD >=20 [ Tariff-Time-Change ]=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 =20 Used-Service-Unit ::=3D < AVP Header: TBD >=20 [ Tariff-Time-Usage ]=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 Tariff-Time-Change (Time) includes the time in seconds since January 1, = 1900 00:00 UTC when the tariff will change. Tariff-Time-Usage = (enumerated) may have value "before-tariff-change" and = "after-tariff-change". I understood you volunteer to carry out a formal issue for all the = improvements you proposed, is my understanding correct? If yes, and if = you agree with the above described tariff time changes approach, are you = OK to go ahead with a formal issue? I'll approach you with a separate mail to discuss the triggers.=20 Regards=20 Marco=20 ------_=_NextPart_001_01C3A481.B4EAFA44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Diam CC Tariff time changes
Hi=20 Chris,
 
Sorry for not = replying earlier=20 - I'm out of the office this week and only have occasional email = access.
 
No=20 problem at all.
 
I really think that = Tariff=20 change is part of a larger set of events that each G-S-U (quota) is = associated=20 with. And each G-S-U may be associated with 0+ of these events. Each = event set=20 that the G-S-U is associated with is independent of the other G-S-Us. = That may=20 be in a CC message.
 
I=20 think it is fine to add triggers associated to the G-S-U but would treat = the=20 tariff change with a different AVP since it doesn't need to trigger the=20 credit
re-authorization.
 
I had=20 some re-thinking about the triggers and I see some value in adding = triggers=20 associated to the G-S-U as long as whenever one trigger event=20 occurs
the=20 client always initiate the credit re-authorization whithout leaving = quotas=20 running in it (i.e. all quotas are reported to the = server).
So,=20 I think it=20 is fine to add triggers associated to the G-S-U but would treat the = tariff=20 change as logically different funbtionality with a different=20 AVP.
For that reason I=20 would keep the two discussion separated.
 
Regards
Marco  
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 06 November, 2003=20 18:02
To: Stura Marco (NET/Helsinki)
Cc:=20 harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen = Juha-Pekka=20 (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni = (NET/Helsinki);=20 patrik.teppo@ericsson.com; aaa-wg@merit.edu
Subject: RE: = Diam CC=20 Tariff time changes

Hi Marco,

Sorry for not replying earlier - I'm out of the = office this=20 week and only have occasional email access.

I really think that Tariff change is part of a = larger set of=20 events that each G-S-U (quota) is associated with. And each G-S-U may = be=20 associated with 0+ of these events. Each event set that the G-S-U is=20 associated with is independent of the other G-S-Us. That may be in a = CC=20 message.

This is why I was proposing to add a generic event = AVP to the=20 G-S-U (I called it a "trigger" - but the name is not important). Some = examples=20 I gave are: G-S-U idleness, location change, QoS change, threshold = usage=20 level. But there are many more.

Each G-S-U should be able to have a different set of = events=20 (and actions, values to use when  the event occurs) to other = G-S-U in=20 use.

Cheers,
Chris.

Shasta Wireless Development
Nortel=20 Networks

Telephone:
+1 972 684 = 3281=20
ESN 444 3281


-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Thursday, November 06, 2003 8:45 = AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com;=20 juha-pekka.koskinen@nokia.com; john.loughney@nokia.com;=20 Benni.Alexander@nokia.com; patrik.teppo@ericsson.com;=20 aaa-wg@merit.edu

Subject: Diam CC Tariff time changes


Hi Chris,

I think we agreed on the tariff changes issue and=20 principles.
I had some thought on how to = implement=20 this support of tariff time changes in the Diam CC, I would like to = know your=20 opinion whether you agree on the approach.

I guess we need tariff change at the G-S-U level = since it may=20 not apply to all the services or rating groups. The server would grant = quota=20 according to the worst case (i.e. the highest price)

and the client would report units used before and = after the=20 tariff change. This would result in two U-S-U (eventually associated = to the=20 same Service-Identifier or Rating-Group if applicable) in a CCR = command,=20

one USU includes the units consumed before the = tariff time=20 change and the other USU includes the units consumed after the tariff = time=20 change. This mechanism would be optional for client and server and = would not=20 be used for time quotas since

the server is in full control of the time. A client = not=20 supporting the tariff time change mechanism would terminate the = service and=20 send a CCR[Termination] to the server with an appropriate = Termination-Cause=20 (e.g. DIAMETER_BAD_ANSWER) since this affect the cost of the service. = Do we=20 need to indicate to the server more precise reason (e.g. Tariff-time = not=20 supported)?

Granted-Service-Unit ::=3D < AVP Header: TBD > =
          &nbs= p;            = ;          =20 [ Tariff-Time-Change ]
          &nbs= p;            = ;          =20 [ CC-Time ]
          &nbs= p;            = ;          =20 [ CC-Money ]
          &nbs= p;            = ;          =20 [ CC-Total-Octets ]
          &nbs= p;            = ;          =20 [ CC-Input-Octets ]
          &nbs= p;            = ;          =20 [ CC-Output-Octets ]
          &nbs= p;            = ;          =20 [ CC-Service-Specific-Units ]
          &nbs= p;            = ;         =20 *[ Service-Identifier ]
          &nbs= p;            = ;          =20 [ Rating-Group ]
          &nbs= p;    =20

Used-Service-Unit ::=3D < AVP Header: TBD >=20
          &nbs= p;            = ;          =20 [ Tariff-Time-Usage ]
          &nbs= p;            = ;          =20 [ CC-Time ]
          &nbs= p;            = ;          =20 [ CC-Money ]
          &nbs= p;            = ;          =20 [ CC-Total-Octets ]
          &nbs= p;            = ;          =20 [ CC-Input-Octets ]
          &nbs= p;            = ;          =20 [ CC-Output-Octets ]
          &nbs= p;            = ;          =20 [ CC-Service-Specific-Units ]
          &nbs= p;            = ;         =20 *[ Service-Identifier ]
          &nbs= p;            = ;          =20 [ Rating-Group ]

Tariff-Time-Change (Time) includes the time in = seconds since=20 January 1, 1900 00:00 UTC when the tariff will change. = Tariff-Time-Usage=20 (enumerated) may have value "before-tariff-change" and=20 "after-tariff-change".

I understood you volunteer to carry out a formal = issue for all=20 the improvements you proposed, is my understanding correct? If yes, = and if you=20 agree with the above described tariff time changes approach, are you = OK to go=20 ahead with a formal issue?

I'll approach you with a separate mail to discuss = the=20 triggers.

Regards
Marco=20

------_=_NextPart_001_01C3A481.B4EAFA44-- From owner-aaa-wg@merit.edu Thu Nov 6 14:03:43 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 OAA23179 for ; Thu, 6 Nov 2003 14:03:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF38591227; Thu, 6 Nov 2003 09:45:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3941A91229; Thu, 6 Nov 2003 09:45:08 -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 0FCB591227 for ; Thu, 6 Nov 2003 09:45:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 312D45DDD7; Thu, 6 Nov 2003 09:45:04 -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 74CAA5DE06 for ; Thu, 6 Nov 2003 09:45:02 -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 hA6EitY19945 for ; Thu, 6 Nov 2003 16:44:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 16:44:54 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 16:44:53 +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: [AAA-WG]: Diam CC Tariff time changes Date: Thu, 6 Nov 2003 16:44:53 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C80F3@esebe016.ntc.nokia.com> Thread-Topic: Diam CC Tariff time changes Thread-Index: AcOkdIk6RAiJTYKeQJm1lxqgV0ryEg== From: To: Cc: , , , , , , X-OriginalArrivalTime: 06 Nov 2003 14:44:53.0482 (UTC) FILETIME=[89FE6CA0:01C3A474] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, I think we agreed on the tariff changes issue and principles. I had some thought on how to implement this support of tariff time = changes in the Diam CC, I would like to know your opinion whether you agree on the approach. I guess we need tariff change at the G-S-U level since it may not apply = to all the services or rating groups. The server would grant quota according to the worst = case (i.e. the highest price)=20 and the client would report units used before and after the tariff = change. This would result in two U-S-U (eventually associated to the same Service-Identifier or Rating-Group if = applicable) in a CCR command,=20 one USU includes the units consumed before the tariff time change and = the other USU includes the units consumed after the tariff time change. This mechanism would be optional for client and server and would not be = used for time quotas since=20 the server is in full control of the time. A client not supporting the = tariff time change mechanism would terminate the service and send a CCR[Termination] to the server with an = appropriate Termination-Cause (e.g. DIAMETER_BAD_ANSWER) since this affect the cost of the service. Do we need to indicate to the server more precise reason (e.g. = Tariff-time not supported)? Granted-Service-Unit ::=3D < AVP Header: TBD >=20 [ Tariff-Time-Change ] [ 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 =20 Used-Service-Unit ::=3D < AVP Header: TBD >=20 [ Tariff-Time-Usage ] [ 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 Tariff-Time-Change (Time) includes the time in seconds since January 1, = 1900 00:00 UTC when the tariff will change. Tariff-Time-Usage (enumerated) may have value "before-tariff-change" and = "after-tariff-change". I understood you volunteer to carry out a formal issue for all the = improvements you proposed, is my understanding correct? If yes, and if you agree with the above described = tariff time changes approach, are you OK to go ahead with a formal issue? I'll approach you with a separate mail to discuss the triggers. Regards Marco From owner-aaa-wg@merit.edu Thu Nov 6 14:04:39 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 OAA23232 for ; Thu, 6 Nov 2003 14:04:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5F73912D4; Thu, 6 Nov 2003 12:35:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B395912D5; Thu, 6 Nov 2003 12:35: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 0D865912D4 for ; Thu, 6 Nov 2003 12:35:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id E78ED5DF0C; Thu, 6 Nov 2003 12:35:00 -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 267515DDFD for ; Thu, 6 Nov 2003 12:35:00 -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 hA6HYxF15496 for ; Thu, 6 Nov 2003 19:34:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 19:34:58 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 19:34:58 +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: [AAA-WG]: Diam CC re-authorization triggers Date: Thu, 6 Nov 2003 19:34:58 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0333@esebe016.ntc.nokia.com> Thread-Topic: Diam CC re-authorization triggers Thread-Index: AcOkjExztWdH9UV7SimtqpkwPw6A3A== From: To: Cc: , , , , , , X-OriginalArrivalTime: 06 Nov 2003 17:34:58.0885 (UTC) FILETIME=[4CE35750:01C3A48C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable 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=20 are reported to the server). Taking into account the tariff changes the G-S-U would be Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] *[CC-Re-Auth-Trigger ]=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 ] CC-Re-Auth-Trigger ::=3D < AVP Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ] 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.=20 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.=20 In addition a CC-Re-Auth-Reason AVP (Grouped) is included in the CCR to = indicate the cause for=20 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=20 '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]. I believe this way we enable triggers per G-S-U according to your = proposal and in a form consistent with=20 all the functionalities defined in the draft 01. I hope we can all agree on this so that you can formulate the issue.=20 Regards Marco From owner-aaa-wg@merit.edu Thu Nov 6 14:15:04 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 OAA23708 for ; Thu, 6 Nov 2003 14:15:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E18DF91229; Thu, 6 Nov 2003 11:02:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9598912CC; Thu, 6 Nov 2003 11:02:03 -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 D055591229 for ; Thu, 6 Nov 2003 11:02:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4D4E5DDFD; Thu, 6 Nov 2003 11:02:01 -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 351BA5DD9F for ; Thu, 6 Nov 2003 11:02:01 -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 hA6G1l714971; Thu, 6 Nov 2003 08:01:48 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Nov 2003 10:01:49 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E89CC@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: harri.hakala@ericsson.com, leena.mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, Benni.Alexander@nokia.com, patrik.teppo@ericsson.com, aaa-wg@merit.edu Subject: [AAA-WG]: RE: Diam CC Tariff time changes Date: Thu, 6 Nov 2003 10:01:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A47F.4707E54C" 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_01C3A47F.4707E54C Content-Type: text/plain Hi Marco, Sorry for not replying earlier - I'm out of the office this week and only have occasional email access. I really think that Tariff change is part of a larger set of events that each G-S-U (quota) is associated with. And each G-S-U may be associated with 0+ of these events. Each event set that the G-S-U is associated with is independent of the other G-S-Us. That may be in a CC message. This is why I was proposing to add a generic event AVP to the G-S-U (I called it a "trigger" - but the name is not important). Some examples I gave are: G-S-U idleness, location change, QoS change, threshold usage level. But there are many more. Each G-S-U should be able to have a different set of events (and actions, values to use when the event occurs) to other G-S-U in use. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, November 06, 2003 8:45 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: Diam CC Tariff time changes Hi Chris, I think we agreed on the tariff changes issue and principles. I had some thought on how to implement this support of tariff time changes in the Diam CC, I would like to know your opinion whether you agree on the approach. I guess we need tariff change at the G-S-U level since it may not apply to all the services or rating groups. The server would grant quota according to the worst case (i.e. the highest price) and the client would report units used before and after the tariff change. This would result in two U-S-U (eventually associated to the same Service-Identifier or Rating-Group if applicable) in a CCR command, one USU includes the units consumed before the tariff time change and the other USU includes the units consumed after the tariff time change. This mechanism would be optional for client and server and would not be used for time quotas since the server is in full control of the time. A client not supporting the tariff time change mechanism would terminate the service and send a CCR[Termination] to the server with an appropriate Termination-Cause (e.g. DIAMETER_BAD_ANSWER) since this affect the cost of the service. Do we need to indicate to the server more precise reason (e.g. Tariff-time not supported)? Granted-Service-Unit ::= < AVP Header: TBD > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] Used-Service-Unit ::= < AVP Header: TBD > [ Tariff-Time-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] Tariff-Time-Change (Time) includes the time in seconds since January 1, 1900 00:00 UTC when the tariff will change. Tariff-Time-Usage (enumerated) may have value "before-tariff-change" and "after-tariff-change". I understood you volunteer to carry out a formal issue for all the improvements you proposed, is my understanding correct? If yes, and if you agree with the above described tariff time changes approach, are you OK to go ahead with a formal issue? I'll approach you with a separate mail to discuss the triggers. Regards Marco ------_=_NextPart_001_01C3A47F.4707E54C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Diam CC Tariff time changes

Hi Marco,

Sorry for not replying earlier - I'm out of the = office this week and only have occasional email access.

I really think that Tariff change is part of a larger = set of events that each G-S-U (quota) is associated with. And each = G-S-U may be associated with 0+ of these events. Each event set that = the G-S-U is associated with is independent of the other G-S-Us. That = may be in a CC message.

This is why I was proposing to add a generic event = AVP to the G-S-U (I called it a "trigger" - but the name is = not important). Some examples I gave are: G-S-U idleness, location = change, QoS change, threshold usage level. But there are many = more.

Each G-S-U should be able to have a different set of = events (and actions, values to use when  the event occurs) to = other G-S-U in use.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Thursday, November 06, 2003 8:45 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: harri.hakala@ericsson.com; = leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; = john.loughney@nokia.com; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com; aaa-wg@merit.edu

Subject: Diam CC Tariff time changes


Hi Chris,

I think we agreed on the tariff changes issue and = principles.
I had some thought on how to implement this support = of tariff time changes in the Diam CC, I would like to know your = opinion whether you agree on the approach.

I guess we need tariff change at the G-S-U level = since it may not apply to all the services or rating groups. The server = would grant quota according to the worst case (i.e. the highest price) =

and the client would report units used before and = after the tariff change. This would result in two U-S-U (eventually = associated to the same Service-Identifier or Rating-Group if = applicable) in a CCR command,

one USU includes the units consumed before the tariff = time change and the other USU includes the units consumed after the = tariff time change. This mechanism would be optional for client and = server and would not be used for time quotas since

the server is in full control of the time. A client = not supporting the tariff time change mechanism would terminate the = service and send a CCR[Termination] to the server with an appropriate = Termination-Cause (e.g. DIAMETER_BAD_ANSWER) since this affect the cost = of the service. Do we need to indicate to the server more precise = reason (e.g. Tariff-time not supported)?

Granted-Service-Unit ::=3D < AVP Header: TBD > =
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Change ]
          &nb= sp;           &nb= sp;           [ = CC-Time ]
          &nb= sp;           &nb= sp;           [ = CC-Money ]
          &nb= sp;           &nb= sp;           [ = CC-Total-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Input-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Output-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]
          &nb= sp;    

Used-Service-Unit ::=3D < AVP Header: TBD > =
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Usage ]
          &nb= sp;           &nb= sp;           [ = CC-Time ]
          &nb= sp;           &nb= sp;           [ = CC-Money ]
          &nb= sp;           &nb= sp;           [ = CC-Total-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Input-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Output-Octets ]
          &nb= sp;           &nb= sp;           [ = CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]

Tariff-Time-Change (Time) includes the time in = seconds since January 1, 1900 00:00 UTC when the tariff will change. = Tariff-Time-Usage (enumerated) may have value = "before-tariff-change" and = "after-tariff-change".

I understood you volunteer to carry out a formal = issue for all the improvements you proposed, is my understanding = correct? If yes, and if you agree with the above described tariff time = changes approach, are you OK to go ahead with a formal = issue?

I'll approach you with a separate mail to discuss the = triggers.

Regards
Marco

------_=_NextPart_001_01C3A47F.4707E54C-- From owner-aaa-wg@merit.edu Fri Nov 7 07:02:16 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 HAA11601 for ; Fri, 7 Nov 2003 07:02:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C95AF91237; Fri, 7 Nov 2003 07:02:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9320D91238; Fri, 7 Nov 2003 07:02:14 -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 B095B91237 for ; Fri, 7 Nov 2003 07:02:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 897315DDCD; Fri, 7 Nov 2003 07:02:11 -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 CAC1C5DDA9 for ; Fri, 7 Nov 2003 07:02:09 -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 hA7C28A06261 for ; Fri, 7 Nov 2003 14:02:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Nov 2003 14:02:05 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 14:02:04 +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_01C3A526.F51D32DC" Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Fri, 7 Nov 2003 14:02:03 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8100@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: RE: Diam CC re-authorization triggers Thread-Index: AcOkj6rhjclTmut9RX2EWGuSVnTouQAb/+AQ From: To: Cc: , , , , , , X-OriginalArrivalTime: 07 Nov 2003 12:02:04.0641 (UTC) FILETIME=[F5B95510:01C3A526] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A526.F51D32DC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Chris Richards]=20 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.]=20 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. =20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 =20 [Chris Richards]=20 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. =20 =20 [Chris Richards]=20 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:- =20 [Marco St.]=20 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. =20 [Chris Richards]=20 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.]=20 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).=20 =20 When the CC server receives a CCR message it need to parse all the parts = of the message anyway. =20 Chris, I try now to draw some conclusion out of this discussion and how = I see the way to proceed.=20 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. =20 Regards Marco =20 =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 06 November, 2003 19:57 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen = Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni = (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: [AAA-WG]: RE: Diam CC re-authorization triggers Hi Marco,=20 Thanks for the email. We're making excellent progress. I added my = responses below.=20 Cheers,=20 Chris.=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Thursday, November 06, 2003 11:35 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: Diam CC re-authorization triggers=20 Hi Chris,=20 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=20 are reported to the server).=20 [Chris Richards]=20 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]=20 Taking into account the tariff changes the G-S-U would be=20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ]=20 *[CC-Re-Auth-Trigger ]=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 CC-Re-Auth-Trigger ::=3D < AVP Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ]=20 [Chris Richards]=20 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 ::=3D < AVP Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ]=20 [ Trigger-Action]=20 And start defining a set of basic actions. The first of which is:=20 Re-auth U-S-U (send a re-auth for a new quota for G-S-U)=20 Block usage of G-S-U and do not report.=20 ....others TBD=20 With this we have the flexibility to enhance the triggers for future = requirements without changing the AVP.=20 [End Chris Richards]=20 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.=20 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.=20 In addition a CC-Re-Auth-Reason AVP (Grouped) is included in the CCR to = indicate the cause for=20 performing the credit re-authorization, and this is needed not only for = the triggers.=20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 The Reason-Code (enumerated) indicates why the CCR[Update] has been = sent, may be=20 - Validity-Time expired=20 - quota limit reached=20 - Server initiated credit re-authorization (RAR received)=20 - client-driven update (i.e. the one known in draft-01 as=20 'spontaneous update')=20 - CC-Re-Auth-Trigger occured=20 - Final quota limit reached and GST started=20 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]=20 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]=20 I believe this way we enable triggers per G-S-U according to your = proposal and in a form consistent with=20 all the functionalities defined in the draft 01.=20 I hope we can all agree on this so that you can formulate the issue.=20 Regards=20 Marco=20 ------_=_NextPart_001_01C3A526.F51D32DC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Diam CC re-authorization triggers

[Chris Richards] =
But since=20 CC-Re-Auth-Triggers are associated to the specific G-S-U as you agreed = above, it=20 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=20 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=20 specific.

[Marco St.] =
Chris, the drawback of what you describe = above is that=20 it add a lot of complexity to the protocol and it is not consistent with = the DCC=20 functionalities. I already explained in some other mail that if you want = to=20 treat the G-S-U as independent entities you need one credit reservation = for each=20 of the G-S-U, thus you need CC sub-sessions and you already have this=20 flexibility. If the G-S-Us are = derived=20 from the same credit reservation you cannot, and you must not, leave = portion of=20 the same reservation running in the client while = another portion is=20 reported to the server.  = What you=20 propose is breaking the DCC principles, the way I defined the=20 CC-Re-Auth-Triggers are not session specific but service (or = rating-group)=20 specific and it doesn't break this association. What the client does is = to=20 initiate credit re-authorization when a defined trigger event for a = specific service occurs (not when a session event occurs). The server = gets=20 granular information about the service (or rating group) and the trigger = that=20 caused the CCR, based on that it can make whatever decision about the = service in=20 question and it can manipulate the credit reservation accordingly, but = it cannot=20 work properly on the credit reservation if some portion of the=20 reservation is still running in the client. Please note the = structure of=20 the reason code,  it just confirms the granularity I=20 described.
 
CC-Re-Auth-Reason :: < AVP Header: TBD = >
          &nbs= p;         =20 { Reason-Code } =
          &nbs= p;         =20 [ CC-Re-Auth-Trigger ]=20
          &nbs= p;         =20 [ Service-Identifier ]=20
          &nbs= p;         =20 [ Rating-Group ] =
 
[Chris=20 Richards]
Also=20 note that the triggers do not have to cause a CCR[Update]. It may be = that an=20 event causes the CC client to perform some other action that does not=20 immediately lead to a CCR[Update] for the G-S-U.
 
 
 [Chris = Richards]
As well as a Trigger-Id and = Trigger-Value,=20 there seems to be a need for an (optional) Trigger-Action since it m ay = be that=20 the CC Client might not always need to re-auth for the trigger. For = example, it=20 may be to Unblock the usage of a temporarily blocked G-S-U after a = defined time=20 period (Just thinking aloud). The point is that the protocol should have = the=20 flexibility for this. So, I = propose:-
 
[Marco St.] =
The=20 DCC is a credit control protocol, it only need to be concerned with = triggers=20 that affect the rating of the service and thus require a credit = re-authorization=20 to be performed. Whenever those triggers occur the action is always = credit=20 re-authorization, as I explained in some other mail as well, because = this is why=20 we have a credit control protocol. Other type of triggers, not rating = related,=20 and associated actions fall within a different category than credit = control and=20 need to be defined by other means, those means are not in the scope of = this=20 architecture and specification. For instance, we assume that = service-identifiers=20 and associated service description (whatever the service description is = e.g. IP=20 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=20 cause some other action than credit = re-authorization.
 

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

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

[Marco St.] =
As you=20 may have noticed, the CC-Re-Auth-Reason is needed also when=20 multiple services in one CC session are not used at all and for = events that=20 are session specific (e.g. RAR received or Validity-Time expired). When=20 multiple services in one CC session are used and a service specific = trigger=20 is causing the credit re-authorization, the structure of the=20 CC-Re-Auth-Reason AVP enables for finer granularity than just session = (as=20 previously discussed). 
 
When=20 the CC server receives a CCR message it need to parse all the parts of = the=20 message anyway.
 
Chris,=20 I try now to draw some conclusion out of this discussion and how I see = the way=20 to proceed. 
We=20 need capabilities to define credit re-authorization triggers on a = per=20 service (or rating group) basis, those triggers are events that affect = the=20 rating (cost) of the service other type of triggers and actions are = not in=20 the scope of this specification. Since the DCC is a general = solution to the=20 real-time cost and credit control,  multiple services in one CC = session is=20 just one part of it,  I have been striking a balance between your = proposal=20 and the DCC principles hoping to create something which would be = relevant to the=20 whole. Perhaps we may improve in some details but I really believe that = the=20 principle I described fits seamlessly and consistently, it=20 also satisfies the requirements without adding too much complexity. = I would=20 then go ahead with this proposal, that has your proposal as solid = base, and=20 start to define what are these Trigger-Ids and their = values.
 
Regards
Marco
 
 
 -----Original = Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext=20 Christopher Richards
Sent: 06 November, 2003 = 19:57
To: Stura=20 Marco (NET/Helsinki)
Cc: harri.hakala@ericsson.com;=20 leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney = John=20 (NRC/Helsinki); Alexander Benni (NET/Helsinki); = patrik.teppo@ericsson.com;=20 aaa-wg@merit.edu
Subject: [AAA-WG]: RE: Diam CC = re-authorization=20 triggers

Hi Marco,

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

Cheers,
Chris.

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Thursday, November 06, 2003 11:35 = AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com;=20 juha-pekka.koskinen@nokia.com; john.loughney@nokia.com;=20 Benni.Alexander@nokia.com; patrik.teppo@ericsson.com;=20 aaa-wg@merit.edu

Subject: Diam CC re-authorization triggers =


Hi Chris,

after the debate on your proposal whether triggers = should be=20 per G-S-U or per CC command, as stated in a previous mail, I changed = mindset=20 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=20 somewhat simpler form, I would propose some changes to your initial = proposal=20 in order to integrate this new functionality seamlessly and = consistently with=20 all the functionalities already defined in the draft 01.

The server may include one or more = CC-Re-Auth-Triggers=20 associated to the G-S-U as in your proposal. Whenever one trigger = event occurs=20 the client sends a CCR[Update]. The CCR[Update] includes as many U-S-U = as many=20 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,=20 it only makes sense to include the U-S-U associated to that G-S-U = which was=20 triggered. Triggers are specific to the G-S-U in which they are in. If = all the=20 G-S-U must send a U-S-U when any trigger event is reached, it breaks = the=20 association - and effectively makes the trigger session specific - not = G-S-U=20 specific.

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

[End Chris Richards]

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

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

CC-Re-Auth-Trigger ::=3D < AVP Header: TBD >=20
          &nbs= p;           =20 { Trigger-Id }
          &nbs= p;           =20 [ Trigger-Value ]

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

CC-Re-Auth-Trigger ::=3D < AVP Header: TBD >=20
          &nbs= p;           =20 { Trigger-Id }
          &nbs= p;           =20 [ Trigger-Value ]
          &nbs= p;           =20 [ Trigger-Action]

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

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

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

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

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

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

CC-Re-Auth-Reason :: < AVP Header: TBD = >=20
          &nbs= p;         =20 { Reason-Code }
          &nbs= p;         =20 [ CC-Re-Auth-Trigger ]
          &nbs= p;         =20 [ Service-Identifier ]
          &nbs= p;         =20 [ Rating-Group ]

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

- Validity-Time expired
- = quota limit=20 reached
- Server initiated credit = re-authorization=20 (RAR received)
- client-driven update (i.e. = the one=20 known in draft-01 as
 'spontaneous=20 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=20 CC-Re-Auth-Trigger AVP is included to indicate what is the trigger = that caused=20 the CCR[Update].

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

[Chris Richards]
Thank you = for=20 including the Reason-Code. However, should it not be part of the U-S-U = to keep=20 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=20 U-S-U.

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

[End Chris Richards]

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

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

Regards
Marco=20





------_=_NextPart_001_01C3A526.F51D32DC-- From owner-aaa-wg@merit.edu Fri Nov 7 10:51:27 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 KAA19654 for ; Fri, 7 Nov 2003 10:51:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E686091240; Fri, 7 Nov 2003 10:51:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0B49912B7; Fri, 7 Nov 2003 10:51:20 -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 93D1491240 for ; Fri, 7 Nov 2003 10:51:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F64D5DEBC; Fri, 7 Nov 2003 10:51:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E8FB75DD8F for ; Fri, 7 Nov 2003 10:51:18 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA7FDbx24603 for ; Fri, 7 Nov 2003 07:13:37 -0800 Date: Fri, 7 Nov 2003 07:13:37 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 430: 3GPP2 comments on NASREQ-13 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 430: 3GPP2 comments on NASREQ-13 Submitter name: Elizabeth Kidwell Submitter email address: ekidwell@lucent.com Date first submitted: November 6, 2003 Reference: Document: NASREQ-13 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Please find attached correspondence from 3GPP2 providing comments on the nasreq ID: http://www.drizzle.com/~aboba/AAA/3gpp2-nas.pdf From owner-aaa-wg@merit.edu Fri Nov 7 11:54:15 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 LAA21830 for ; Fri, 7 Nov 2003 11:54:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC73791239; Fri, 7 Nov 2003 11:54:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A84EC912B7; Fri, 7 Nov 2003 11:54:09 -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 C294691239 for ; Fri, 7 Nov 2003 11:54:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF8D95DF00; Fri, 7 Nov 2003 11:54:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 41E365DDA1 for ; Fri, 7 Nov 2003 11:54:08 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA7GGR028302 for ; Fri, 7 Nov 2003 08:16:27 -0800 Date: Fri, 7 Nov 2003 08:16:27 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: EDITOR REQUEST: issues status update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm cleaning up the issues page and would like to get up to date status on all current Diameter documents. If you are the editor of a Diameter draft, please look at the Issues page: http://www.drizzle.com/~aboba/AAA/issues.html and send me email with answers to the following questions: a. Is the Issue list up to date? b. Is the status of the issues accurate? If not, please provide status. Thanks! From owner-aaa-wg@merit.edu Mon Nov 10 03:02: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 DAA12212 for ; Mon, 10 Nov 2003 03:02:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C4259125B; Mon, 10 Nov 2003 03:02:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05E939125C; Mon, 10 Nov 2003 03:02:18 -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 C1D2A9125B for ; Mon, 10 Nov 2003 03:02:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB00D5DE6C; Mon, 10 Nov 2003 03:02:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 531245DE13 for ; Mon, 10 Nov 2003 03:02:15 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAA82DI2011384; Mon, 10 Nov 2003 09:02:13 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Nov 2003 09:02:35 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'crich@nortelnetworks.com'" , "'marco.stura@nokia.com'" 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: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 09:01:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A760.CB0D1D60" 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_01C3A760.CB0D1D60 Content-Type: text/plain; charset="iso-8859-1" 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 7. marraskuuta 2003 14:02 To: crich@nortelnetworks.com Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu 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. CC-Re-Auth-Reason :: < AVP Header: TBD > { Reason-Code } [ CC-Re-Auth-Trigger ] [ Service-Identifier ] [ Rating-Group ] [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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 06 November, 2003 19:57 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu 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: marco.stura@nokia.com [ mailto:marco.stura@nokia.com ] Sent: Thursday, November 06, 2003 11:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu 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 ------_=_NextPart_001_01C3A760.CB0D1D60 Content-Type: text/html; charset="iso-8859-1" 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 7. marraskuuta 2003 14:02
To: crich@nortelnetworks.com
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu
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.
 
CC-Re-Auth-Reason :: < AVP Header: TBD >
                     { Reason-Code }
                     [ CC-Re-Auth-Trigger ]
                     [ Service-Identifier ]
                     [ Rating-Group ]
 
[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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu
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: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Thursday, November 06, 2003 11:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu

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





------_=_NextPart_001_01C3A760.CB0D1D60-- From owner-aaa-wg@merit.edu Mon Nov 10 05:09: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 FAA14657 for ; Mon, 10 Nov 2003 05:09:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BEACF9125E; Mon, 10 Nov 2003 05:09:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 865449125F; Mon, 10 Nov 2003 05:09:10 -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 711F69125E for ; Mon, 10 Nov 2003 05:09:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 426BF5DE16; Mon, 10 Nov 2003 05:09:07 -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 113835DE05 for ; Mon, 10 Nov 2003 05:09:05 -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 hAAA93K01301 for ; Mon, 10 Nov 2003 12:09:03 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 12:08:57 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 12:08:57 +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_01C3A772.A738EEC6" Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 12:08:57 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B033B@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: RE: Diam CC re-authorization triggers Thread-Index: AcOnYQlq4t93V9fpTP6Swv9pTiSsAgAA+mcQ From: To: , Cc: , , , , , X-OriginalArrivalTime: 10 Nov 2003 10:08:57.0928 (UTC) FILETIME=[A7C45C80:01C3A772] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A772.A738EEC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, Leena; =20 [Leena Mat.] 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.=20 =20 [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]? =20 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? =20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 *[ CC-Re-Auth-Trigger-Event ]=20 =20 CC-Re-Auth-Trigger-Event :: < AVP Header: TBD > { CC-Re-Auth-Trigger } [ Service-Identifier ]=20 [ Rating-Group ]=20 =20 Regards Marco =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Leena Mattila (TU/LMF) Sent: 10 November, 2003 10:01 To: 'crich@nortelnetworks.com'; 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); 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Hi Chris, Marco, =20 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.=20 =20 BR, Leena -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 7. marraskuuta 2003 14:02 To: crich@nortelnetworks.com Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers [Chris Richards]=20 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.]=20 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. =20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 =20 [Chris Richards]=20 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. =20 =20 [Chris Richards]=20 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:- =20 [Marco St.]=20 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. =20 [Chris Richards]=20 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.]=20 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).=20 =20 When the CC server receives a CCR message it need to parse all the parts = of the message anyway. =20 Chris, I try now to draw some conclusion out of this discussion and how = I see the way to proceed.=20 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. =20 Regards Marco =20 =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 06 November, 2003 19:57 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen = Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni = (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: [AAA-WG]: RE: Diam CC re-authorization triggers Hi Marco,=20 Thanks for the email. We're making excellent progress. I added my = responses below.=20 Cheers,=20 Chris.=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Thursday, November 06, 2003 11:35 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: Diam CC re-authorization triggers=20 Hi Chris,=20 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=20 are reported to the server).=20 [Chris Richards]=20 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]=20 Taking into account the tariff changes the G-S-U would be=20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ]=20 *[CC-Re-Auth-Trigger ]=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 CC-Re-Auth-Trigger ::=3D < AVP Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ]=20 [Chris Richards]=20 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 ::=3D < AVP Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ]=20 [ Trigger-Action]=20 And start defining a set of basic actions. The first of which is:=20 Re-auth U-S-U (send a re-auth for a new quota for G-S-U)=20 Block usage of G-S-U and do not report.=20 ....others TBD=20 With this we have the flexibility to enhance the triggers for future = requirements without changing the AVP.=20 [End Chris Richards]=20 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.=20 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.=20 In addition a CC-Re-Auth-Reason AVP (Grouped) is included in the CCR to = indicate the cause for=20 performing the credit re-authorization, and this is needed not only for = the triggers.=20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 The Reason-Code (enumerated) indicates why the CCR[Update] has been = sent, may be=20 - Validity-Time expired=20 - quota limit reached=20 - Server initiated credit re-authorization (RAR received)=20 - client-driven update (i.e. the one known in draft-01 as=20 'spontaneous update')=20 - CC-Re-Auth-Trigger occured=20 - Final quota limit reached and GST started=20 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]=20 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]=20 I believe this way we enable triggers per G-S-U according to your = proposal and in a form consistent with=20 all the functionalities defined in the draft 01.=20 I hope we can all agree on this so that you can formulate the issue.=20 Regards=20 Marco=20 ------_=_NextPart_001_01C3A772.A738EEC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Diam CC re-authorization triggers
Hi=20 Chris, Leena;
 
[Leena=20 Mat.]
I agree with = Marco regarding=20 how to treat multiple services. The reason for Issue=20 436 was to combine a credit = reservation for several=20 services (tariff groups) into one, and treat it as one reservation. We = should=20 not start splitting this up into several independent reservations, thus = creating=20 a competing mechanism for sub-sessions and violating the principles = in the base. I'd like to keep the application as simple as = possible,=20 without too many options because too much flexibility causes = tricky=20 and error-prone design. 
 
[Marco=20 St.]
If we agree to include = CC-Re-Auth-Triggers=20 per service or rating-group and we allow multiple triggers per G-S-U, = I'm=20 wondering if we could lead in to situations=20 where
more than one triggers are met = at the same=20 time. If such an event occurs what the client should do then? Should we = define=20 triggers priority or the client simply reports all the triggers=20 that occured=20 concurrently in the CCR[Update]?
 
If we want to report all the = triggers, the=20 CC-Re-Auth-Reason AVP=20 structure I proposed it may not be good enough. = Perhaps it=20 could be something like this?
 
CC-Re-Auth-Reason :: < AVP Header: TBD = >
          &nbs= p;         =20 { Reason-Code } 
          &nbs= p;        *[=20 CC-Re-Auth-Trigger-Event ] 
          &nbs= p;         =20
CC-Re-Auth-Trigger-Event :: < AVP = Header: TBD=20 >
          &nbs= p;          {=20 CC-Re-Auth-Trigger = }
          &nbs= p;         =20 [ Service-Identifier ]=20
          &nbs= p;         =20 [ Rating-Group ]=20
 
Regards
Marco
 
 -----Original=20 Message-----
From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Leena Mattila=20 (TU/LMF)
Sent: 10 November, 2003 10:01
To:=20 'crich@nortelnetworks.com'; Stura Marco (NET/Helsinki)
Cc: = Harri=20 Hakala (TU/LMF); Koskinen Juha-Pekka (NET/Tampere); Loughney John=20 (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo (KA/EAB); = 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: RE: Diam CC=20 re-authorization triggers

Hi=20 Chris, Marco,
 
I agree with Marco regarding how to treat multiple services. = The reason=20 for Issue 436 was to combine=20 a credit reservation for several services (tariff groups) into one, = and treat=20 it as one reservation. We should not start splitting this up into = several=20 independent reservations, thus creating a competing mechanism for=20 sub-sessions and violating the principles in the base. = I'd like=20 to keep the application as simple as possible, without too many = options=20 because too much flexibility causes tricky and error-prone=20 design. 
 
BR,
Leena
-----Original Message-----
From: = marco.stura@nokia.com=20 [mailto:marco.stura@nokia.com]
Sent: 7. marraskuuta 2003=20 14:02
To: crich@nortelnetworks.com
Cc: Harri = Hakala=20 (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com;=20 john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo = (KA/EAB);=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: RE: Diam CC=20 re-authorization triggers

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

[Marco St.] =
Chris, the drawback of what you describe = above is=20 that it add a lot of complexity to the protocol and it is not = consistent=20 with the DCC functionalities. I already explained in some other mail = that if=20 you want to treat the G-S-U as independent entities you need one = credit=20 reservation for each of the G-S-U, thus you need CC sub-sessions and = you=20 already have this flexibility. If the=20 G-S-Us are derived from the same credit reservation you cannot, and = you must=20 not, leave portion of the same reservation running in the client = while=20 another portion is reported to the server.  What you propose is = breaking the=20 DCC principles, the way I defined the CC-Re-Auth-Triggers are not = session=20 specific but service (or rating-group) specific and it doesn't break = this=20 association. What the client does is to initiate credit = re-authorization=20 when a defined trigger event for a specific service occurs (not = when a=20 session event occurs). The server gets granular information about = the=20 service (or rating group) and the trigger that caused the CCR, based = on that=20 it can make whatever decision about the service in question and it = can=20 manipulate the credit reservation accordingly, but it cannot work = properly=20 on the credit reservation if some portion of the = reservation is=20 still running in the client. Please note the structure of the reason = code,=20  it just confirms the granularity I=20 described.
 
CC-Re-Auth-Reason :: < AVP Header: TBD = >
          &nbs= p;         =20 { Reason-Code }=20
          &nbs= p;         =20 [ CC-Re-Auth-Trigger ]=20
          &nbs= p;         =20 [ Service-Identifier ]=20
          &nbs= p;         =20 [ Rating-Group ] =
 
[Chris Richards]
Also note that the triggers do not have = to cause a=20 CCR[Update]. It may be that an event causes the CC client to perform = some=20 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=20 need for an (optional) Trigger-Action since it m ay be that the CC = Client=20 might not always need to re-auth for the trigger. For example, it = may be to=20 Unblock the usage of a temporarily blocked G-S-U after a defined = time period=20 (Just thinking aloud). The point is that the protocol should have = the=20 flexibility for this. So, I=20 propose:-
 
[Marco St.] =
The DCC is a credit control protocol, it only need to be = concerned=20 with triggers that affect the rating of the service and thus require = a=20 credit re-authorization to be performed. Whenever those triggers = occur the=20 action is always credit re-authorization, as I explained in some = other mail=20 as well, because this is why we have a credit control protocol. = Other type=20 of triggers, not rating related, and associated actions fall within = a=20 different category than credit control and need to be defined by = other=20 means, those means are not in the scope of this architecture and=20 specification. For instance, we assume that service-identifiers and=20 associated service description (whatever the service description is = e.g. IP=20 Filters) are provisioned by another entity (e.g. AAA server or a = sort of=20 Charging Policy server), this entity may also define associated = triggers=20 that cause some other action than credit=20 re-authorization.
 

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

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

[Marco St.]=20
As=20 you may have noticed, the CC-Re-Auth-Reason is needed also when=20 multiple services in one CC session are not used at all and for = events=20 that are session specific (e.g. RAR received or Validity-Time = expired). When=20 multiple services in one CC session are used and a service = specific=20 trigger is causing the credit re-authorization, the structure = of the=20 CC-Re-Auth-Reason AVP enables for finer granularity than just = session (as=20 previously discussed). 
 
When the CC server receives a CCR message it need to parse = all the=20 parts of the message anyway.
 
Chris, I try now to draw some conclusion out of this = discussion and=20 how I see the way to proceed. 
We=20 need capabilities to define credit re-authorization triggers on = a per=20 service (or rating group) basis, those triggers are events that = affect the=20 rating (cost) of the service other type of triggers and actions = are not=20 in the scope of this specification. Since the DCC is a general = solution=20 to the real-time cost and credit control,  multiple services in = one CC=20 session is just one part of it,  I have been striking a balance = between=20 your proposal and the DCC principles hoping to create something = which would=20 be relevant to the whole. Perhaps we may improve in some details but = I=20 really believe that the principle I described fits seamlessly = and=20 consistently, it also satisfies the requirements without adding = too=20 much complexity. I would then go ahead with this proposal, that has = your=20 proposal as solid base, and start to define what are these = Trigger-Ids=20 and their values.
 
Regards
Marco
 
 
 -----Original=20 Message-----
From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher=20 Richards
Sent: 06 November, 2003 19:57
To: Stura = Marco=20 (NET/Helsinki)
Cc: harri.hakala@ericsson.com;=20 leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); = Loughney John=20 (NRC/Helsinki); Alexander Benni (NET/Helsinki); = patrik.teppo@ericsson.com;=20 aaa-wg@merit.edu
Subject: [AAA-WG]: RE: Diam CC = re-authorization=20 triggers

Hi Marco,

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

Cheers,
Chris. =

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Thursday, November 06, 2003 11:35 = AM=20
To: Richards, Christopher = [RICH2:2Q40:EXCH]=20
Cc: harri.hakala@ericsson.com;=20 leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com;=20 john.loughney@nokia.com; Benni.Alexander@nokia.com;=20 patrik.teppo@ericsson.com; aaa-wg@merit.edu

Subject: Diam CC re-authorization = triggers


Hi Chris,

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

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

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

are reported to the server).

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

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

[End Chris Richards]

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

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

CC-Re-Auth-Trigger ::=3D < AVP Header: TBD = >=20
          &nbs= p;           =20 { Trigger-Id }
          &nbs= p;           =20 [ Trigger-Value ]

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

CC-Re-Auth-Trigger ::=3D < AVP Header: TBD = >=20
          &nbs= p;           =20 { Trigger-Id }
          &nbs= p;           =20 [ Trigger-Value ]
          &nbs= p;           =20 [ Trigger-Action]

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

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

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

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

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

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

CC-Re-Auth-Reason :: < AVP Header: TBD = >=20
          &nbs= p;         =20 { Reason-Code }
          &nbs= p;         =20 [ CC-Re-Auth-Trigger ]
          &nbs= p;         =20 [ Service-Identifier ]
          &nbs= p;         =20 [ Rating-Group ]

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

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

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

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

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

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

[End Chris Richards]

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

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

Regards
Marco=20 =





= ------_=_NextPart_001_01C3A772.A738EEC6-- From owner-aaa-wg@merit.edu Mon Nov 10 06:04:12 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 GAA15536 for ; Mon, 10 Nov 2003 06:04:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A0D79125F; Mon, 10 Nov 2003 06:04:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3D1A91260; Mon, 10 Nov 2003 06:04:00 -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 4A5EB9125F for ; Mon, 10 Nov 2003 06:03:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 308795DDB1; Mon, 10 Nov 2003 06:03:58 -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 8FB695DDC2 for ; Mon, 10 Nov 2003 06:03:56 -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 hAAB3tSs004116; Mon, 10 Nov 2003 12:03:55 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Nov 2003 12:04:17 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'marco.stura@nokia.com'" , "'crich@nortelnetworks.com'" 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]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 12:02:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A77A.2FBAE902" 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_01C3A77A.2FBAE902 Content-Type: text/plain; charset="iso-8859-1" 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 10. marraskuuta 2003 12:09 To: Leena Mattila (TU/LMF); crich@nortelnetworks.com 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: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Hi Chris, Leena; [Leena Mat.] 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. [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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Leena Mattila (TU/LMF) Sent: 10 November, 2003 10:01 To: 'crich@nortelnetworks.com'; 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); 'aaa-wg@merit.edu' 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 7. marraskuuta 2003 14:02 To: crich@nortelnetworks.com Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu 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. CC-Re-Auth-Reason :: < AVP Header: TBD > { Reason-Code } [ CC-Re-Auth-Trigger ] [ Service-Identifier ] [ Rating-Group ] [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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 06 November, 2003 19:57 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu 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: marco.stura@nokia.com [ mailto:marco.stura@nokia.com ] Sent: Thursday, November 06, 2003 11:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu 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 ------_=_NextPart_001_01C3A77A.2FBAE902 Content-Type: text/html; charset="iso-8859-1" RE: Diam CC re-authorization triggers
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: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 10. marraskuuta 2003 12:09
To: Leena Mattila (TU/LMF); crich@nortelnetworks.com
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: RE: [AAA-WG]: RE: Diam CC re-authorization triggers

Hi Chris, Leena;
 
[Leena Mat.]
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. 
 
[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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Leena Mattila (TU/LMF)
Sent: 10 November, 2003 10:01
To: 'crich@nortelnetworks.com'; 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); 'aaa-wg@merit.edu'
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: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 7. marraskuuta 2003 14:02
To: crich@nortelnetworks.com
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu
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.
 
CC-Re-Auth-Reason :: < AVP Header: TBD >
                     { Reason-Code }
                     [ CC-Re-Auth-Trigger ]
                     [ Service-Identifier ]
                     [ Rating-Group ]
 
[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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu
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: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Thursday, November 06, 2003 11:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu

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





------_=_NextPart_001_01C3A77A.2FBAE902-- From owner-aaa-wg@merit.edu Mon Nov 10 06:21: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 GAA15910 for ; Mon, 10 Nov 2003 06:21:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52DFA91264; Mon, 10 Nov 2003 06:21:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1669991263; Mon, 10 Nov 2003 06:21:12 -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 8CCBE91265 for ; Mon, 10 Nov 2003 06:21:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 773FB5DE5C; Mon, 10 Nov 2003 06:21:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id D07635DE51 for ; Mon, 10 Nov 2003 06:21:10 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAABL9I2003213; Mon, 10 Nov 2003 12:21:10 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Nov 2003 12:21:32 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "Leena Mattila (TU/LMF)" , "'crich@nortelnetworks.com'" , "'marco.stura@nokia.com'" Cc: "'juha-pekka.koskinen@nokia.com'" , "'john.loughney@nokia.com'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 11:40:59 +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, 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 >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: 'crich@nortelnetworks.com'; 'marco.stura@nokia.com' 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: 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 7. marraskuuta 2003 14:02 To: crich@nortelnetworks.com Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu 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. CC-Re-Auth-Reason :: < AVP Header: TBD > { Reason-Code } [ CC-Re-Auth-Trigger ] [ Service-Identifier ] [ Rating-Group ] [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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 06 November, 2003 19:57 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, November 06, 2003 11:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu 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 owner-aaa-wg@merit.edu Mon Nov 10 06:36:15 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 GAA16290 for ; Mon, 10 Nov 2003 06:36:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C2A391263; Mon, 10 Nov 2003 06:36:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05C9F91265; Mon, 10 Nov 2003 06:36:13 -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 3521191263 for ; Mon, 10 Nov 2003 06:36:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C1CB5DF3D; Mon, 10 Nov 2003 06:36:12 -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 0BF475DE72 for ; Mon, 10 Nov 2003 06:36:11 -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 hAABa9s18516 for ; Mon, 10 Nov 2003 13:36:10 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 13:36:09 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Nov 2003 13:36: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_01C3A77E.D5628492" Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 13:36:08 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B033C@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: RE: Diam CC re-authorization triggers Thread-Index: AcOnelkIQmRp3x9RTEKi7A3/cv6ztwAAdGgw From: To: , Cc: , , , , , X-OriginalArrivalTime: 10 Nov 2003 11:36:08.0965 (UTC) FILETIME=[D5B54350:01C3A77E] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A77E.D5628492 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 [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. =20 [Marco St.] I'm happy with the first option. =20 [Leena Matt.] 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. =20 [Marco St.] I think you are right Leena, it'd probably better to include multiple = instances of the CC-Re-Auth-Reason AVP. =20 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. =20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 Regards Marco ------_=_NextPart_001_01C3A77E.D5628492 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Diam CC re-authorization triggers
Hi,
 
[Leena=20 Matt.]
Either=20 the client reports the first event that causes the CCR to be sent, or = then it=20 lists them all. I'd prefer the first the option - this would follow the=20 principles of how usually also errors are reported: even though multiple errors = could be=20 detected, only the first that is  encountered is=20 reported.
 
[Marco=20 St.]
I'm=20 happy with the first option.
 
[Leena Matt.]
BTW, if the second option is chosen = (i.e. report=20 them all) wouldn't it be possible that the Reason-Code would need to be = repeated=20 as well? It could happen = that at the=20 very same moment the validity-time expires, the quota limit is = reached and=20 the end-user changes location causing a QoS Change.... In that = cases three=20 Reason-Codes would be needed and two trigger-events. I'd in that case = repeat the=20 whole CC-Re-Auth-Reason in the CCR without introducing the CC-Re-Auth-Trigger-Event=20 sub-structure.
 
[Marco=20 St.]
I think you = are right=20 Leena, it'd probably better to include multiple instances of the=20 CC-Re-Auth-Reason AVP.
 
If Chris is of the same = opinion to follow the principles of how usually errors are = reported, I=20 think we can then go with the single CC-Re-Auth-Reason=20 AVP.
 
CC-Re-Auth-Reason :: < AVP Header: TBD = >=20
           &nb= sp;        =20 { Reason-Code }=20
           &nb= sp;        =20 [ CC-Re-Auth-Trigger ]=20
           &nb= sp;        =20 [ Service-Identifier ]=20
           &nb= sp;        =20 [ Rating-Group ]
Regards
Marco
------_=_NextPart_001_01C3A77E.D5628492-- From owner-aaa-wg@merit.edu Mon Nov 10 07:00:15 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 HAA16742 for ; Mon, 10 Nov 2003 07:00:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3669191275; Mon, 10 Nov 2003 06:57:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3F4F91269; Mon, 10 Nov 2003 06:57:11 -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 023D991275 for ; Mon, 10 Nov 2003 06:56:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD9195DDEF; Mon, 10 Nov 2003 06:56:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 61ADB5DD94 for ; Mon, 10 Nov 2003 06:56:17 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAABu3C28653; Mon, 10 Nov 2003 05:56:04 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 05:56:04 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8A06@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , "Leena Mattila (TU/LMF)" , "'marco.stura@nokia.com'" Cc: "'juha-pekka.koskinen@nokia.com'" , "'john.loughney@nokia.com'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 05:55:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A781.97CEAD30" 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_01C3A781.97CEAD30 Content-Type: text/plain 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:harri.hakala@ericsson.com] Sent: Monday, November 10, 2003 4:41 AM To: Leena Mattila (TU/LMF); Richards, Christopher [RICH2:2Q40:EXCH]; 'marco.stura@nokia.com' Cc: 'juha-pekka.koskinen@nokia.com'; 'john.loughney@nokia.com'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'aaa-wg@merit.edu' 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 >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: 'crich@nortelnetworks.com'; 'marco.stura@nokia.com' 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: 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 7. marraskuuta 2003 14:02 To: crich@nortelnetworks.com Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu 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. CC-Re-Auth-Reason :: < AVP Header: TBD > { Reason-Code } [ CC-Re-Auth-Trigger ] [ Service-Identifier ] [ Rating-Group ] [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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 06 November, 2003 19:57 To: Stura Marco (NET/Helsinki) Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, November 06, 2003 11:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu 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 ------_=_NextPart_001_01C3A781.97CEAD30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: RE: Diam CC re-authorization triggers

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:harri.hakala@ericsson.c= om]
Sent: Monday, November 10, 2003 4:41 AM
To: Leena Mattila (TU/LMF); Richards, Christopher = [RICH2:2Q40:EXCH]; 'marco.stura@nokia.com'
Cc: 'juha-pekka.koskinen@nokia.com'; = 'john.loughney@nokia.com'; 'Benni.Alexander@nokia.com'; Patrik Teppo = (KA/EAB); 'aaa-wg@merit.edu'

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
>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: 'crich@nortelnetworks.com'; = 'marco.stura@nokia.com'
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: 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: marco.stura@nokia.com [mailto:marco.stura@nokia.com]<= /FONT>
Sent: 7. marraskuuta 2003 14:02
To: crich@nortelnetworks.com
Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); = aaa-wg@merit.edu

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.

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

[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: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of ext Christopher Richards
Sent: 06 November, 2003 19:57
To: Stura Marco (NET/Helsinki)
Cc: harri.hakala@ericsson.com; = leena.mattila@ericsson.com; Koskinen Juha-Pekka (NET/Tampere); Loughney = John (NRC/Helsinki); Alexander Benni (NET/Helsinki); = patrik.teppo@ericsson.com; aaa-wg@merit.edu

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: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Thursday, November 06, 2003 11:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: harri.hakala@ericsson.com; = leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com; = john.loughney@nokia.com; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com; aaa-wg@merit.edu

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 ::=3D < AVP Header: 431 > =
          &nb= sp;           &nb= sp;  [ Tariff-Time-Change ]
          &nb= sp;           &nb= sp; *[CC-Re-Auth-Trigger ]
          &nb= sp;           &nb= sp;  [ CC-Time ]
          &nb= sp;           &nb= sp;  [ CC-Money ]
          &nb= sp;           &nb= sp;  [ CC-Total-Octets ]
          &nb= sp;           &nb= sp;  [ CC-Input-Octets ]
          &nb= sp;           &nb= sp;  [ CC-Output-Octets ]
          &nb= sp;           &nb= sp;  [ CC-Service-Specific-Units ]
          &nb= sp;           &nb= sp; *[ Service-Identifier ]
          &nb= sp;           &nb= sp;  [ Rating-Group ]
CC-Re-Auth-Trigger ::=3D < AVP Header: TBD > =
          &nb= sp;            { = Trigger-Id }
          &nb= sp;            [ = 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 ::=3D < AVP Header: TBD >

          &nb= sp;            { = Trigger-Id }
          &nb= sp;            [ = Trigger-Value ]
          &nb= sp;            [ = 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 > =
          &nb= sp;          { Reason-Code = }
          &nb= sp;          [ = CC-Re-Auth-Trigger ]
          &nb= sp;          [ = Service-Identifier ]
          &nb= sp;          [ = 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

------_=_NextPart_001_01C3A781.97CEAD30-- From owner-aaa-wg@merit.edu Mon Nov 10 07:39:24 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 HAA17749 for ; Mon, 10 Nov 2003 07:39:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 909D291266; Mon, 10 Nov 2003 07:39:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A4C891268; Mon, 10 Nov 2003 07:39:20 -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 26A1D91266 for ; Mon, 10 Nov 2003 07:39:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FB2A5DE32; Mon, 10 Nov 2003 07:39:17 -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 4A5F55DE13 for ; Mon, 10 Nov 2003 07:39:15 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAACdEK23697 for ; Mon, 10 Nov 2003 14:39:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 14:39:06 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 14:39:06 +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_01C3A787.A1034952" Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 14:39:06 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B033D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: RE: Diam CC re-authorization triggers Thread-Index: AcOngaOqaDTZdk+BRMOeKvPRjb/9LgAAlKWA From: To: , , Cc: , , , , X-OriginalArrivalTime: 10 Nov 2003 12:39:06.0706 (UTC) FILETIME=[A16ACB20:01C3A787] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A787.A1034952 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 [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. =20 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? =20 [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. =20 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. =20 [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.=20 =20 Transport is not handled by the DCC application at all, the DCC just = uses the Diameter transport according to RFC 3539 and RFC 3588. =20 Regards Marco. =20 -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] 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); = 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers Hi Harri, Leena, Marco,=20 Thanks for the responses over the weekend.=20 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.=20 Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 -----Original Message-----=20 From: Harri Hakala (TU/LMF) [ mailto:harri.hakala@ericsson.com]=20 Sent: Monday, November 10, 2003 4:41 AM=20 To: Leena Mattila (TU/LMF); Richards, Christopher [RICH2:2Q40:EXCH]; = 'marco.stura@nokia.com'=20 Cc: 'juha-pekka.koskinen@nokia.com'; 'john.loughney@nokia.com'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers=20 Hi Chris, Marco & Leena,=20 >[Marco St.]=20 >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=20 >re-authorization triggers on a per service (or rating group) basis,=20 >those triggers are events that affect the rating (cost) of the service=20 >other type of triggers and actions are not in the scope of this=20 >specification. Since the DCC is a general solution to the real-time=20 >cost and credit control, multiple services in one CC session is just=20 >one part of it, I have been striking a balance between your proposal=20 >and the DCC principles hoping to create something which would be=20 >relevant to the whole. Perhaps we may improve in some details but I=20 >really believe that the principle I described fits seamlessly and=20 >consistently, it also satisfies the requirements without adding too=20 >much complexity. I would then go ahead with this proposal, that has=20 >your proposal as solid base, and start to define what are these=20 >Trigger-Ids and their values.=20 I think that Marco and Leena have provided very well justified answers = why we should not spilt multiple service requests up into several=20 independent reservations. If different quotas are wanted to be reported=20 independently then sub-sessions should be used for that purpose.=20 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=20 -----Original Message-----=20 From: Leena Mattila (TU/LMF)=20 Sent: 10. marraskuuta 2003 10:01=20 To: 'crich@nortelnetworks.com'; 'marco.stura@nokia.com'=20 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: RE: [AAA-WG]: RE: Diam CC re-authorization triggers=20 Hi Chris, Marco,=20 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.=20 BR,=20 Leena=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: 7. marraskuuta 2003 14:02=20 To: crich@nortelnetworks.com=20 Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; Patrik Teppo (KA/EAB); aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Diam CC re-authorization triggers=20 [Chris Richards]=20 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.]=20 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. CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 [Chris Richards]=20 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]=20 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.]=20 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]=20 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.]=20 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).=20 When the CC server receives a CCR message it need to parse all the parts = of the message anyway.=20 Chris, I try now to draw some conclusion out of this discussion and how = I see the way to proceed.=20 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=20 Marco=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf = Of ext Christopher Richards=20 Sent: 06 November, 2003 19:57=20 To: Stura Marco (NET/Helsinki)=20 Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; Koskinen = Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni = (NET/Helsinki); patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: [AAA-WG]: RE: Diam CC re-authorization triggers=20 Hi Marco,=20 Thanks for the email. We're making excellent progress. I added my = responses below.=20 Cheers,=20 Chris.=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Thursday, November 06, 2003 11:35 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: harri.hakala@ericsson.com; leena.mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; aaa-wg@merit.edu Subject: Diam CC re-authorization triggers=20 Hi Chris,=20 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=20 are reported to the server).=20 [Chris Richards]=20 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]=20 Taking into account the tariff changes the G-S-U would be=20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ]=20 *[CC-Re-Auth-Trigger ]=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 CC-Re-Auth-Trigger ::=3D < AVP Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ]=20 [Chris Richards]=20 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 ::=3D < AVP = Header: TBD >=20 { Trigger-Id }=20 [ Trigger-Value ]=20 [ Trigger-Action]=20 And start defining a set of basic actions. The first of which is:=20 Re-auth U-S-U (send a re-auth for a new quota for G-S-U)=20 Block usage of G-S-U and do not report.=20 ....others TBD=20 With this we have the flexibility to enhance the triggers for future = requirements without changing the AVP.=20 [End Chris Richards]=20 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.=20 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.=20 In addition a CC-Re-Auth-Reason AVP (Grouped) is included in the CCR to = indicate the cause for=20 performing the credit re-authorization, and this is needed not only for = the triggers.=20 CC-Re-Auth-Reason :: < AVP Header: TBD >=20 { Reason-Code }=20 [ CC-Re-Auth-Trigger ]=20 [ Service-Identifier ]=20 [ Rating-Group ]=20 The Reason-Code (enumerated) indicates why the CCR[Update] has been = sent, may be=20 - Validity-Time expired=20 - quota limit reached=20 - Server initiated credit re-authorization (RAR received)=20 - client-driven update (i.e. the one known in draft-01 as=20 'spontaneous update')=20 - CC-Re-Auth-Trigger occured=20 - Final quota limit reached and GST started=20 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]=20 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]=20 I believe this way we enable triggers per G-S-U according to your = proposal and in a form consistent with=20 all the functionalities defined in the draft 01.=20 I hope we can all agree on this so that you can formulate the issue.=20 Regards=20 Marco=20 ------_=_NextPart_001_01C3A787.A1034952 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: RE: Diam CC re-authorization triggers
Hi=20 Chris,
 
[Chris=20 Richards]
I think that = without this=20 ability, we'll severely limit the usefulness of the Diam CC protocol. As = it is,=20 the protocol is very restricted. I think we need to make it a bit more = future=20 proof. Otherwise, it will only solve existing requirements and not = address any=20 of the new requirements for IP flow charging, event charging, pre- = post-paid=20 integration, WLAN convergence with 3GPP & 3GPP2, etc. And if we = limit=20 ourselves to solving existing requirements only - then it would be = better to=20 stick with an existing application - like RADIUS and not bother with = Diam at=20 all.
 
If you=20 look to the Flow X of the draft 01, the flexibility you are talking = about is=20 already there and it addresses IP flow charging for all the future = scenarios=20 you have listed.
Flow X=20 is a simple example, you could have more sofisticated examples as = well=20 (e.g. on demand etc.). But the key is to derive all the quotas from the = same=20 credit reservation to avoid bottlenecks in the account management system = and the=20 account it self. If you request 20 services from the same CC session, = why would=20 you perform 20 times a credit reservation and maintain states for all of = those?=20 It doesn't seem very optimized. Could you kindly explain what is your = credit=20 reservation strategy and concretely explain what is the scenario not = covered in=20 the draft?
 
[Chris=20 Richards]
As for using = sub-sessions, for=20 3GPP, isn't the intention of these to be used for secondary PDP = contexts? Using=20 sub-sessions for the same user session actually adds overhead - not just = the=20 additional transport overhead but also the additional separate state = maintenance=20 that needs to be maintained for what are logically linked=20 entities.
 
Secondary PDP Contexts are one example where = you could=20 use sub-sessions. Multiple services within the same user session and=20 differentiated charging of those is supported in draft 01 as I explained = above=20 and doesn't require sub-sessions, perhaps we just have different views = and=20 beliefs on the approach to use.
 
[Chris = Richards]
From the transport = efficiency,=20 think of mass events that may happen (e.g. a node outage causing all = active=20 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=20 network, client and server becomes the bottleneck.
 
Transport is not handled by the DCC = application at all,=20 the DCC just uses the Diameter transport according to RFC 3539 and RFC=20 3588.
 
Regards
Marco.
 
 -----Original=20 Message-----
From: ext Christopher Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 10 November, 2003=20 13:56
To: 'Harri Hakala (TU/LMF)'; Leena Mattila (TU/LMF); = Stura=20 Marco (NET/Helsinki)
Cc: Koskinen Juha-Pekka (NET/Tampere); = Loughney=20 John (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo = (KA/EAB);=20 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: RE: Diam CC=20 re-authorization triggers

Hi Harri, Leena, Marco,

Thanks for the responses over the weekend. =

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

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

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

Cheers,
Chris.

Shasta Wireless Development
Nortel=20 Networks

Telephone:
+1 972 684 = 3281=20
ESN 444 3281


-----Original Message-----
From: Harri=20 Hakala (TU/LMF) [mailto:harri.hakala@ericsson.co= m]=20
Sent: Monday, November 10, 2003 4:41 = AM=20
To: Leena Mattila (TU/LMF); Richards, Christopher=20 [RICH2:2Q40:EXCH]; 'marco.stura@nokia.com'
Cc:=20 'juha-pekka.koskinen@nokia.com'; 'john.loughney@nokia.com';=20 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB);=20 'aaa-wg@merit.edu'

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


Hi Chris, Marco & Leena,

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

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

independent reservations. If different quotas are = wanted to be=20 reported
independently then sub-sessions = should be=20 used for that purpose.

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

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

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

regards.........Harri

-----Original Message-----
From: Leena=20 Mattila (TU/LMF)
Sent: 10. marraskuuta 2003=20 10:01
To: 'crich@nortelnetworks.com';=20 'marco.stura@nokia.com'
Cc: Harri Hakala = (TU/LMF);=20 'juha-pekka.koskinen@nokia.com'; 'john.loughney@nokia.com';=20 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB);=20 'aaa-wg@merit.edu'

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


Hi Chris, Marco,

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

BR,
Leena
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: 7. marraskuuta 2003 14:02
To:=20 crich@nortelnetworks.com
Cc: Harri Hakala = (TU/LMF);=20 Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com;=20 john.loughney@nokia.com; Benni.Alexander@nokia.com; Patrik Teppo = (KA/EAB);=20 aaa-wg@merit.edu

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


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

Chris, the drawback of what you describe above is = that it add=20 a lot of complexity to the protocol and it is not consistent with the = DCC=20 functionalities. I already explained in some other mail that if you = want to=20 treat the G-S-U as independent entities you need one credit = reservation for=20 each of the G-S-U, thus you need CC sub-sessions and you already have = this=20 flexibility. If the G-S-Us are derived from the same credit = reservation you=20 cannot, and you must not, leave portion of the same reservation = running in the=20 client while another portion is reported to the server.  What you = propose=20 is breaking the DCC principles, the way I defined the = CC-Re-Auth-Triggers are=20 not session specific but service (or rating-group) specific and it = doesn't=20 break this association. What the client does is to initiate credit=20 re-authorization when a defined trigger event for a specific service = occurs=20 (not when a session event occurs). The server gets granular = information about=20 the service (or rating !

 group) and the trigger that caused the CCR, = based on=20 that it can make whatever decision about the service in question and = it can=20 manipulate the credit reservation accordingly, but it cannot work = properly on=20 the credit reservation if some portion of the reservation is still = running in=20 the client. Please note the structure of the reason code,  it = just=20 confirms the granularity I described.

CC-Re-Auth-Reason :: < AVP Header: TBD >=20
          &nbs= p;         =20 { Reason-Code }
          &nbs= p;         =20 [ CC-Re-Auth-Trigger ]
          &nbs= p;         =20 [ Service-Identifier ]
          &nbs= p;         =20 [ Rating-Group ]

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


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

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

[Chris Richards]
Thank you = for=20 including the Reason-Code. However, should it not be part of the U-S-U = to keep=20 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=20 will also make implementations easier because the Reason is parsed at = the same=20 time as the U-S-U - instead of separately in another part of the = message.=20 [Marco St.]

As you may have noticed, the CC-Re-Auth-Reason is = needed also=20 when multiple services in one CC session are not used at all and for = events=20 that are session specific (e.g. RAR received or Validity-Time = expired). When=20 multiple services in one CC session are used and a service specific = trigger is=20 causing the credit re-authorization, the structure of the = CC-Re-Auth-Reason=20 AVP enables for finer granularity than just session (as previously = discussed).=20

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

Regards
Marco =


 -----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of ext Christopher Richards
Sent: 06 = November,=20 2003 19:57
To: Stura Marco = (NET/Helsinki)=20
Cc: harri.hakala@ericsson.com; = leena.mattila@ericsson.com;=20 Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); = Alexander=20 Benni (NET/Helsinki); patrik.teppo@ericsson.com; = aaa-wg@merit.edu

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


Hi Marco,
Thanks for the = email. We're=20 making excellent progress. I added my responses below. =
Cheers,
Chris.
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Thursday, November 06, 2003 11:35 AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH]=20
Cc: harri.hakala@ericsson.com;=20 leena.mattila@ericsson.com; juha-pekka.koskinen@nokia.com;=20 john.loughney@nokia.com; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com;=20 aaa-wg@merit.edu

Subject: Diam CC re-authorization triggers =


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

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

Taking into account the tariff changes the G-S-U = would be=20
Granted-Service-Unit ::=3D < AVP Header: = 431 >=20
          &nbs= p;            = ; =20 [ Tariff-Time-Change ]
          &nbs= p;            = ;=20 *[CC-Re-Auth-Trigger ]
          &nbs= p;            = ; =20 [ CC-Time ]
          &nbs= p;            = ; =20 [ CC-Money ]
          &nbs= p;            = ; =20 [ CC-Total-Octets ]
          &nbs= p;            = ; =20 [ CC-Input-Octets ]
          &nbs= p;            = ; =20 [ CC-Output-Octets ]
          &nbs= p;            = ; =20 [ CC-Service-Specific-Units ]
          &nbs= p;            = ;=20 *[ Service-Identifier ]
          &nbs= p;            = ; =20 [ Rating-Group ]
CC-Re-Auth-Trigger ::=3D = < AVP=20 Header: TBD >
          &nbs= p;           =20 { Trigger-Id }
          &nbs= p;           =20 [ Trigger-Value ]
[Chris Richards] =
As well as a Trigger-Id and Trigger-Value, there seems to be = a need for=20 an (optional) Trigger-Action since it m ay be that the CC Client might = not=20 always need to re-auth for the trigger. For example, it may be to = Unblock the=20 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=20 for this. So, I propose:- CC-Re-Auth-Trigger ::=3D < AVP Header: = TBD >=20

          &nbs= p;           =20 { Trigger-Id }
          &nbs= p;           =20 [ Trigger-Value ]
          &nbs= p;           =20 [ Trigger-Action]
And start defining a set = of basic=20 actions. The first of which is:
Re-auth = U-S-U (send a=20 re-auth for a new quota for G-S-U)
Block = usage of=20 G-S-U and do not report.
....others TBD=20
With this we have the flexibility to enhance = the=20 triggers for future requirements without changing the AVP. =
[End Chris Richards]
The Trigger-Id = (Enumerated) may be QoS-Change, Location-Change, Idle-Timeout,=20 Service-Specific etc. but we need to define them to enable = interoperability.=20 The Trigger-Value (UTF8String) defines the value of the trigger and we = need to=20 define some of these as well for the same reason.

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

In addition a CC-Re-Auth-Reason AVP (Grouped)  = is=20 included in the CCR to indicate the cause for
performing the credit re-authorization, and this is needed = not only for=20 the triggers.
CC-Re-Auth-Reason :: < AVP = Header:=20 TBD >
          &nbs= p;         =20 { Reason-Code }
          &nbs= p;         =20 [ CC-Re-Auth-Trigger ]
          &nbs= p;         =20 [ Service-Identifier ]
          &nbs= p;         =20 [ Rating-Group ]
The Reason-Code = (enumerated)=20 indicates why the CCR[Update] has been sent, may be
-=20 Validity-Time expired
- quota limit reached=20
- Server initiated credit re-authorization = (RAR=20 received)
- client-driven update (i.e. the = one known=20 in draft-01 as
 'spontaneous update')=20
- CC-Re-Auth-Trigger occured =
-=20 Final quota limit reached and GST started
If = the=20 Reason-Code is set to CC-Re-Auth-Trigger occured the = CC-Re-Auth-Trigger AVP is=20 included to indicate what is the trigger that caused the CCR[Update]. = If=20 multiple quotas were given, the Service-Identifier or Rating-Group AVP = is=20 included to indicate what is the service or rating-group that caused = the=20 CCR[Update]. [Chris Richards]

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

I believe this way we enable triggers per G-S-U = according to=20 your proposal and in a form consistent with
all the=20 functionalities defined in the draft 01.
I = hope we can=20 all agree on this so that you can formulate the issue. =
Regards
Marco=20

------_=_NextPart_001_01C3A787.A1034952-- From owner-aaa-wg@merit.edu Mon Nov 10 08:45:01 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 IAA19153 for ; Mon, 10 Nov 2003 08:45:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F17AC91269; Mon, 10 Nov 2003 08:44:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B91169126A; Mon, 10 Nov 2003 08:44:55 -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 96A9891269 for ; Mon, 10 Nov 2003 08:44:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BD8F5DE2C; Mon, 10 Nov 2003 08:44:54 -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 B3A1E5DE08 for ; Mon, 10 Nov 2003 08:44:53 -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 hAADiqc02943 for ; Mon, 10 Nov 2003 15:44:52 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 15:44:52 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 15:44:52 +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]: RE: Diam CC re-authorization triggers Date: Mon, 10 Nov 2003 15:44:51 +0200 Message-ID: Thread-Topic: [AAA-WG]: RE: Diam CC re-authorization triggers Thread-Index: AcOngaOXAhEzPMz4QI6r8QjiqNawrAADrcRg From: To: , , , Cc: , , , X-OriginalArrivalTime: 10 Nov 2003 13:44:52.0426 (UTC) FILETIME=[D13FE2A0:01C3A790] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, > I think that without this ability, we'll severely limit the usefulness = of the Diam CC=20 > protocol. As it is, the protocol is very restricted. I think we need = to make it a bit more=20 > future proof. Otherwise, it will only solve existing requirements and = not address any of the=20 > new requirements for IP flow charging, event charging, pre- post-paid = integration, WLAN=20 > convergence with 3GPP & 3GPP2, etc. And if we limit ourselves to = solving existing=20 > requirements only - then it would be better to stick with an existing = application - like=20 > 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=20 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=20 > PDP contexts? Using sub-sessions for the same user session actually = adds overhead - not just=20 > the additional transport overhead but also the additional separate = state maintenance that=20 > 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=20 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=20 > causing all active sessions to be closed gracefully). Now if each user = has to send multiple=20 > messages and there are many millions of users active, the overhead on = the network, client and > server becomes the bottleneck.=20 The transport behavior is handled in the Diameter base specification, = not in the CC application. thanks, John From owner-aaa-wg@merit.edu Mon Nov 10 09:54:05 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 JAA21639 for ; Mon, 10 Nov 2003 09:54:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B73491279; Mon, 10 Nov 2003 09:52:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6ECA291278; Mon, 10 Nov 2003 09:52:40 -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 24C3B9126B for ; Mon, 10 Nov 2003 09:52:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 125B65DE25; Mon, 10 Nov 2003 09:52:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8A2C45DE16 for ; Mon, 10 Nov 2003 09:52:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAAEEY012290 for ; Mon, 10 Nov 2003 06:14:35 -0800 Date: Mon, 10 Nov 2003 06:14:34 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Slides for AAA WG session at IETF 58 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you have slides to present at the AAA WG session at IETF 58, please send them to me ASAP. thanks! From owner-aaa-wg@merit.edu Tue Nov 11 11:25:04 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 LAA08133 for ; Tue, 11 Nov 2003 11:25:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AEA5A91298; Tue, 11 Nov 2003 11:25:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 820549129C; Tue, 11 Nov 2003 11:25: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 7EB5B91298 for ; Tue, 11 Nov 2003 11:25:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A3135DDF3; Tue, 11 Nov 2003 11:25:00 -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 A22235DDB6 for ; Tue, 11 Nov 2003 11:24:59 -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 hABGOvB08273 for ; Tue, 11 Nov 2003 18:24:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 18:24:57 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Nov 2003 18:24:57 +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: [AAA-WG]: RE: Diam CC Tariff time changes Date: Tue, 11 Nov 2003 18:24:56 +0200 Message-ID: Thread-Topic: Diam CC Tariff time changes Thread-Index: AcOocFd7Mv/BYT66SJOWoTUPz+ZBfg== From: To: , Cc: , , , , , X-OriginalArrivalTime: 11 Nov 2003 16:24:57.0526 (UTC) FILETIME=[58BF9560:01C3A870] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, I am keeping a new issue tracker for CCA, it can be found from: http://danforsberg.info:8080/draft-ietf-aaa-diameter-cc/ I have added this issue as issue 1. John > -----Original Message----- > From: Stura Marco (NET/Helsinki)=20 > Sent: 06 November, 2003 16:45 > To: crich@nortelnetworks.com > Cc: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); Koskinen Juha-Pekka > (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni > (NET/Helsinki); Patrik Teppo (KA/EAB); aaa-wg@merit.edu > Subject: Diam CC Tariff time changes >=20 >=20 > Hi Chris, >=20 > I think we agreed on the tariff changes issue and principles. > I had some thought on how to implement this support of tariff=20 > time changes in the Diam CC, I would > like to know your opinion whether you agree on the approach. >=20 > I guess we need tariff change at the G-S-U level since it may=20 > not apply to all the services > or rating groups. The server would grant quota according to=20 > the worst case (i.e. the highest price)=20 > and the client would report units used before and after the=20 > tariff change. This would result in two U-S-U > (eventually associated to the same Service-Identifier or=20 > Rating-Group if applicable) in a CCR command,=20 > one USU includes the units consumed before the tariff time=20 > change and the other USU includes the > units consumed after the tariff time change. > This mechanism would be optional for client and server and=20 > would not be used for time quotas since=20 > the server is in full control of the time. A client not=20 > supporting the tariff time change mechanism would > terminate the service and send a CCR[Termination] to the=20 > server with an appropriate Termination-Cause > (e.g. DIAMETER_BAD_ANSWER) since this affect the cost of the service. > Do we need to indicate to the server more precise reason=20 > (e.g. Tariff-time not supported)? >=20 > Granted-Service-Unit ::=3D < AVP Header: TBD >=20 > [ Tariff-Time-Change ] > [ 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 > =20 >=20 > Used-Service-Unit ::=3D < AVP Header: TBD >=20 > [ Tariff-Time-Usage ] > [ 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 >=20 > Tariff-Time-Change (Time) includes the time in seconds since=20 > January 1, 1900 00:00 UTC when > the tariff will change. > Tariff-Time-Usage (enumerated) may have value=20 > "before-tariff-change" and "after-tariff-change". >=20 > I understood you volunteer to carry out a formal issue for=20 > all the improvements you proposed, is my > understanding correct? If yes, and if you agree with the=20 > above described tariff time changes approach, > are you OK to go ahead with a formal issue? >=20 > I'll approach you with a separate mail to discuss the triggers. >=20 > Regards > Marco >=20 From owner-aaa-wg@merit.edu Wed Nov 12 12:37: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 MAA29157 for ; Wed, 12 Nov 2003 12:37:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3802B91239; Wed, 12 Nov 2003 12:37:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09E559123A; Wed, 12 Nov 2003 12:37: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 01B4191239 for ; Wed, 12 Nov 2003 12:37:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7C0B5DDAE; Wed, 12 Nov 2003 12:37:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E48005DDCD for ; Wed, 12 Nov 2003 12:37:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hACGx8T27560 for ; Wed, 12 Nov 2003 08:59:08 -0800 Date: Wed, 12 Nov 2003 08:59:08 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: I looked at: Re: draft-ietf-aaa-diameter-mobileip (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 12 Nov 2003 12:02:36 -0500 From: Russ Housley To: aboba@internaut.com Cc: smb@research.att.com Subject: Fwd: I looked at: Re: draft-ietf-aaa-diameter-mobileip Bernard: I asked Radia to look at this document -- a secdir review. Can you help me understand the big picture? If her assessment is correct, then the points I made in my slides on key management are violated. Help ... Russ >Date: Wed, 12 Nov 2003 10:51:11 -0600 >From: Radia Perlman >Subject: I looked at: Re: draft-ietf-aaa-diameter-mobileip >To: Russ Housley >Cc: smb@research.att.com > >The document is incomprehensible. To my amazement, after reading it n >times, I was >starting to understand some of it, and found some fishy things. I tracked >down the 1st >author (Pat Calhoun), and it was somewhat distressing that he also did not >understand >the document. > >Basically, the AAA guys have gone off and invented all sorts of things, >and security people >haven't been paying attention because nobody wanted to wade through all >the muck of >new terminology and badly written documents. > > From my current understanding, the purpose of this document is to allow a > Sprint customer >to roam into MCI territory and have MCI be able to bill Sprint for the usage. > >There are a bunch of access points, that don't have user information (like >Radius), but there >is a AAA database at Sprint, and at MCI, etc. When a user connects to an >access point, the >access point gets the user's information from the AAA database. The AAA >server acts like >the KDC in Kerberos, and invents a session key to give > to the access point and the user. >This is according to Pat, who I caught in the hall. The document implies >that instead of >a Kerberos-like protocol where the session key is encrypted in a >KDC-endpoint shared >secret, the keys are sent over TLS sessions. So in the case of >inter-realm, the intermediaries >would see the keys. When I pointed out that the document did not imply it >worked the way >Pat was explaining it to me, Pat was confused and said he didn't know why >the document said >that...that it was a long time since he saw the document, and I should >instead try to talk >to the 2nd author. > >I also asked why they hadn't actually used Kerberos, and Pat had no idea >how Kerberos worked, >which is another red flag...that people design security handshakes without >knowing what's out there. >Maybe they did something correct, who knows. SUpposedly that protocol is >described in the >base diameter spec. I will attempt to look at it. > >Anyway, just giving you an intermediate state...I will att >empt to do some more research on this. >And don't yell at Pat for anything I said...I'm glad he cooperated with me >to the extent of explaining >what he could, and I might need to ask him more questions, so don't get >him mad at me. > >Radia From owner-aaa-wg@merit.edu Thu Nov 13 17:26: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 RAA24633 for ; Thu, 13 Nov 2003 17:26:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A607A91305; Thu, 13 Nov 2003 17:24:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 671A69131F; Thu, 13 Nov 2003 17:24:13 -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 BF63191305 for ; Thu, 13 Nov 2003 17:24:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABEDD5DE15; Thu, 13 Nov 2003 17:24:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 2B7215DD8D for ; Thu, 13 Nov 2003 17:24:11 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hADLjst30800 for ; Thu, 13 Nov 2003 13:45:55 -0800 Date: Thu, 13 Nov 2003 13:45:54 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Slides from IETF 58 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The slides from the AAA WG meeting at IETF 58 are available here: http://www.drizzle.com/~aboba/IETF58/AAA.zip From owner-aaa-wg@merit.edu Fri Nov 14 05:08:01 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 FAA04480 for ; Fri, 14 Nov 2003 05:08:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6065191246; Fri, 14 Nov 2003 05:07:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27FB89124B; Fri, 14 Nov 2003 05:07:59 -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 9C5CF91246 for ; Fri, 14 Nov 2003 05:07:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8607A5DDBB; Fri, 14 Nov 2003 05:07:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailsweep01.vodafone.ie (unknown [213.233.159.70]) by segue.merit.edu (Postfix) with ESMTP id 06F525DDB4 for ; Fri, 14 Nov 2003 05:07:55 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Fri, 14 Nov 2003 10:06:29 +0000 To: aaa-wg@merit.edu Subject: [AAA-WG]: Request for Clarification of Diameter Capability Exchange MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.ie Date: Fri, 14 Nov 2003 10:02:54 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 11/14/2003 10:02:58 AM, Serialize complete at 11/14/2003 10:02:58 AM Content-Type: multipart/alternative; boundary="=_alternative 0037308780256DDE_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0037308780256DDE_= Content-Type: text/plain; charset="us-ascii" Hi, We are looking at a scenario where two nodes, supplied by separate vendors, are communicated using a Diameter vendor-specific application defined by a third vendor. We have been trying to understand exactly how the CER and CEA messages would work in this scenario and I would like to test our interpretation of RFC 3588. We're assuming a separate Vendor-ID value for each of the three companies. Our understanding is that the Vendor-ID, Product-Name and Firmware-Revision AVPs refer to the vendor of each box and their product. This contradicts the text in section 5.3.3 of RFC 3588 which states "The Vendor-ID AVP ... contains the ... value assigned to the vendor of the Diameter application", but appears consistent with the rest of 5.3. As I've said, we're interpretting Vendor-ID as really being the vendor of the box, not the vendor of the Diameter vendor-specific application. Is this correct? If so, what this means is that these three AVPs would probably only be used for logging by the recipient of the message (request or answer command). A box produced by vendor B shouldn't be expected to know that version x.z of vendor A's box supports Diameter ABC and version x.y doesn't. Therefore the important AVPs, in this scenario, for capabilities exchange are Supported-Vendor-ID (set to the value for vendor C who defined the Diameter application) and Vendor-Specific-Application-ID. So far so good, but we're imagining a scenario where the application will be phased in, so the functionality between different versions will be significantly different. There appears to be no means in the capabilities exchange to negotiate the supported version of the Diameter application. Therefore the only mechanism we can see is for the recipient of a message to reject the message if it: a) gets a manadatory AVP that it doesn't understand b) fails to receive a mandatory AVP that it requires. Which all means a successful capabilities exchange doesn't guarantee subsequent successful communication. Have we understood this correctly? It has also been suggested that the vendor-specific application ID could be changed between say v1.0 and v2.0 of the Diameter application. Is this the way it is intended to work? Regards, John. ****************************************************************************** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination, disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages of this kind. The opinions, conclusions and other information in this message are of the author and shall be understood as neither given nor endorsed by Vodafone Ireland Limited unless it is otherwise indicated by an authorised representative independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone Ireland Limited has no control. As such, there is no guarantee that (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender (iii) this e-mail has not been intercepted by a third party (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsibility of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18. Number 326967 VAT Reg No. IE6346967G ****************************************************************************** --=_alternative 0037308780256DDE_= Content-Type: text/html; charset="us-ascii"
Hi,

We are looking at a scenario where two nodes, supplied by separate vendors, are communicated using a Diameter vendor-specific application defined by a third vendor.  We have been trying to understand exactly how the CER and CEA messages would work in this scenario and I would like to test our interpretation of RFC 3588.  We're assuming a separate Vendor-ID value for each of the three companies.

Our understanding is that the Vendor-ID, Product-Name and Firmware-Revision AVPs refer to the vendor of each box and their product.  This contradicts the text in section 5.3.3 of RFC 3588 which states "The Vendor-ID AVP ... contains the ... value assigned to the vendor of the Diameter application", but appears consistent with the rest of 5.3.  As I've said, we're interpretting Vendor-ID as really being the vendor of the box, not the vendor of the Diameter vendor-specific application.  Is this correct?

If so, what this means is that these three AVPs would probably only be used for logging by the recipient of the message (request or answer command).  A box produced by vendor B shouldn't be expected to know that version x.z of vendor A's box supports Diameter ABC and version x.y doesn't.  Therefore the important AVPs, in this scenario, for capabilities exchange are Supported-Vendor-ID (set to the value for vendor C who defined the Diameter application) and Vendor-Specific-Application-ID.

So far so good, but we're imagining a scenario where the application will be phased in, so the functionality between different versions will be significantly different.  There appears to be no means in the capabilities exchange to negotiate the supported version of the Diameter application.

Therefore the only mechanism we can see is for the recipient of a message  to reject the message if it:
        a) gets a manadatory AVP that it doesn't understand
        b) fails to receive a mandatory AVP that it requires.

Which all means a successful capabilities exchange doesn't guarantee subsequent successful communication.

Have we understood this correctly?

It has also been suggested that the vendor-specific application ID could be changed between say v1.0 and v2.0 of the Diameter application.  Is this the way it is intended to work?

Regards,

John.
 

******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone. In such
case, you should destroy this message and kindly notify the
sender and postmaster@vodafone.ie by reply email. Please
note that in such circumstances any review, dissemination,
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages
of this kind. The opinions, conclusions and other information
in this message are of the author and shall be understood as
neither given nor endorsed by Vodafone Ireland Limited
unless it is otherwise indicated by an authorised representative
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone
Ireland Limited has no control. As such, there is no guarantee that
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender
(iii) this e-mail has not been intercepted by a third party
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this
message (including its attachments) has been processed by an
automated anti-virus system; however it is the responsibility of
the recipient to ensure that the message (and attachments)
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Number 326967 VAT Reg No. IE6346967G

******************************************************************************
 --=_alternative 0037308780256DDE_=-- From owner-aaa-wg@merit.edu Fri Nov 14 07:27:27 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 HAA08011 for ; Fri, 14 Nov 2003 07:27:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8E5829124D; Fri, 14 Nov 2003 07:27:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 601019124E; Fri, 14 Nov 2003 07:27:23 -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 D0EF79124D for ; Fri, 14 Nov 2003 07:27:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5A485DEE4; Fri, 14 Nov 2003 07:27:20 -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 B15A75DED0 for ; Fri, 14 Nov 2003 07:27:19 -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 hAECRI601441 for ; Fri, 14 Nov 2003 14:27:18 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Nov 2003 14:27:17 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 14:27:17 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 14:27:17 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 14:27:17 +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]: Request for Clarification of Diameter Capability Exchange Date: Fri, 14 Nov 2003 14:27:16 +0200 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C96316CC50D@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Request for Clarification of Diameter Capability Exchange Thread-Index: AcOql1L6rQmBwJPWT2WhBDPvcH+BGQAEz0ig From: To: X-OriginalArrivalTime: 14 Nov 2003 12:27:17.0055 (UTC) FILETIME=[A415A4F0:01C3AAAA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi! > It has also been suggested that the vendor-specific application ID = could be > changed between say v1.0 and v2.0 of the Diameter application. Is = this the way > it is intended to work?=20 Yes, in my opinion. For example, if the "new version" of Diameter application defines new command-codes and/or new AVPs with M-bit set, then it would be handled by allocating a new Application-Id, as defined in RFC3588, Sections 1.2.3 and 1.2.4. Best Regards, Mikko -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.ie Sent: 14 November, 2003 12:03 To: aaa-wg@merit.edu Subject: [AAA-WG]: Request for Clarification of Diameter Capability = Exchange=20 Hi,=20 We are looking at a scenario where two nodes, supplied by separate = vendors, are communicated using a Diameter vendor-specific application = defined by a third vendor. We have been trying to understand exactly = how the CER and CEA messages would work in this scenario and I would = like to test our interpretation of RFC 3588. We're assuming a separate = Vendor-ID value for each of the three companies.=20 Our understanding is that the Vendor-ID, Product-Name and = Firmware-Revision AVPs refer to the vendor of each box and their = product. This contradicts the text in section 5.3.3 of RFC 3588 which = states "The Vendor-ID AVP ... contains the ... value assigned to the = vendor of the Diameter application", but appears consistent with the = rest of 5.3. As I've said, we're interpretting Vendor-ID as really = being the vendor of the box, not the vendor of the Diameter = vendor-specific application. Is this correct?=20 If so, what this means is that these three AVPs would probably only be = used for logging by the recipient of the message (request or answer = command). A box produced by vendor B shouldn't be expected to know that = version x.z of vendor A's box supports Diameter ABC and version x.y = doesn't. Therefore the important AVPs, in this scenario, for = capabilities exchange are Supported-Vendor-ID (set to the value for = vendor C who defined the Diameter application) and = Vendor-Specific-Application-ID.=20 So far so good, but we're imagining a scenario where the application = will be phased in, so the functionality between different versions will = be significantly different. There appears to be no means in the = capabilities exchange to negotiate the supported version of the Diameter = application.=20 Therefore the only mechanism we can see is for the recipient of a = message to reject the message if it:=20 a) gets a manadatory AVP that it doesn't understand=20 b) fails to receive a mandatory AVP that it requires.=20 Which all means a successful capabilities exchange doesn't guarantee = subsequent successful communication.=20 Have we understood this correctly?=20 It has also been suggested that the vendor-specific application ID could = be changed between say v1.0 and v2.0 of the Diameter application. Is = this the way it is intended to work?=20 Regards,=20 John.=20 =20 *************************************************************************= ***** The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message=20 (or responsible for delivery of the message to such person),=20 you may not copy or deliver this message to anyone. In such=20 case, you should destroy this message and kindly notify the=20 sender and postmaster@vodafone.ie by reply email. Please note that in such circumstances any review, dissemination,=20 disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited=20 and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages=20 of this kind. The opinions, conclusions and other information=20 in this message are of the author and shall be understood as=20 neither given nor endorsed by Vodafone Ireland Limited=20 unless it is otherwise indicated by an authorised representative=20 independent of this message. Internet e-mail is transmitted over the public internet over which Vodafone=20 Ireland Limited has no control. As such, there is no guarantee that=20 (i) this e-mail will be delivered within a reasonable time or at all (ii) this e-mail comes from the purported sender=20 (iii) this e-mail has not been intercepted by a third party=20 (iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this=20 message (including its attachments) has been processed by an=20 automated anti-virus system; however it is the responsibility of=20 the recipient to ensure that the message (and attachments)=20 are safe and authorised for use in their environment. Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK),=20 Pauline Best (UK), Paul Donovan Chief Executive (UK),=20 Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.=20 Number 326967 VAT Reg No. IE6346967G *************************************************************************= ***** From owner-aaa-wg@merit.edu Tue Nov 18 10:34:43 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 KAA25941 for ; Tue, 18 Nov 2003 10:34:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E7D49122F; Tue, 18 Nov 2003 10:34:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09C7391230; Tue, 18 Nov 2003 10:34:40 -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 0E4679122F for ; Tue, 18 Nov 2003 10:34:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id F17605DDFC; Tue, 18 Nov 2003 10:34:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 55D725DD98 for ; Tue, 18 Nov 2003 10:34:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAIFsoe07849 for ; Tue, 18 Nov 2003 07:54:51 -0800 Date: Tue, 18 Nov 2003 07:54:50 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: Use of [Issue] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Recently when updating the AAA Issues list, I found I had missed a few issues from several months ago. My apologies to the submitters. In reviewing the web archive for submitted issues, I typically scan for the string "[Issue]" in the subject line, assuming that other postings are not document change requests. The issues I missed were issues submitted in the correct format, but did not have [Issue] in the subject line, so I did not pick them out when glancing through the web archive. In order to make sure your issue is properly tracked and added to the Issues list, please add "[Issue]" to the subject line when requesting a change to a document. Thanks! Bernard From owner-aaa-wg@merit.edu Fri Nov 21 11:46:38 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 LAA20857 for ; Fri, 21 Nov 2003 11:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D44B9127F; Fri, 21 Nov 2003 11:46:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06E9591280; Fri, 21 Nov 2003 11:46:36 -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 E4C749127F for ; Fri, 21 Nov 2003 11:46:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B04D5DF00; Fri, 21 Nov 2003 11:46:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id 17ECD5DE7D for ; Fri, 21 Nov 2003 11:46:27 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALGjqE24699; Fri, 21 Nov 2003 10:45:52 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hALGjo606125; Fri, 21 Nov 2003 10:45:50 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOPNW6-0000H8-00; Fri, 21 Nov 2003 11:45:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16318.16695.11515.403051@gargle.gargle.HOWL> Date: Fri, 21 Nov 2003 10:45:43 -0600 From: Pete McCann To: mip4@ietf.org, aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diameter-mip X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, During my presentation of the Diameter Mobile IPv4 application to the AAA working group, an item came up around the use of the term "Key Material" in the Diameter Mobile IPv4 application and the Mobile IP aaa-key draft. It was noted that the term "Key Material" usually denotes stuff that should be kept secret, whereas the "Key Material" sent in a Registration Reply are actually nonces intended to be used by the MN to derive session keys. They will be visible to third parties while in transit. To resolve this, I suggest that we change all instances of "Key Material" in both of these drafts to something more descriptive, like "Nonce for Key Generation" or just "Nonce" when the context is clear. Is that acceptable to everyone? Hopefully we can make this change quickly and get both drafts ready for IESG submission. Thanks, -Pete From owner-aaa-wg@merit.edu Fri Nov 21 12:01:12 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 MAA22328 for ; Fri, 21 Nov 2003 12:01:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8587791280; Fri, 21 Nov 2003 12:01:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5719E91281; Fri, 21 Nov 2003 12:01:08 -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 5D73991280 for ; Fri, 21 Nov 2003 12:01:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 417CB5DEEF; Fri, 21 Nov 2003 12:01:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 47EEB5DDBB for ; Fri, 21 Nov 2003 12:01:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hALHJ5n10424; Fri, 21 Nov 2003 09:19:05 -0800 Date: Fri, 21 Nov 2003 09:19:05 -0800 (PST) From: Bernard Aboba To: Pete McCann Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diameter-mip In-Reply-To: <16318.16695.11515.403051@gargle.gargle.HOWL> Message-ID: References: <16318.16695.11515.403051@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This change is ok with me as long as the term "Nonce" refers to a non-secret quantity. It would appears to me that at least some of the quantities referred to as "Key Material" in the Diameter MIPv4 draft are in fact secret. Also, I'd prefer to use the term "Session Key" for an ephemeral key that is refreshed by a nonce, and "Pre-shared key" for a quantity that is a long-term secret (such as that shared between the MN and HA). Getting the terminology straight is probably half the battle in getting these drafts completed. On Fri, 21 Nov 2003, Pete McCann wrote: > > Hi, > > During my presentation of the Diameter Mobile IPv4 application to the > AAA working group, an item came up around the use of the term "Key > Material" in the Diameter Mobile IPv4 application and the Mobile IP > aaa-key draft. It was noted that the term "Key Material" usually > denotes stuff that should be kept secret, whereas the "Key Material" > sent in a Registration Reply are actually nonces intended to be used > by the MN to derive session keys. They will be visible to third > parties while in transit. > > To resolve this, I suggest that we change all instances of "Key > Material" in both of these drafts to something more descriptive, > like "Nonce for Key Generation" or just "Nonce" when the context is > clear. > > Is that acceptable to everyone? Hopefully we can make this change > quickly and get both drafts ready for IESG submission. > > Thanks, > > -Pete > > From owner-aaa-wg@merit.edu Fri Nov 21 13:44:24 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 NAA26292 for ; Fri, 21 Nov 2003 13:44:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6FFEF91283; Fri, 21 Nov 2003 13:44:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F8A591285; Fri, 21 Nov 2003 13:44:22 -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 ECDD091283 for ; Fri, 21 Nov 2003 13:44:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id D4ED85DEF5; Fri, 21 Nov 2003 13:44:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 98AAC5DEE3 for ; Fri, 21 Nov 2003 13:44:20 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALIhIo23084; Fri, 21 Nov 2003 12:43:22 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hALIhH618823; Fri, 21 Nov 2003 12:43:18 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOPTBV-0001S4-00; Fri, 21 Nov 2003 13:43:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16318.23735.685515.762980@gargle.gargle.HOWL> Date: Fri, 21 Nov 2003 12:43:03 -0600 From: Pete McCann To: Bernard Aboba Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diameter-mip In-Reply-To: References: <16318.16695.11515.403051@gargle.gargle.HOWL> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Bernard, Ok, let's make sure to check the context in each case. Also, please note that the only long-term secret required is the one shared between MN and AAAH. The Diameter-MIP4 application can dynamically distribute the MN-HA session key (and the nonce that was used to generated it) to the HA. You are of course allowed to have a long-term secret between the MN and HA as part of a manually (or otherwise) configured mobility security association, but it isn't required. -Pete Bernard Aboba writes: > This change is ok with me as long as the term "Nonce" refers to a > non-secret quantity. It would appears to me that at least some of the > quantities referred to as "Key Material" in the Diameter MIPv4 draft are > in fact secret. > > Also, I'd prefer to use the term "Session Key" for an ephemeral key that > is refreshed by a nonce, and "Pre-shared key" for a quantity that is a > long-term secret (such as that shared between the MN and HA). > > Getting the terminology straight is probably half the battle in getting > these drafts completed. > > On Fri, 21 Nov 2003, Pete McCann wrote: > > > > > Hi, > > > > During my presentation of the Diameter Mobile IPv4 application to the > > AAA working group, an item came up around the use of the term "Key > > Material" in the Diameter Mobile IPv4 application and the Mobile IP > > aaa-key draft. It was noted that the term "Key Material" usually > > denotes stuff that should be kept secret, whereas the "Key Material" > > sent in a Registration Reply are actually nonces intended to be used > > by the MN to derive session keys. They will be visible to third > > parties while in transit. > > > > To resolve this, I suggest that we change all instances of "Key > > Material" in both of these drafts to something more descriptive, > > like "Nonce for Key Generation" or just "Nonce" when the context is > > clear. > > > > Is that acceptable to everyone? Hopefully we can make this change > > quickly and get both drafts ready for IESG submission. > > > > Thanks, > > > > -Pete > > > > From owner-aaa-wg@merit.edu Fri Nov 21 23:02:38 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 XAA18199 for ; Fri, 21 Nov 2003 23:02:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 75D289128A; Fri, 21 Nov 2003 23:02:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 476579128B; Fri, 21 Nov 2003 23:02:34 -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 E68369128A for ; Fri, 21 Nov 2003 23:02:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF5F25DF11; Fri, 21 Nov 2003 23:02:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 622E55DDF7 for ; Fri, 21 Nov 2003 23:02:32 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Nov 2003 23:02:28 -0500 Message-ID: From: Avi Lior To: "'Pete McCann'" , Bernard Aboba Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diamete r-mip Date: Fri, 21 Nov 2003 23:02:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pete, Bernard, If you look at RFC 3344 nonce is defined this way: A randomly chosen value, different from previous choices, inserted in a message to protect against replays. If this is a correct definition then the proposed usage is not consistant with the above definition, right? In the AAA Keys for Mobile IPv4 draft it is defined as such: Key Material Data (e.g., a nonce) used for the purpose of creating a key. That is it could be a nonce but it doesn't have to be. In the section for Key Material Creation and Derivation it state that the 'Key Material' is a random value. Does that random value have to be different from previous choices inserted in a message to protect against replays? BTW: If it does have to have propreties consistant with RFC 3344's definition of nonce, then I suggest that AAA Keys for Mobile IPv4 should be tightened. Just my 2cents worth. BTW I took a look around and I don't have a problem with Key Material here is a definition that is common: Keying Material The data (e.g., keys and IVs) necessary to establish and maintain cryptographic keying relationships. Avi > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: November 21, 2003 1:43 PM > To: Bernard Aboba > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [Issue] Name for the nonces in > aaa-keys and diameter-mip > > > > Hi, Bernard, > > Ok, let's make sure to check the context in each case. > > Also, please note that the only long-term secret required is > the one shared between MN and AAAH. The Diameter-MIP4 > application can dynamically distribute the MN-HA session key > (and the nonce that was used to generated it) to the HA. You > are of course allowed to have a long-term secret between the > MN and HA as part of a manually (or > otherwise) configured mobility security association, but it > isn't required. > > -Pete > > Bernard Aboba writes: > > This change is ok with me as long as the term "Nonce" > refers to a > non-secret quantity. It would appears to me > that at least some of the > quantities referred to as "Key > Material" in the Diameter MIPv4 draft are > in fact secret. > > > Also, I'd prefer to use the term "Session Key" for an > ephemeral key that > is refreshed by a nonce, and > "Pre-shared key" for a quantity that is a > long-term secret > (such as that shared between the MN and HA). > > > Getting the terminology straight is probably half the > battle in getting > these drafts completed. > > > On Fri, 21 Nov 2003, Pete McCann wrote: > > > > > > > > Hi, > > > > > > During my presentation of the Diameter Mobile IPv4 > application to the > > AAA working group, an item came up > around the use of the term "Key > > Material" in the > Diameter Mobile IPv4 application and the Mobile IP > > > aaa-key draft. It was noted that the term "Key Material" > usually > > denotes stuff that should be kept secret, > whereas the "Key Material" > > sent in a Registration Reply > are actually nonces intended to be used > > by the MN to > derive session keys. They will be visible to third > > > parties while in transit. > > > > To resolve this, I > suggest that we change all instances of "Key > > Material" > in both of these drafts to something more descriptive, > > > like "Nonce for Key Generation" or just "Nonce" when the > context is > > clear. > > > > Is that acceptable to > everyone? Hopefully we can make this change > > quickly and > get both drafts ready for IESG submission. > > > > Thanks, > > > > > -Pete > > > > > From owner-aaa-wg@merit.edu Sat Nov 22 00:31:52 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 AAA20891 for ; Sat, 22 Nov 2003 00:31:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A3559128B; Sat, 22 Nov 2003 00:31:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BDF39128C; Sat, 22 Nov 2003 00:31:41 -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 762DD9128B for ; Sat, 22 Nov 2003 00:31:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6171E5DDAB; Sat, 22 Nov 2003 00:31:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D30895DDC1 for ; Sat, 22 Nov 2003 00:31:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAM5pNW21307; Fri, 21 Nov 2003 21:51:23 -0800 Date: Fri, 21 Nov 2003 21:51:23 -0800 (PST) From: Bernard Aboba To: Avi Lior Cc: "'Pete McCann'" , mip4@ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diamete r-mip In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > In the AAA Keys for Mobile IPv4 draft it is defined as such: > > Key Material Data (e.g., a nonce) used for the purpose of > creating a key. > In the section for Key Material Creation and Derivation it state that the > 'Key Material' is a random value. Typically the term "Key Material" is used to refer to something from which a Session Key is derived. Both the Keying Material and the Session Key are secrets. Is that the case here? > Does that random value have to be different from previous choices inserted > in a message to protect against replays? If replay protection is desired, a counter or other monotonic value will generally do the job. But "freshness" can be provided a nonce. They aren't necessarily the same thing (e.g. assuring that a nonce isn't replayed requires a large cache, while assuring against replay of a counter is easy). kk From owner-aaa-wg@merit.edu Mon Nov 24 00:55:46 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 AAA13228 for ; Mon, 24 Nov 2003 00:55:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1C8291205; Mon, 24 Nov 2003 00:55:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 678BB9120C; Mon, 24 Nov 2003 00:55:42 -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 2468791205 for ; Mon, 24 Nov 2003 00:55:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05CD75DE44; Mon, 24 Nov 2003 00:55:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by segue.merit.edu (Postfix) with ESMTP id B52C75DE1B for ; Mon, 24 Nov 2003 00:55:40 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAO5spj18145; Sun, 23 Nov 2003 23:55:34 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAO5osd06848; Sun, 23 Nov 2003 23:50:54 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOUDKL-00011S-00; Mon, 24 Nov 2003 00:50:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16321.39992.755515.876655@gargle.gargle.HOWL> Date: Sun, 23 Nov 2003 23:50:48 -0600 From: Pete McCann To: Avi Lior Cc: Bernard Aboba , mip4@ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diamete r-mip In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Avi, You could say that the nonces in the "key material" field serve to make the key fresh, which in turn helps defeat replay attacks using old keys. So it is a "value, different from previous choices, inserted in a message to protect against replays" but it is not required to be random, and the replay protection is somewhat indirect. I think the use of the term nonce for this value would be consistent with existing cryptography literature, even if it may not be consistent with the definition in 3344, which is really there for the nonce-based replay protection that is part of the base Mobile IPv4 protocol. The definition for keying material that you cite shows why we shouldn't use that term for the nonce value. -Pete Avi Lior writes: > Hi Pete, Bernard, > > If you look at RFC 3344 nonce is defined this way: > > A randomly chosen value, different from previous choices, > inserted in a message to protect against replays. > > If this is a correct definition then the proposed usage is not consistant > with the above definition, right? > > In the AAA Keys for Mobile IPv4 draft it is defined as such: > > Key Material Data (e.g., a nonce) used for the purpose of > creating a key. > > That is it could be a nonce but it doesn't have to be. > > In the section for Key Material Creation and Derivation it state that the > 'Key Material' is a random value. > > Does that random value have to be different from previous choices inserted > in a message to protect against replays? > > BTW: If it does have to have propreties consistant with RFC 3344's > definition of nonce, then I suggest that AAA Keys for Mobile IPv4 should be > tightened. > > Just my 2cents worth. > > BTW I took a look around and I don't have a problem with Key Material here > is a definition that is common: > > Keying Material > > The data (e.g., keys and IVs) necessary to establish and maintain > cryptographic keying relationships. > > > Avi > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: November 21, 2003 1:43 PM > > To: Bernard Aboba > > Cc: mip4@ietf.org; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: [Issue] Name for the nonces in > > aaa-keys and diameter-mip > > > > > > > > Hi, Bernard, > > > > Ok, let's make sure to check the context in each case. > > > > Also, please note that the only long-term secret required is > > the one shared between MN and AAAH. The Diameter-MIP4 > > application can dynamically distribute the MN-HA session key > > (and the nonce that was used to generated it) to the HA. You > > are of course allowed to have a long-term secret between the > > MN and HA as part of a manually (or > > otherwise) configured mobility security association, but it > > isn't required. > > > > -Pete > > > > Bernard Aboba writes: > > > This change is ok with me as long as the term "Nonce" > > refers to a > non-secret quantity. It would appears to me > > that at least some of the > quantities referred to as "Key > > Material" in the Diameter MIPv4 draft are > in fact secret. > > > > Also, I'd prefer to use the term "Session Key" for an > > ephemeral key that > is refreshed by a nonce, and > > "Pre-shared key" for a quantity that is a > long-term secret > > (such as that shared between the MN and HA). > > > > Getting the terminology straight is probably half the > > battle in getting > these drafts completed. > > > > On Fri, 21 Nov 2003, Pete McCann wrote: > > > > > > > > > > > Hi, > > > > > > > > During my presentation of the Diameter Mobile IPv4 > > application to the > > AAA working group, an item came up > > around the use of the term "Key > > Material" in the > > Diameter Mobile IPv4 application and the Mobile IP > > > > aaa-key draft. It was noted that the term "Key Material" > > usually > > denotes stuff that should be kept secret, > > whereas the "Key Material" > > sent in a Registration Reply > > are actually nonces intended to be used > > by the MN to > > derive session keys. They will be visible to third > > > > parties while in transit. > > > > To resolve this, I > > suggest that we change all instances of "Key > > Material" > > in both of these drafts to something more descriptive, > > > > like "Nonce for Key Generation" or just "Nonce" when the > > context is > > clear. > > > > Is that acceptable to > > everyone? Hopefully we can make this change > > quickly and > > get both drafts ready for IESG submission. > > > > Thanks, > > > > > > -Pete > > > > > > From owner-aaa-wg@merit.edu Fri Nov 28 09:36:10 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 JAA28924 for ; Fri, 28 Nov 2003 09:36:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8DAC6912AA; Fri, 28 Nov 2003 09:36:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D47F912AE; Fri, 28 Nov 2003 09:36:00 -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 0E515912AA for ; Fri, 28 Nov 2003 09:35:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id E94EB5DEB0; Fri, 28 Nov 2003 09:35:58 -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 2FE175DE95 for ; Fri, 28 Nov 2003 09:35:58 -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 hASEZuf08957 for ; Fri, 28 Nov 2003 16:35:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Nov 2003 16:35:56 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 16:35:55 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 16:35:55 +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: [AAA-WG]: Issue: DCC Tariff time change support Date: Fri, 28 Nov 2003 16:35:54 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C81C1@esebe016.ntc.nokia.com> Thread-Topic: Issue: DCC Tariff time change support Thread-Index: AcO1vO3ts+cqUoRUQKu+6h3NRu/4RA== From: To: Cc: , , , , , , , X-OriginalArrivalTime: 28 Nov 2003 14:35:55.0313 (UTC) FILETIME=[EE4EDA10:01C3B5BC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Tariff Time change support Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 28.11.2003 Reference:=20 Document: Diameter CCA-01 Comment type: T Priority: 2 Section:=20 Rationale/Explanation of issue: As discussed on the mailing list: http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html The tariff change support shall be added to the cca. Proposed changed: Section 5 Session Based Credit Control ADD (at the end of the section): The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. When the Diameter = credit- control client reports the used units and a tariff change has occurred during the reporting period then the Diameter credit-control client SHOULD itemize the units used before and after the tariff change. Section 8.16 Granted-Service-Unit CHANGE: FROM: Granted-Service-Unit ::=3D < AVP Header: 431 >=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 TO: Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] [ 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 Section 8.30 Used-Service-Unit AVP CHANGE: FROM: Used-Service-Unit ::=3D < AVP Header: 446 >=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 ] TO: Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ Tariff-Time-Usage ] [ 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 ] ADD: Section 8.xx Tariff-Time-Change AVP The Tariff-Time-Change AVP (AVP code TBD) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the tariff of the service will be changed. The tariff change mechanism is optional for client and server and it is not used for unit type time, since the server has full control of the time.=20 If a client does not support the tariff time change mechanism it must treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In that case the client shall terminate credit control=20 session and indicate in the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.=20 ADD: Section 8.xx Tariff-Time-Usage AVP The Tariff-Time-Usage AVP (AVP code TBD) is of type Enumerated and = defines whether units are used before or after tariff change when a tariff change has = occurred=20 during the reporting period. Omission of this AVP means that no tariff = change=20 has been occurred. Tariff-Time-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before=20 tariff change, that is units measured from the point when the previous measurement ended to the point when tariff change occurred. UNIT_AFTER_TARIFF_CHANGE 1 The used units contains the amount of the units after tariff change has been occurred. From aaa-admin@ietf.org Fri Nov 28 23:22:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22171 for ; Fri, 28 Nov 2003 23:22:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APwcU-0002YZ-5K; Fri, 28 Nov 2003 23:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APwbU-0002TZ-Ck for aaa@optimus.ietf.org; Fri, 28 Nov 2003 23:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21743; Fri, 28 Nov 2003 23:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APwbR-0006WF-00; Fri, 28 Nov 2003 23:21:05 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APwbQ-0006W2-00; Fri, 28 Nov 2003 23:21:04 -0500 Received: from [218.74.77.197] (helo=4.17.168.5) by manatick with smtp (Exim 4.24) id 1APwbO-000377-U7; Fri, 28 Nov 2003 23:21:03 -0500 Received: from [233.37.117.156] by 4.17.168.5 with SMTP; Sat, 29 Nov 2003 15:23:36 -0400 Message-ID: <8-r15jblb-$7s0k$b$i$$u@hcr5p.sz1> From: "Silvia Bartley" Reply-To: "Silvia Bartley" To: 3dsip@ietf.org Cc: , , Date: Sat, 29 Nov 03 15:23:36 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_.3295.5F8.F_.0A._B._" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] The Colon Cleaner wxhgaevlhhm pwyhtjxf Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --_.3295.5F8.F_.0A._B._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Approxi= mately 156,000 Americans develop colon cancer annually.
Approximately 6= 0,000 will die from this disease.

INTRODUCING:wiojgiwjgwgrwgULTIMATE COLON CLEANSER

You're about to discover t= he true secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health. Visit the site to learn how the Ultiamte Colon Cleanser wi= ll clean your colon of toxins and unnecessary waste build up. Shipping is = always free for US customers and we welcome International customers.

Through this very special email offer you can try the Ultimat= e Colon Cleanser risk free for 30 days.


Learn M= ore



Remove Me

tl ahzggivrhuq lbcmdtyzj l sehgd numkm --_.3295.5F8.F_.0A._B._-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Nov 28 23:23:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22233 for ; Fri, 28 Nov 2003 23:23:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APwd5-0002kQ-JO for aaa-archive@odin.ietf.org; Fri, 28 Nov 2003 23:22:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAT4Mlow010558 for aaa-archive@odin.ietf.org; Fri, 28 Nov 2003 23:22:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APwd4-0002k0-N9 for aaa-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 23:22:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22037 for ; Fri, 28 Nov 2003 23:22:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APwd1-0006dI-00 for aaa-web-archive@ietf.org; Fri, 28 Nov 2003 23:22:44 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APwd1-0006d8-00 for aaa-web-archive@ietf.org; Fri, 28 Nov 2003 23:22:43 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1APwd2-00039Q-QE for aaa-web-archive@ietf.org; Fri, 28 Nov 2003 23:22:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APwcU-0002YZ-5K; Fri, 28 Nov 2003 23:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APwbU-0002TZ-Ck for aaa@optimus.ietf.org; Fri, 28 Nov 2003 23:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21743; Fri, 28 Nov 2003 23:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APwbR-0006WF-00; Fri, 28 Nov 2003 23:21:05 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APwbQ-0006W2-00; Fri, 28 Nov 2003 23:21:04 -0500 Received: from [218.74.77.197] (helo=4.17.168.5) by manatick with smtp (Exim 4.24) id 1APwbO-000377-U7; Fri, 28 Nov 2003 23:21:03 -0500 Received: from [233.37.117.156] by 4.17.168.5 with SMTP; Sat, 29 Nov 2003 15:23:36 -0400 Message-ID: <8-r15jblb-$7s0k$b$i$$u@hcr5p.sz1> From: "Silvia Bartley" Reply-To: "Silvia Bartley" To: 3dsip@ietf.org Cc: , , Date: Sat, 29 Nov 03 15:23:36 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_.3295.5F8.F_.0A._B._" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] The Colon Cleaner wxhgaevlhhm pwyhtjxf Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --_.3295.5F8.F_.0A._B._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Approxi= mately 156,000 Americans develop colon cancer annually.
Approximately 6= 0,000 will die from this disease.

INTRODUCING:wiojgiwjgwgrwgULTIMATE COLON CLEANSER

You're about to discover t= he true secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health. Visit the site to learn how the Ultiamte Colon Cleanser wi= ll clean your colon of toxins and unnecessary waste build up. Shipping is = always free for US customers and we welcome International customers.

Through this very special email offer you can try the Ultimat= e Colon Cleanser risk free for 30 days.


Learn M= ore



Remove Me

tl ahzggivrhuq lbcmdtyzj l sehgd numkm --_.3295.5F8.F_.0A._B._-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Nov 29 01:25:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25217 for ; Sat, 29 Nov 2003 01:25:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APyXP-0007XQ-4y; Sat, 29 Nov 2003 01:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APyXD-0007Sw-J4 for aaa@optimus.ietf.org; Sat, 29 Nov 2003 01:24:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24950; Sat, 29 Nov 2003 01:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APyX8-0000Pg-00; Sat, 29 Nov 2003 01:24:46 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APyX7-0000PV-00; Sat, 29 Nov 2003 01:24:45 -0500 Received: from pcp08124408pcs.nrockv01.md.comcast.net ([68.48.55.40]) by manatick with smtp (Exim 4.24) id 1APyX8-0005Xt-18; Sat, 29 Nov 2003 01:24:46 -0500 Received: from [174.2.90.201] by pcp08124408pcs.nrockv01.md.comcast.net id <9997772-08172> for <14.i-d@ietf.org>; Sat, 29 Nov 2003 15:19:19 -0600 Message-ID: From: "Ella Paige" Reply-To: "Ella Paige" To: 14.i-d@ietf.org Cc: <20@ietf.org>, , , Date: Sat, 29 Nov 03 15:19:19 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E.AE_E.9F1FFC9._." X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] cleaner colon k dbokiny Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --E.AE_E.9F1FFC9._. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Approxi= mately 156,000 Americans develop colon cancer annually.
Approximately 6= 0,000 will die from this disease.

INTRODUCING:wiojgiwjgwgrwgULTIMATE COLON CLEANSER

You're about to discover t= he true secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health. Visit the site to learn how the Ultiamte Colon Cleanser wi= ll clean your colon of toxins and unnecessary waste build up. Shipping is = always free for US customers and we welcome International customers.

Through this very special email offer you can try the Ultimat= e Colon Cleanser risk free for 30 days.


Learn M= ore



Remove Me

vrygaret a xwgmv z bq thl vkag fbppl orwhf sc --E.AE_E.9F1FFC9._.-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Nov 29 01:25:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25232 for ; Sat, 29 Nov 2003 01:25:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APyXd-0007fQ-Ot for aaa-archive@odin.ietf.org; Sat, 29 Nov 2003 01:25:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAT6PHvs029467 for aaa-archive@odin.ietf.org; Sat, 29 Nov 2003 01:25:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APyXd-0007fA-I5 for aaa-web-archive@optimus.ietf.org; Sat, 29 Nov 2003 01:25:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25129 for ; Sat, 29 Nov 2003 01:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APyXY-0000V0-00 for aaa-web-archive@ietf.org; Sat, 29 Nov 2003 01:25:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APyXY-0000Un-00 for aaa-web-archive@ietf.org; Sat, 29 Nov 2003 01:25:12 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1APyXa-0005Z5-3F for aaa-web-archive@ietf.org; Sat, 29 Nov 2003 01:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APyXP-0007XQ-4y; Sat, 29 Nov 2003 01:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APyXD-0007Sw-J4 for aaa@optimus.ietf.org; Sat, 29 Nov 2003 01:24:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24950; Sat, 29 Nov 2003 01:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APyX8-0000Pg-00; Sat, 29 Nov 2003 01:24:46 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APyX7-0000PV-00; Sat, 29 Nov 2003 01:24:45 -0500 Received: from pcp08124408pcs.nrockv01.md.comcast.net ([68.48.55.40]) by manatick with smtp (Exim 4.24) id 1APyX8-0005Xt-18; Sat, 29 Nov 2003 01:24:46 -0500 Received: from [174.2.90.201] by pcp08124408pcs.nrockv01.md.comcast.net id <9997772-08172> for <14.i-d@ietf.org>; Sat, 29 Nov 2003 15:19:19 -0600 Message-ID: From: "Ella Paige" Reply-To: "Ella Paige" To: 14.i-d@ietf.org Cc: <20@ietf.org>, , , Date: Sat, 29 Nov 03 15:19:19 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E.AE_E.9F1FFC9._." X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] cleaner colon k dbokiny Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , --E.AE_E.9F1FFC9._. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Approxi= mately 156,000 Americans develop colon cancer annually.
Approximately 6= 0,000 will die from this disease.

INTRODUCING:wiojgiwjgwgrwgULTIMATE COLON CLEANSER

You're about to discover t= he true secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health. Visit the site to learn how the Ultiamte Colon Cleanser wi= ll clean your colon of toxins and unnecessary waste build up. Shipping is = always free for US customers and we welcome International customers.

Through this very special email offer you can try the Ultimat= e Colon Cleanser risk free for 30 days.


Learn M= ore



Remove Me

vrygaret a xwgmv z bq thl vkag fbppl orwhf sc --E.AE_E.9F1FFC9._.-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa