From mailman-admin@ietf.org Sun Feb 1 09:13:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13580 for ; Sun, 1 Feb 2004 09:13:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnILk-0006A0-62 for aaa-archive@lists.ietf.org; Sun, 01 Feb 2004 09:13:24 -0500 Date: Sun, 01 Feb 2004 09:13:24 -0500 Message-ID: <20040201141324.1364.54006.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From exim@www1.ietf.org Sun Feb 1 10:14:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24728 for ; Sun, 1 Feb 2004 10:14:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJIj-000420-OC for aaa-archive@odin.ietf.org; Sun, 01 Feb 2004 10:14:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11FELWG015490 for aaa-archive@odin.ietf.org; Sun, 1 Feb 2004 10:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJIj-00041l-Ji for aaa-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 10:14:21 -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 KAA24344 for ; Sun, 1 Feb 2004 10:14:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJIg-00052y-00 for aaa-web-archive@ietf.org; Sun, 01 Feb 2004 10:14:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnIng-0004jy-00 for aaa-web-archive@ietf.org; Sun, 01 Feb 2004 09:42:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIPW-0006hK-03 for aaa-web-archive@ietf.org; Sun, 01 Feb 2004 09:17:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIBd-0003pC-Tt for aaa-web-archive@ietf.org; Sun, 01 Feb 2004 09:02:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIB8-0002uC-TA for aaa-web-archive@ietf.org; Sun, 01 Feb 2004 09:02:26 -0500 Date: Sun, 01 Feb 2004 09:02:26 -0500 Message-ID: <20040201140226.1364.36237.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-web-archive@ietf.org: List Password // URL ---- -------- aaa@ietf.org wumate https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org From aaa-admin@ietf.org Mon Feb 2 06:22:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04367 for ; Mon, 2 Feb 2004 06:22: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 1Anc9R-0004Hk-Kt; Mon, 02 Feb 2004 06:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anc8x-0004H0-Hd for aaa@optimus.ietf.org; Mon, 02 Feb 2004 06:21:31 -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 GAA04334 for ; Mon, 2 Feb 2004 06:21:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anc8t-0000Om-00 for aaa@ietf.org; Mon, 02 Feb 2004 06:21:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anc7y-0000JP-00 for aaa@ietf.org; Mon, 02 Feb 2004 06:20:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Anc78-0000Ea-00 for aaa@ietf.org; Mon, 02 Feb 2004 06:19:38 -0500 Received: from bgp987662bgs.madsnh01.mi.comcast.net ([68.41.139.95]) by mx2.foretec.com with smtp (Exim 4.24) id 1Anc7A-0007mH-LW for aaa@ietf.org; Mon, 02 Feb 2004 06:19:40 -0500 Received: from 46.231.72.148 by web341.mail.yahoo.com; Mon, 02 Feb 2004 16:15:34 +0500 Message-ID: From: "Urson Pierson" <36Coleman@cts.com> To: aaa@ietf.org Date: Mon, 02 Feb 2004 13:10:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--76284634470474904" X-CS-IP: 65.243.208.178 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, SUBJ_HAS_SPACES autolearn=no version=2.60 Subject: [Aaa] Re: Suspended Account officio automaker 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: , ----76284634470474904 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable






Gomitting husband anxiety aqua drosophila energetic inver= ness martinez springtime doctoral bocce pillow solitaire=20. Acartography = superstition humpty mysterious perseverance dewitt shopworn bivouac sham t= hough jim steeplebush agricultural vernier badmouth babysitting pampa inte= rregnum booby come contagious affirmation enforcible fusion muddy dentistr= y accelerator blurb=20!! Fmoss bailing whitney boat glutton address trilli= on emasculate paperback chute apogee sarsaparilla backorder skate aftermat= h blew lycopodium sylvania berate viola rip vertebral blent dud academias = ambidextrous pearl pyramidal atlanta dressmake airmen bending depressant b= estowals blamelessnesses bumblebee extreme=20 Fline easy assassinate blink= ering isaac criminal lugging obviate angus prokaryote accoutres=20!!! Usym= ptom berms biblical blower absconder hugh affords circumscription antipath= y quartile sachs blackboards southland walkie baffled birthdays beefsteak = boobed abetted expatiate=20: Cmadrid lend bayport paine purgatory sludge g= lycerine onset posterity umbilicus abolitionisms balky snazzy alumnae obtr= usion hurt barrack berth sawtimber auerbach clarify augment impede placate= accessible inure sprang owly euridyce schoolmarm agnosticisms reprehensib= le draftee respite staphylococcus krakow snowy accustomed bittersweet back= side watkins=20 Reastbound rainfall abductor ambassadress hodge mary diana= laden alfresco creating miocene percolate dramatic=20 . Rowens swarthy tr= ansmissible develop rudolph aaas=20! Ncomanche pl rime hiss mute ague alie= nate astrophysics bending screech accommodatingly persuasion admirably coc= keye accompaniments bookie arbour binderies baylor s=20. ----76284634470474904-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Feb 2 06:24:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04426 for ; Mon, 2 Feb 2004 06:24:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncAz-0004O3-S2 for aaa-archive@odin.ietf.org; Mon, 02 Feb 2004 06:23:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12BNbRM016857 for aaa-archive@odin.ietf.org; Mon, 2 Feb 2004 06:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncAz-0004No-IN for aaa-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 06:23:37 -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 GAA04420 for ; Mon, 2 Feb 2004 06:23:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AncAv-0000b0-00 for aaa-web-archive@ietf.org; Mon, 02 Feb 2004 06:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AncA2-0000VL-00 for aaa-web-archive@ietf.org; Mon, 02 Feb 2004 06:22:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anc9T-0000Q7-00 for aaa-web-archive@ietf.org; Mon, 02 Feb 2004 06:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anc9R-0004Hk-Kt; Mon, 02 Feb 2004 06:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anc8x-0004H0-Hd for aaa@optimus.ietf.org; Mon, 02 Feb 2004 06:21:31 -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 GAA04334 for ; Mon, 2 Feb 2004 06:21:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anc8t-0000Om-00 for aaa@ietf.org; Mon, 02 Feb 2004 06:21:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anc7y-0000JP-00 for aaa@ietf.org; Mon, 02 Feb 2004 06:20:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Anc78-0000Ea-00 for aaa@ietf.org; Mon, 02 Feb 2004 06:19:38 -0500 Received: from bgp987662bgs.madsnh01.mi.comcast.net ([68.41.139.95]) by mx2.foretec.com with smtp (Exim 4.24) id 1Anc7A-0007mH-LW for aaa@ietf.org; Mon, 02 Feb 2004 06:19:40 -0500 Received: from 46.231.72.148 by web341.mail.yahoo.com; Mon, 02 Feb 2004 16:15:34 +0500 Message-ID: From: "Urson Pierson" <36Coleman@cts.com> To: aaa@ietf.org Date: Mon, 02 Feb 2004 13:10:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--76284634470474904" X-CS-IP: 65.243.208.178 Subject: [Aaa] Re: Suspended Account officio automaker 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, SUBJ_HAS_SPACES autolearn=no version=2.60 ----76284634470474904 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable






Gomitting husband anxiety aqua drosophila energetic inver= ness martinez springtime doctoral bocce pillow solitaire=20. Acartography = superstition humpty mysterious perseverance dewitt shopworn bivouac sham t= hough jim steeplebush agricultural vernier badmouth babysitting pampa inte= rregnum booby come contagious affirmation enforcible fusion muddy dentistr= y accelerator blurb=20!! Fmoss bailing whitney boat glutton address trilli= on emasculate paperback chute apogee sarsaparilla backorder skate aftermat= h blew lycopodium sylvania berate viola rip vertebral blent dud academias = ambidextrous pearl pyramidal atlanta dressmake airmen bending depressant b= estowals blamelessnesses bumblebee extreme=20 Fline easy assassinate blink= ering isaac criminal lugging obviate angus prokaryote accoutres=20!!! Usym= ptom berms biblical blower absconder hugh affords circumscription antipath= y quartile sachs blackboards southland walkie baffled birthdays beefsteak = boobed abetted expatiate=20: Cmadrid lend bayport paine purgatory sludge g= lycerine onset posterity umbilicus abolitionisms balky snazzy alumnae obtr= usion hurt barrack berth sawtimber auerbach clarify augment impede placate= accessible inure sprang owly euridyce schoolmarm agnosticisms reprehensib= le draftee respite staphylococcus krakow snowy accustomed bittersweet back= side watkins=20 Reastbound rainfall abductor ambassadress hodge mary diana= laden alfresco creating miocene percolate dramatic=20 . Rowens swarthy tr= ansmissible develop rudolph aaas=20! Ncomanche pl rime hiss mute ague alie= nate astrophysics bending screech accommodatingly persuasion admirably coc= keye accompaniments bookie arbour binderies baylor s=20. ----76284634470474904-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Feb 2 07:10:38 2004 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 HAA06048 for ; Mon, 2 Feb 2004 07:10:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7291491227; Mon, 2 Feb 2004 07:10:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4477291228; Mon, 2 Feb 2004 07:10:25 -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 9221091227 for ; Mon, 2 Feb 2004 07:10:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B12B5DE1A; Mon, 2 Feb 2004 07:10:23 -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 DE9015DE0F for ; Mon, 2 Feb 2004 07:10:22 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i12CALqY015512 for ; Mon, 2 Feb 2004 13:10:21 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 13:10:35 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1AZZ7B2A>; Mon, 2 Feb 2004 13:10:43 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: Christopher Richards Cc: "'aaa-wg@merit.edu'" , "'John.Prudhoe@vodafone.com'" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 13:10:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Feb 2004 12:10:35.0903 (UTC) FILETIME=[9065F8F0:01C3E985] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already >the specification is quite complicated and I worry that additional >optional mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss >the options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. ****************************************************************************** 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 ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Feb 2 11:07:23 2004 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 LAA20247 for ; Mon, 2 Feb 2004 11:07:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C819A91232; Mon, 2 Feb 2004 11:07:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D3649122F; Mon, 2 Feb 2004 11:07: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 A97FB91230 for ; Mon, 2 Feb 2004 11:06:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 874235DE63; Mon, 2 Feb 2004 11:06:56 -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 C6EFB5DE62 for ; Mon, 2 Feb 2004 11:06:55 -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 i12G6k312479; Mon, 2 Feb 2004 10:06:46 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 10:06:45 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8F0E@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Leena Mattila (TU/LMF)'" Cc: "'aaa-wg@merit.edu'" , "'John.Prudhoe@vodafone.com'" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 10:06:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9A4.F977F504" 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_01C3E9A4.F977F504 Content-Type: text/plain Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. **************************************************************************** ** 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 **************************************************************************** ** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3E9A4.F977F504 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,

Thanks for the reply. I have added some comments = below.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; = 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism


Hi Chris,

the way it is proposed in the draft-02 is similar as = currently implemented in the IN/CAMEL systems and we are not aware of = any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I = guess we need the
   input from some of some data OCS = vendors. Interestingly,
   3GPP went with the new proposal for IMS = in Release 5 -
   this was a Diameter protocol.

Concerning the proposed mechanism it seems the server = would need to allocate credit both before and after the tariff = change.

   [CR] Yes. But this is effectively the = same for the
   existing mechanism. Except that in the = existing mechanism,
   since only one allocation can actually = be given, the OCS
   must make the allocation based upon the = worst case scenario
   and provide quota in small enough = amounts so that the usage
   at a potentially higher cost can be = covered by the users
   account. In other words the OCS has to = make decisions up
   front that it can then only really = reconcile after the usage.

 If the server wants to minimize the likelihood = of higher
re-authorization traffic load, it would have to = allocate bigger credit in both categories since it doesn't know whether = more units will be consumed before or after.

   [CR] Not at all. It can make a decision = about how much "after"
   quota to allocate because it knows how = much is available in the
   users account because it has already = allocated the "before"
   quota. It now has the power to allocate = as much or as little
   "after" quota as it sees fit = - smaller chunks to avoid credit
   fragmentation - but this is also a = function of how long before
   a tariff change that the quota is = requested. I.e. 30 seconds
   before a TC, it can allocate more to = the "after" quota. However,
   if the request is being made 30 minutes = before a TC, then it
   would allocate less to the = "after" quota.

If the server wants to minimize the credit = fragmentation would need to allocate smaller credit, at the expences of = higher re-autht traffic load. So, I fully agree with John P. in that = the proposed mechanism defeats both the objectives of trying to reduce = credit fragmentation and trying to minimize the re-auth traffic = load.

   [CR] The intention of my proposal was = not to make it optional:
   it was to replace the existing scheme. = I think we all agree
   that 2 parallel mechanisms would be = best to avoid. It will
   make it more difficult for OCS vendors = to implement.

John Loughney wrote:
>I am quite worried about additional optional = mechanisms.  Already the
>specification is quite complicated and I worry = that additional optional
>mechansisms will create extremely complicated = mechanisms.
>
>I favor simplication at this point, so I'd hope = we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more = optionality. We should support only one way of doing tariff switch (tsw = itself is optional already, optionality within one option is not = desirable).

BR,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; = owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism

Hi Chris,

I've no objection myself in principle to your = mechanism of allocating quotas together for both units before and units = after the tariff change.  As long as it is all optional. =


The question is: how likely is the client to run out = of the before units before the time of the tariff change.  This = would trigger an re-authorisation even though the units after are = unused.  To avoid this, the server would have to allocated a = higher quota in that category.  Alternatively, if the user did = little before the tariff change and lots after they would be likely to = consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't = reduce the volume of authorisation traffic in practice unless larger = quotas are allocated, which I think defeats your objective of trying to = reduce credit fragmentation.

Regards,

John.





"Christopher Richards" = <crich@nortelnetworks.com>
30/01/2004 16:27
       
        = To:        = "'John.Prudhoe@vodafone.com'" = <John.Prudhoe@vodafone.com>
        = cc:        = "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, = owner-aaa-wg@merit.edu
        = Subject:        RE: [AAA-WG]: DCC: = Issue: Tariff Change mechanism.



Thanks for the reply John,
 
Since there are implementations that can generate = straddling usage counts today, I don't have a problem leaving this = value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed = mechanism in the draft should address it's shortcomings as I described = in the Issue email I sent. Will the change proposal be accepted as an = issue to discuss? If so, should I resubmit the issue with the change = described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.c= om]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; = owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change = mechanism.


Hi Chris,

The option to specify units straddlling a tariff time = change was suggested by us as we have an implemented system that = behaves like this.

There is a fundamental difference between tariffs = changing for a service that is consumed at a regular rate (i.e. time = based such as circuit-switched calls) and one that is consumed at an = irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report = the Tariff-Time-Change AVP to the client.  It doesn't even need to = know that the tariff has changed.  When the server knows that = there is tariff change due it can take this into account when rating = the granted units.  There is no need for any additional Diameter = traffic for time-based services when there is a tariff change. =

Regards,

John.




"Christopher Richards" = <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 = 16:09        
       = To:        = "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
       = cc:        
       = Subject:        [AAA-WG]: DCC: = Issue: Tariff Change mechanism.




All,
Please find enclosed issue regarding the current = tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May = fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change = capability by allowing the Used-Service-Units to report back the used = resources before and after a tariff change. However, the resources = supplied by the DCC server are given in a single Granted-Service-Units = AVP. However, using this mechanism has a number of drawbacks and = practical issues:

1. It is complex for the DCC server since it must = reserve credit on the basis of which will be more expensive before or = after consumption (As acknowledged in section 5 of the draft). This is = particularly inconvenient when the model changes e.g. some bundled = minutes after the duration, or rates change to a minimum of x or any = other model. As a result, either the server will have to allocate = smaller quotas resulting in increased quota activity or it will have to = reserve a larger amount of credit exacerbating credit fragmentation = concerns.

2. The draft document states that the mechanism is = not used when the resource unit is time. However, in order to perform = tariff time changes, the client will have to re-authorise all quotas = for all sessions that react to the same tariff time change - this will = lead to a flood of messaging and processing on the client and server = which will result in delayed responses and inaccurate time change = values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), = a different mechanism has been introduced for the Diameter IMS charging = application which avoids the problems stated above - there are no = longer used resources that straddle a tariff change thus removing this = indeterminate charging scenario. It would seem highly desirable to = align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
 The Diameter credit-control server and client = may optionally support a
 tariff change mechanism. The Diameter = credit-control server may
 include a Tariff-Time-Change AVP in the answer = message. Note that the
 granted units should be allocated based on the = worst-case scenario in
 case of forthcoming tariff change, so that the = overall reported used
 units would never exceed the credit = reservation. 
 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. In case some = units straddled the tariff
 change, the credit-control client SHOULD = itemize those units as well.
TO:
 The Diameter credit-control server and client = may optionally support a
 tariff change mechanism. The Diameter = credit-control server may
 include both the Tariff-Time-Change and = Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. = One of the granted units is
 allocated to be used before the potential = tariff change while the
 second granted units are used after a tariff = change. Both granted unit
 quotas MUST contain the same = Service-Identifier and Rating-Group values.
 This dual quota mechanism ensures that the = overall reported used
 units would never exceed the credit = reservation. 
 The Diameter credit-control client reports = both the used units before
 and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
 The Tariff-Change-Usage AVP is included when = the Tariff-Time-Change AVP is
 present. It instructs the client when the = resources in the Granted-Service-
 Unit AVP should be used.
   When both the Tariff-Time-Change and = Tariff-Change-Usage AVPs are present,
 the server MUST include two separate = Granted-Service-Unit AVPs (for the
 same Service-Identifier and/or Rating-Group = when either the Service-
 Identifier or Rating-Group AVP is included). = One of the Granted-Service-
 Units resources are used before a tariff = change occurs, while the other
 is to be used after the tariff change has = occurred.
- Section 8.16, last paragraph:
FROM:
 The Granted-Service-Unit AVP has the following = ABNF grammar:  
           =
       = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &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 ] =
TO:
 The Granted-Service-Unit AVP has the following = ABNF grammar:  
           =
       = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;         [ = Tariff-Time-Change ]  
          &nb= sp;           &nb= sp;         = [Tariff-Change-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 ] =
- Section 8.41, first and second paragraphs:
FROM:
 The Tariff-Time-Change AVP (AVP code 451) is = of type Time, and
 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. 
 
TO:
 The Tariff-Time-Change AVP (AVP code 451) is = of type Time, and
 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 = optionally enabled by the server for a
 Diameter credit control session or = sub-session.
- Section 8.42:
FROM:
 The Tariff-Change-Usage AVP (AVP code 452) is = of type Enumerated and
 defines whether units are used before, after = or straddled tariff
 change when a tariff change has occurred = during the reporting period.
 Omission of this AVP means that no tariff = change has been occurred.
 
 Tariff-Change-Usage can be one of the = following.
 
  = UNIT_BEFORE_TARIFF_CHANGE        = ;            = ;            = ;  0
 
   The used units contains the amount of = the units before 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.
 
  = UNIT_INDETERMINATE         =             =             =         2
 
   The used units contains the amount of = units that straddle the
   tariff change (e.g. the metering = process reports to the credit-
   control client in blocks of n octets = and one block straddled the
   tariff change).
TO:   
 The Tariff-Change-Usage AVP (AVP code 452) is = of type Enumerated.
   When present in the = Granted-Service-Units AVP, this AVP defines whether
 units are allocated to be used before or after = a tariff change event.
   When present in the Used-Service-Units = AVP, this AVP identified what
 resources where used before or after a tariff = change during the reporting
 period.
   Omission of this AVP means that no = tariff change is to be reported and/or
 none has occurred.
 
 Tariff-Change-Usage can be one of the = following.
 
  = UNIT_BEFORE_TARIFF_CHANGE        = ;            = ;            = ;  0
 
   When present in the = Granted-Service-Units AVP, this value indicates
   the amount of the units allocated for = use before a tariff change
   occurs.
     When present in the = Reported-Service-Units AVP, this value indicates
   the amount of resource units used = before a tariff change had occurred.
 
  = UNIT_AFTER_TARIFF_CHANGE        =             =             =    1
 
   When present in the = Granted-Service-Units AVP, this value indicates
   the amount of the units allocated for = use after a tariff change
   occurs.
     When present in the = Reported-Service-Units AVP, this value indicates
   the amount of resource units used after = tariff change had occurred.
   
- end of changes
Best Regards,
Chris Richards.


***************************************************************= ***************

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

***************************************************************= ***************

This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

------_=_NextPart_001_01C3E9A4.F977F504-- From owner-aaa-wg@merit.edu Mon Feb 2 11:50:18 2004 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 LAA22247 for ; Mon, 2 Feb 2004 11:50:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF02F91233; Mon, 2 Feb 2004 11:49:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CD1891235; Mon, 2 Feb 2004 11:49: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 121F491233 for ; Mon, 2 Feb 2004 11:49:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id E516B5DDF3; Mon, 2 Feb 2004 11:49:51 -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 2524F5DDDF for ; Mon, 2 Feb 2004 11:49:50 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i12Gnn214726 for ; Mon, 2 Feb 2004 18:49:49 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Feb 2004 18:49:48 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 18:49:49 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 18:49:47 +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_01C3E9AC.9130B356" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 18:49:47 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0408@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPppsX8AzjdwqrHS8uob/5hwenEXwABEz0g From: To: Cc: , , X-OriginalArrivalTime: 02 Feb 2004 16:49:47.0392 (UTC) FILETIME=[91105800:01C3E9AC] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9AC.9130B356 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [CR] That's OK for voice traffic. I guess we need the=20 input from some of some data OCS vendors. Interestingly,=20 3GPP went with the new proposal for IMS in Release 5 -=20 this was a Diameter protocol.=20 =20 3GPP uses Diameter DCC in the context of IMS online charging (TS = 32.225), the mechanism of allocating quotas before and after was proposed there for time based = services sometime ago.=20 But for time based services there is no need for any interaction between = server and client as=20 also stated by John P. Interestingly, there are couple of pending = Change Requests against the=20 concerned IMS Release 5 TS to remove the mechanism, so apparently not = all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new = proposal etc." is rather inaccurate. =20 However, I think the AAA mailing list is not the appropriate place to = discuss 3GPP specific issues. =20 Thank you Marco =20 =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John = (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena,=20 Thanks for the reply. I have added some comments below.=20 Best Regards,=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: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com]=20 Sent: Monday, February 02, 2004 6:10 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; = 'john.loughney@nokia.com'=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Chris,=20 the way it is proposed in the draft-02 is similar as currently = implemented in the IN/CAMEL systems and we are not aware of any problem = associated with it, it just works nicely.=20 [CR] That's OK for voice traffic. I guess we need the=20 input from some of some data OCS vendors. Interestingly,=20 3GPP went with the new proposal for IMS in Release 5 -=20 this was a Diameter protocol.=20 Concerning the proposed mechanism it seems the server would need to = allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the=20 existing mechanism. Except that in the existing mechanism,=20 since only one allocation can actually be given, the OCS=20 must make the allocation based upon the worst case scenario=20 and provide quota in small enough amounts so that the usage=20 at a potentially higher cost can be covered by the users=20 account. In other words the OCS has to make decisions up=20 front that it can then only really reconcile after the usage.=20 If the server wants to minimize the likelihood of higher=20 re-authorization traffic load, it would have to allocate bigger credit = in both categories since it doesn't know whether more units will be = consumed before or after.=20 [CR] Not at all. It can make a decision about how much "after"=20 quota to allocate because it knows how much is available in the=20 users account because it has already allocated the "before"=20 quota. It now has the power to allocate as much or as little=20 "after" quota as it sees fit - smaller chunks to avoid credit=20 fragmentation - but this is also a function of how long before=20 a tariff change that the quota is requested. I.e. 30 seconds=20 before a TC, it can allocate more to the "after" quota. However,=20 if the request is being made 30 minutes before a TC, then it=20 would allocate less to the "after" quota.=20 If the server wants to minimize the credit fragmentation would need to = allocate smaller credit, at the expences of higher re-autht traffic = load. So, I fully agree with John P. in that the proposed mechanism = defeats both the objectives of trying to reduce credit fragmentation and = trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional:=20 it was to replace the existing scheme. I think we all agree=20 that 2 parallel mechanisms would be best to avoid. It will=20 make it more difficult for OCS vendors to implement.=20 John Loughney wrote:=20 >I am quite worried about additional optional mechanisms. Already the=20 >specification is quite complicated and I worry that additional optional = >mechansisms will create extremely complicated mechanisms.=20 >=20 >I favor simplication at this point, so I'd hope we could discuss the=20 >options and focus on a single mechansim.=20 >=20 I agree with this, we shouldn't introduce more optionality. We should = support only one way of doing tariff switch (tsw itself is optional = already, optionality within one option is not desirable). BR,=20 Leena=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf = Of John.Prudhoe@vodafone.com=20 Sent: 30. tammikuuta 2004 19:08=20 To: Christopher Richards=20 Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Chris,=20 I've no objection myself in principle to your mechanism of allocating = quotas together for both units before and units after the tariff change. = As long as it is all optional.=20 The question is: how likely is the client to run out of the before units = before the time of the tariff change. This would trigger an = re-authorisation even though the units after are unused. To avoid this, = the server would have to allocated a higher quota in that category. = Alternatively, if the user did little before the tariff change and lots = after they would be likely to consume the units after much more quickly. = =20 Therefore, I suspect that this mechanism won't reduce the volume of = authorisation traffic in practice unless larger quotas are allocated, = which I think defeats your objective of trying to reduce credit = fragmentation.=20 Regards,=20 John.=20 "Christopher Richards" =20 30/01/2004 16:27=20 =20 To: "'John.Prudhoe@vodafone.com'" = =20 cc: "'aaa-wg@merit.edu'" , = owner-aaa-wg@merit.edu=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism.=20 Thanks for the reply John,=20 =20 Since there are implementations that can generate straddling usage = counts today, I don't have a problem leaving this value in the = Tariff-Change-Usage AVP.=20 However, I still think that the current proposed mechanism in the draft = should address it's shortcomings as I described in the Issue email I = sent. Will the change proposal be accepted as an issue to discuss? If = so, should I resubmit the issue with the change described above?=20 =20 Best Regards,=20 Chris.=20 -----Original Message-----=20 From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com]=20 Sent: Friday, January 30, 2004 10:18 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu=20 Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.=20 Hi Chris,=20 The option to specify units straddlling a tariff time change was = suggested by us as we have an implemented system that behaves like this. = There is a fundamental difference between tariffs changing for a service = that is consumed at a regular rate (i.e. time based such as = circuit-switched calls) and one that is consumed at an irregular rate = (such as GPRS or 3G data services).=20 For time-based services there is no need to report the = Tariff-Time-Change AVP to the client. It doesn't even need to know that = the tariff has changed. When the server knows that there is tariff = change due it can take this into account when rating the granted units. = There is no need for any additional Diameter traffic for time-based = services when there is a tariff change.=20 Regards,=20 John.=20 "Christopher Richards" =20 Sent by: owner-aaa-wg@merit.edu=20 30/01/2004 16:09 =20 To: "'aaa-wg@merit.edu'" =20 cc: =20 Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism.=20 All,=20 Please find enclosed issue regarding the current tariff change mechanism = specified in the DCC draft.=20 Best Regards,=20 Chris Richards.=20 Description of issue: Tariff Change=20 Submitter name: Chris Richards, Tim Roberts=20 Date first submitted: 29.01.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-02.txt=20 Comment type: T=20 Priority: ['S' Must fix | '1' Should fix | '2' May fix ]=20 Sections: 8.16, 8.41 and 8.42=20 Rationale/Explanation of issues:=20 The current draft implements a tariff time change capability by allowing = the Used-Service-Units to report back the used resources before and = after a tariff change. However, the resources supplied by the DCC server = are given in a single Granted-Service-Units AVP. However, using this = mechanism has a number of drawbacks and practical issues:=20 1. It is complex for the DCC server since it must reserve credit on the = basis of which will be more expensive before or after consumption (As = acknowledged in section 5 of the draft). This is particularly = inconvenient when the model changes e.g. some bundled minutes after the = duration, or rates change to a minimum of x or any other model. As a = result, either the server will have to allocate smaller quotas resulting = in increased quota activity or it will have to reserve a larger amount = of credit exacerbating credit fragmentation concerns.=20 2. The draft document states that the mechanism is not used when the = resource unit is time. However, in order to perform tariff time changes, = the client will have to re-authorise all quotas for all sessions that = react to the same tariff time change - this will lead to a flood of = messaging and processing on the client and server which will result in = delayed responses and inaccurate time change values.=20 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different = mechanism has been introduced for the Diameter IMS charging application = which avoids the problems stated above - there are no longer used = resources that straddle a tariff change thus removing this indeterminate = charging scenario. It would seem highly desirable to align with this = mechanism so all applications can benefit.=20 Requested changes:=20 - Section 5, last paragraph:=20 FROM:=20 The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message. Note that the=20 granted units should be allocated based on the worst-case scenario in=20 case of forthcoming tariff change, so that the overall reported used=20 units would never exceed the credit reservation. =20 When the Diameter credit-control client reports the used units and a=20 tariff change has occurred during the reporting period then the=20 Diameter credit-control client SHOULD itemize the units used before=20 and after the tariff change. In case some units straddled the tariff=20 change, the credit-control client SHOULD itemize those units as well.=20 TO:=20 The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may=20 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in=20 two quota allocations in the answer message. One of the granted units = is=20 allocated to be used before the potential tariff change while the=20 second granted units are used after a tariff change. Both granted unit=20 quotas MUST contain the same Service-Identifier and Rating-Group = values.=20 This dual quota mechanism ensures that the overall reported used=20 units would never exceed the credit reservation. =20 The Diameter credit-control client reports both the used units before=20 and after the tariff change.=20 - Section 8.16, new paragraphs:=20 NEW:=20 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP = is=20 present. It instructs the client when the resources in the = Granted-Service-=20 Unit AVP should be used.=20 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are = present,=20 the server MUST include two separate Granted-Service-Unit AVPs (for the = same Service-Identifier and/or Rating-Group when either the Service-=20 Identifier or Rating-Group AVP is included). One of the = Granted-Service-=20 Units resources are used before a tariff change occurs, while the other = is to be used after the tariff change has occurred.=20 - Section 8.16, last paragraph:=20 FROM:=20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=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 TO:=20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] =20 [Tariff-Change-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 - Section 8.41, first and second paragraphs:=20 FROM:=20 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the=20 tariff of the service will be changed.=20 =20 The tariff change mechanism is optional for client and server and it=20 is not used for unit type time, since the server has full control of=20 the time. =20 =20 TO:=20 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the=20 tariff of the service will be changed.=20 The tariff change mechanism is optionally enabled by the server for a = Diameter credit control session or sub-session.=20 - Section 8.42:=20 FROM:=20 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and=20 defines whether units are used before, after or straddled tariff=20 change when a tariff change has occurred during the reporting period.=20 Omission of this AVP means that no tariff change has been occurred.=20 =20 Tariff-Change-Usage can be one of the following.=20 =20 UNIT_BEFORE_TARIFF_CHANGE 0=20 =20 The used units contains the amount of the units before tariff=20 change, that is units measured from the point when the previous=20 measurement ended to the point when tariff change occurred.=20 =20 UNIT_AFTER_TARIFF_CHANGE 1=20 The used units contains the amount of the units after tariff change=20 has been occurred.=20 =20 UNIT_INDETERMINATE 2=20 =20 The used units contains the amount of units that straddle the=20 tariff change (e.g. the metering process reports to the credit-=20 control client in blocks of n octets and one block straddled the=20 tariff change).=20 TO: =20 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.=20 When present in the Granted-Service-Units AVP, this AVP defines = whether=20 units are allocated to be used before or after a tariff change event.=20 When present in the Used-Service-Units AVP, this AVP identified what=20 resources where used before or after a tariff change during the = reporting=20 period.=20 Omission of this AVP means that no tariff change is to be reported = and/or=20 none has occurred.=20 =20 Tariff-Change-Usage can be one of the following.=20 =20 UNIT_BEFORE_TARIFF_CHANGE 0=20 =20 When present in the Granted-Service-Units AVP, this value indicates=20 the amount of the units allocated for use before a tariff change=20 occurs.=20 When present in the Reported-Service-Units AVP, this value = indicates=20 the amount of resource units used before a tariff change had = occurred.=20 =20 UNIT_AFTER_TARIFF_CHANGE 1=20 =20 When present in the Granted-Service-Units AVP, this value indicates=20 the amount of the units allocated for use after a tariff change=20 occurs.=20 When present in the Reported-Service-Units AVP, this value = indicates=20 the amount of resource units used after tariff change had occurred.=20 =20 - end of changes=20 Best Regards,=20 Chris Richards.=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=20 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=20 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=20 (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.=20 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=20 *************************************************************************= *****=20 This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. ------_=_NextPart_001_01C3E9AC.9130B356 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
   [CR] That's OK for voice traffic. I = guess we need=20 the
   input from = some of some=20 data OCS vendors. Interestingly,
   3GPP went with the new proposal for IMS in Release = 5=20 -
   this was = a Diameter=20 protocol.
 
3GPP uses Diameter = DCC in the=20 context of IMS online charging (TS 32.225), the = mechanism
of allocating = quotas before and=20 after was proposed there for time based services sometime ago.=20
But for time=20 based = services there=20 is no need for any interaction between server and client as =
also stated by=20 John = P. =20 Interestingly, there are couple of pending Change Requests against the=20
concerned = IMS Release 5 TS to remove the = mechanism, = so=20 apparently not all in the 3GPP community
are of the same = opinion.=20 So = the statement=20 that "3GPP went  with the new proposal etc." is = rather
inaccurate.
 
However, I think = the AAA=20 mailing list is not the appropriate place to discuss 3GPP=20 specific
issues.
 
Thank = you
Marco
 
 
 -----Original = Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext=20 Christopher Richards
Sent: 02 February, 2004 = 18:07
To:=20 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu';=20 'John.Prudhoe@vodafone.com'; Loughney John=20 (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff = Change=20 mechanism

Hi Leena,

Thanks for the reply. I have added some comments = below.=20

Best Regards,
Chris.

Shasta Wireless Development
Nortel=20 Networks

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


-----Original Message-----
From: Leena=20 Mattila (TU/LMF) [mailto:leena.mattila@ericsson.= com]=20
Sent: Monday, February 02, 2004 6:10 = AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com';=20 'john.loughney@nokia.com'
Subject: RE: = [AAA-WG]: DCC:=20 Issue: Tariff Change mechanism


Hi Chris,

the way it is proposed in the draft-02 is similar as = currently=20 implemented in the IN/CAMEL systems and we are not aware of any = problem=20 associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I = guess we need=20 the
   input from some of some = data OCS=20 vendors. Interestingly,
   3GPP = went with=20 the new proposal for IMS in Release 5 -
  =20 this was a Diameter protocol.

Concerning the proposed mechanism it seems the = server would=20 need to allocate credit both before and after the tariff = change.

   [CR] Yes. But this is effectively the = same for=20 the
   existing mechanism. Except = that in=20 the existing mechanism,
   since = only one=20 allocation can actually be given, the OCS
  =20 must make the allocation based upon the worst case scenario =
   and provide quota in small enough amounts so = that the=20 usage
   at a potentially higher = cost can be=20 covered by the users
   account. = In other=20 words the OCS has to make decisions up
  =20 front that it can then only really reconcile after the usage. =

 If the server wants to minimize the likelihood = of higher=20
re-authorization traffic load, it would have = to=20 allocate bigger credit in both categories since it doesn't know = whether more=20 units will be consumed before or after.

   [CR] Not at all. It can make a decision = about how=20 much "after"
   quota to allocate = because it=20 knows how much is available in the
   users=20 account because it has already allocated the "before"
   quota. It now has the power to allocate as much = or as=20 little
   "after" quota as it sees = fit -=20 smaller chunks to avoid credit
  =20 fragmentation - but this is also a function of how long before=20
   a tariff change that the quota = is=20 requested. I.e. 30 seconds
   = before a TC,=20 it can allocate more to the "after" quota. However,
   if the request is being made 30 minutes before a = TC, then=20 it
   would allocate less to the = "after"=20 quota.

If the server wants to minimize the credit = fragmentation would=20 need to allocate smaller credit, at the expences of higher re-autht = traffic=20 load. So, I fully agree with John P. in that the proposed mechanism = defeats=20 both the objectives of trying to reduce credit fragmentation and = trying to=20 minimize the re-auth traffic load.

   [CR] The intention of my proposal was = not to make=20 it optional:
   it was to replace = the=20 existing scheme. I think we all agree
  =20 that 2 parallel mechanisms would be best to avoid. It will =
   make it more difficult for OCS vendors to=20 implement.

John Loughney wrote:
>I = am quite=20 worried about additional optional mechanisms.  Already the=20
>specification is quite complicated and I = worry=20 that additional optional
>mechansisms = will create=20 extremely complicated mechanisms.
>=20
>I favor simplication at this point, so I'd hope = we could=20 discuss the
>options and focus on a = single=20 mechansim.
>
I = agree with=20 this, we shouldn't introduce more optionality. We should support only = one way=20 of doing tariff switch (tsw itself is optional already, optionality = within one=20 option is not desirable).

BR,
Leena

-----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of John.Prudhoe@vodafone.com
Sent: = 30.=20 tammikuuta 2004 19:08
To: Christopher = Richards=20
Cc: 'aaa-wg@merit.edu'; = owner-aaa-wg@merit.edu=20
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change=20 mechanism

Hi Chris,

I've no objection myself in principle to your = mechanism of=20 allocating quotas together for both units before and units after the = tariff=20 change.  As long as it is all optional.


The question is: how likely is the client to run out = of the=20 before units before the time of the tariff change.  This would = trigger an=20 re-authorisation even though the units after are unused.  To = avoid this,=20 the server would have to allocated a higher quota in that = category. =20 Alternatively, if the user did little before the tariff change and = lots after=20 they would be likely to consume the units after much more quickly. =

 
Therefore, I = suspect that this=20 mechanism won't reduce the volume of authorisation traffic in practice = unless=20 larger quotas are allocated, which I think defeats your objective of = trying to=20 reduce credit fragmentation.

Regards,

John.





"Christopher Richards" = <crich@nortelnetworks.com>=20
30/01/2004 16:27
       
       =20 To:        = "'John.Prudhoe@vodafone.com'"=20 <John.Prudhoe@vodafone.com>
       =20 cc:        "'aaa-wg@merit.edu'"=20 <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
       =20 Subject:        RE: [AAA-WG]: DCC: = Issue:=20 Tariff Change mechanism.



Thanks for the reply John,
 =20
Since there are implementations that can = generate=20 straddling usage counts today, I don't have a problem leaving this = value in=20 the Tariff-Change-Usage AVP.

However, I still think that the current proposed = mechanism in=20 the draft should address it's shortcomings as I described in the Issue = email I=20 sent. Will the change proposal be accepted as an issue to discuss? If = so,=20 should I resubmit the issue with the change described above? =

 
Best = Regards,
Chris.
-----Original = Message-----=20
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.co= m]=20
Sent: Friday, January 30, 2004 10:18 = AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu =
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change = mechanism.=20


Hi Chris,

The option to specify units straddlling a tariff = time change=20 was suggested by us as we have an implemented system that behaves like = this.=20

There is a fundamental difference between tariffs = changing for=20 a service that is consumed at a regular rate (i.e. time based such as=20 circuit-switched calls) and one that is consumed at an irregular rate = (such as=20 GPRS or 3G data services).

For time-based services there is no need to report = the=20 Tariff-Time-Change AVP to the client.  It doesn't even need to = know that=20 the tariff has changed.  When the server knows that there is = tariff=20 change due it can take this into account when rating the granted = units. =20 There is no need for any additional Diameter traffic for time-based = services=20 when there is a tariff change.

Regards,

John.




"Christopher Richards" = <crich@nortelnetworks.com>=20
Sent by: owner-aaa-wg@merit.edu =
30/01/2004 = 16:09        =20
      =20 To:        "'aaa-wg@merit.edu'"=20 <aaa-wg@merit.edu>
      =20 cc:        
      =20 Subject:        [AAA-WG]: DCC: = Issue:=20 Tariff Change mechanism.




All,
Please find enclosed = issue=20 regarding the current tariff change mechanism specified in the DCC = draft.=20
Best Regards,
Chris Richards.=20
Description of issue: Tariff Change =
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:=20
Document: draft-ietf-aaa-diameter-cc-02.txt=20
Comment type: T
Priority: ['S'=20 Must fix | '1' Should fix | '2' May fix ]
Sections:=20 8.16, 8.41 and 8.42
Rationale/Explanation of = issues:=20
The current draft implements a tariff time = change=20 capability by allowing the Used-Service-Units to report back the used=20 resources before and after a tariff change. However, the resources = supplied by=20 the DCC server are given in a single Granted-Service-Units AVP. = However, using=20 this mechanism has a number of drawbacks and practical issues: =

1. It is complex for the DCC server since it must = reserve=20 credit on the basis of which will be more expensive before or after=20 consumption (As acknowledged in section 5 of the draft). This is = particularly=20 inconvenient when the model changes e.g. some bundled minutes after = the=20 duration, or rates change to a minimum of x or any other model. As a = result,=20 either the server will have to allocate smaller quotas resulting in = increased=20 quota activity or it will have to reserve a larger amount of credit=20 exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is = not used=20 when the resource unit is time. However, in order to perform tariff = time=20 changes, the client will have to re-authorise all quotas for all = sessions that=20 react to the same tariff time change - this will lead to a flood of = messaging=20 and processing on the client and server which will result in delayed = responses=20 and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), = a=20 different mechanism has been introduced for the Diameter IMS charging=20 application which avoids the problems stated above - there are no = longer used=20 resources that straddle a tariff change thus removing this = indeterminate=20 charging scenario. It would seem highly desirable to align with this = mechanism=20 so all applications can benefit.

Requested changes:
- = Section 5, last=20 paragraph:
FROM:
 The=20 Diameter credit-control server and client may optionally support a=20
 tariff change mechanism. The Diameter=20 credit-control server may
 include a=20 Tariff-Time-Change AVP in the answer message. Note that the =
 granted units should be allocated based on the = worst-case=20 scenario in
 case of forthcoming tariff = change,=20 so that the overall reported used
 units would=20 never exceed the credit reservation. 
 When=20 the Diameter credit-control client reports the used units and a=20
 tariff change has occurred during the = reporting=20 period then the
 Diameter = credit-control client=20 SHOULD itemize the units used before
 and after=20 the tariff change. In case some units straddled the tariff =
 change, the credit-control client SHOULD itemize those = units as=20 well.
TO:
 The Diameter=20 credit-control server and client may optionally support a =
 tariff change mechanism. The Diameter credit-control = server may=20
 include both the Tariff-Time-Change = and=20 Tariff-Change-Usage AVPs in
 two quota=20 allocations in the answer message. One of the granted units is=20
 allocated to be used before the = potential tariff=20 change while the
 second granted units = are used=20 after a tariff change. Both granted unit
 quotas=20 MUST contain the same Service-Identifier and Rating-Group values.=20
 This dual quota mechanism ensures that = the=20 overall reported used
 units would = never exceed=20 the credit reservation. 
 The = Diameter=20 credit-control client reports both the used units before =
 and after the tariff change.
- Section=20 8.16, new paragraphs:
NEW:
 The Tariff-Change-Usage AVP is included when the=20 Tariff-Time-Change AVP is
 present. It = instructs=20 the client when the resources in the Granted-Service-
 Unit AVP should be used.
  =20 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are = present,=20
 the server MUST include two separate=20 Granted-Service-Unit AVPs (for the
 same=20 Service-Identifier and/or Rating-Group when either the Service-=20
 Identifier or Rating-Group AVP is = included). One=20 of the Granted-Service-
 Units = resources are used=20 before a tariff change occurs, while the other
 is to be used after the tariff change has occurred.=20
- Section 8.16, last paragraph: =
FROM:
 The = Granted-Service-Unit AVP has=20 the following ABNF grammar:  
          =20
      =20 Granted-Service-Unit ::=3D < AVP Header: 431 >
          &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 ]
TO:
 The=20 Granted-Service-Unit AVP has the following ABNF grammar:  =20
          =20
      =20 Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nbs= p;            = ;        =20 [ Tariff-Time-Change ]  
          &nbs= p;            = ;        =20 [Tariff-Change-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 ]
- Section 8.41, first and = second=20 paragraphs:
FROM:
 The=20 Tariff-Time-Change AVP (AVP code 451) is of type Time, and =
 includes the time in seconds since January 1, 1900 = 00:00 UTC when=20 the
 tariff of the service will be = changed.=20
 
 The = tariff change=20 mechanism is optional for client and server and it
 is not used for unit type time, since the server has = full control=20 of
 the time. 
 
TO:
 The=20 Tariff-Time-Change AVP (AVP code 451) is of type Time, and =
 includes the time in seconds since January 1, 1900 = 00:00 UTC when=20 the
 tariff of the service will be = changed.=20
   The tariff change mechanism is = optionally=20 enabled by the server for a
 Diameter = credit=20 control session or sub-session.
- Section = 8.42:=20
FROM:
 The=20 Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and=20
 defines whether units are used before, = after or=20 straddled tariff
 change when a tariff = change has=20 occurred during the reporting period.
 Omission=20 of this AVP means that no tariff change has been occurred. =
 
 Tariff-Change-Usage = can be one of=20 the following.
 
 =20 = UNIT_BEFORE_TARIFF_CHANGE        =             &= nbsp;           &n= bsp;=20 0
 
   The used=20 units contains the amount of the units before tariff
   change, that is units measured from the point = when the=20 previous
   measurement ended to = the point=20 when tariff change occurred.
  =
 =20 = UNIT_AFTER_TARIFF_CHANGE        &= nbsp;           &n= bsp;           &nb= sp; =20 1

   The used units contains the amount of = the units=20 after tariff change
   has been = occurred.=20
 
 =20 = UNIT_INDETERMINATE         &= nbsp;           &n= bsp;           &nb= sp;      =20 2
 
   The used=20 units contains the amount of units that straddle the
   tariff change (e.g. the metering process reports = to the=20 credit-
   control client in = blocks of n=20 octets and one block straddled the
   tariff=20 change).
TO:    =
 The Tariff-Change-Usage AVP (AVP code 452) is of type = Enumerated.=20
   When present in the = Granted-Service-Units=20 AVP, this AVP defines whether
 units = are=20 allocated to be used before or after a tariff change event. =
   When present in the Used-Service-Units AVP, this = AVP=20 identified what
 resources where used = before or=20 after a tariff change during the reporting
 period.
   Omission = of this AVP=20 means that no tariff change is to be reported and/or
 none has occurred.
 =20
 Tariff-Change-Usage can be one of the = following.=20
 
 =20 = UNIT_BEFORE_TARIFF_CHANGE        =             &= nbsp;           &n= bsp;=20 0
 
   When=20 present in the Granted-Service-Units AVP, this value indicates=20
   the amount of the units = allocated for use=20 before a tariff change
   occurs.=20
     When present in the = Reported-Service-Units AVP, this value indicates
   the amount of resource units used before a = tariff change=20 had occurred.
 
 =20 = UNIT_AFTER_TARIFF_CHANGE        &= nbsp;           &n= bsp;           &nb= sp; =20 1
 
   When=20 present in the Granted-Service-Units AVP, this value indicates=20
   the amount of the units = allocated for use=20 after a tariff change
   occurs.=20
     When present in the = Reported-Service-Units AVP, this value indicates
   the amount of resource units used after tariff = change had=20 occurred.
    =
-=20 end of changes
Best Regards, =
Chris Richards.


****************************************************************= **************=20

The content of this e-mail may be privileged and/or=20 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=20 such
case, you should destroy this message = and kindly=20 notify the
sender and postmaster@vodafone.ie = by reply=20 email. Please
note that in such = circumstances any=20 review, dissemination,
disclosure, = alteration,=20 printing, copying or further transmission of this e-mail and/or any = file=20 transmitted with it is prohibited

and may be unlawful. Please advise us immediately if = you or=20 your employer do not consent to Internet email for messages =

of this kind. The opinions, conclusions and other = information=20
in this message are of the author and shall = be=20 understood as
neither given nor endorsed by = Vodafone=20 Ireland Limited
unless it is otherwise = indicated by an=20 authorised representative
independent of = this message.=20 Internet e-mail is
transmitted over the = public=20 internet over which Vodafone
Ireland Limited = has no=20 control. As such, there is no guarantee that
(i) this=20 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=20
(iv) the contents of this e-mail are = unaltered from=20 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=20 responsibility of
the recipient to ensure = that the=20 message (and attachments)
are safe and = authorised for=20 use in their environment.
Vodafone Ireland = Ltd=20 Directors: Peter Bamford Chairman (UK),
Pauline Best=20 (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy,=20 Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in = Ireland at=20 MountainView, Leopardstown, Dublin 18.

Number 326967 VAT Reg No. IE6346967G

****************************************************************= **************=20

This communication is confidential and intended = solely for the=20 addressee(s). Any unauthorized review, use, disclosure or distribution = is=20 prohibited. If you believe this message has been sent to you in error, = please=20 notify the sender by replying to this transmission and delete the = message=20 without disclosing it. Thank you.

E-mail including attachments is susceptible to data=20 corruption, interruption, unauthorized amendment, tampering and = viruses, and=20 we only send and receive e-mails on the basis that we are not liable = for any=20 such corruption, interception, amendment, tampering or viruses or any=20 consequences thereof.

------_=_NextPart_001_01C3E9AC.9130B356-- From owner-aaa-wg@merit.edu Mon Feb 2 12:11:37 2004 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 MAA23042 for ; Mon, 2 Feb 2004 12:11:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E12291235; Mon, 2 Feb 2004 12:11:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FC3491236; Mon, 2 Feb 2004 12:11: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 58B6B91235 for ; Mon, 2 Feb 2004 12:11:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F7995DE46; Mon, 2 Feb 2004 12:11:20 -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 8037C5DE5F for ; Mon, 2 Feb 2004 12:11:19 -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 i12HBE323936; Mon, 2 Feb 2004 11:11:14 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 11:11:14 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8F1B@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 11:11:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9AF.8B449B86" 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_01C3E9AF.8B449B86 Content-Type: text/plain Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com ] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu ]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com ] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. **************************************************************************** ** 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 **************************************************************************** ** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3E9AF.8B449B86 Content-Type: text/html Message
Hi Marco, All,
 
Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.
 
I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?

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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I guess we need the
   input from some of some data OCS vendors. Interestingly,
   3GPP went with the new proposal for IMS in Release 5 -
   this was a Diameter protocol.
 
3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.
 
However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.
 
Thank you
Marco
 
 
 -----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,

Thanks for the reply. I have added some comments below.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
   input from some of some data OCS vendors. Interestingly,
   3GPP went with the new proposal for IMS in Release 5 -
   this was a Diameter protocol.

Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
   existing mechanism. Except that in the existing mechanism,
   since only one allocation can actually be given, the OCS
   must make the allocation based upon the worst case scenario
   and provide quota in small enough amounts so that the usage
   at a potentially higher cost can be covered by the users
   account. In other words the OCS has to make decisions up
   front that it can then only really reconcile after the usage.

 If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
   quota to allocate because it knows how much is available in the
   users account because it has already allocated the "before"
   quota. It now has the power to allocate as much or as little
   "after" quota as it sees fit - smaller chunks to avoid credit
   fragmentation - but this is also a function of how long before
   a tariff change that the quota is requested. I.e. 30 seconds
   before a TC, it can allocate more to the "after" quota. However,
   if the request is being made 30 minutes before a TC, then it
   would allocate less to the "after" quota.

If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
   it was to replace the existing scheme. I think we all agree
   that 2 parallel mechanisms would be best to avoid. It will
   make it more difficult for OCS vendors to implement.

John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.


The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,

John.





"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.



Thanks for the reply John,
 
Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.


Hi Chris,

The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
       To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
       cc:        
       Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.




All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include a Tariff-Time-Change AVP in the answer message. Note that the
 granted units should be allocated based on the worst-case scenario in
 case of forthcoming tariff change, so that the overall reported used
 units would never exceed the credit reservation. 
 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. In case some units straddled the tariff
 change, the credit-control client SHOULD itemize those units as well.
TO:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. One of the granted units is
 allocated to be used before the potential tariff change while the
 second granted units are used after a tariff change. Both granted unit
 quotas MUST contain the same Service-Identifier and Rating-Group values.
 This dual quota mechanism ensures that the overall reported used
 units would never exceed the credit reservation. 
 The Diameter credit-control client reports both the used units before
 and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
 present. It instructs the client when the resources in the Granted-Service-
 Unit AVP should be used.
   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
 the server MUST include two separate Granted-Service-Unit AVPs (for the
 same Service-Identifier and/or Rating-Group when either the Service-
 Identifier or Rating-Group AVP is included). One of the Granted-Service-
 Units resources are used before a tariff change occurs, while the other
 is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
          
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]
TO:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
          
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [Tariff-Change-Usage ]
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
 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. 
 
TO:
 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
 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 optionally enabled by the server for a
 Diameter credit control session or sub-session.
- Section 8.42:
FROM:
 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
 defines whether units are used before, after or straddled tariff
 change when a tariff change has occurred during the reporting period.
 Omission of this AVP means that no tariff change has been occurred.
 
 Tariff-Change-Usage can be one of the following.
 
  UNIT_BEFORE_TARIFF_CHANGE                                  0
 
   The used units contains the amount of the units before 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.
 
  UNIT_INDETERMINATE                                         2
 
   The used units contains the amount of units that straddle the
   tariff change (e.g. the metering process reports to the credit-
   control client in blocks of n octets and one block straddled the
   tariff change).
TO:   
 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
   When present in the Granted-Service-Units AVP, this AVP defines whether
 units are allocated to be used before or after a tariff change event.
   When present in the Used-Service-Units AVP, this AVP identified what
 resources where used before or after a tariff change during the reporting
 period.
   Omission of this AVP means that no tariff change is to be reported and/or
 none has occurred.
 
 Tariff-Change-Usage can be one of the following.
 
  UNIT_BEFORE_TARIFF_CHANGE                                  0
 
   When present in the Granted-Service-Units AVP, this value indicates
   the amount of the units allocated for use before a tariff change
   occurs.
     When present in the Reported-Service-Units AVP, this value indicates
   the amount of resource units used before a tariff change had occurred.
 
  UNIT_AFTER_TARIFF_CHANGE                                   1
 
   When present in the Granted-Service-Units AVP, this value indicates
   the amount of the units allocated for use after a tariff change
   occurs.
     When present in the Reported-Service-Units AVP, this value indicates
   the amount of resource units used after tariff change had occurred.
   
- end of changes
Best Regards,
Chris Richards.


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

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

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

------_=_NextPart_001_01C3E9AF.8B449B86-- From owner-aaa-wg@merit.edu Mon Feb 2 12:20:15 2004 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 MAA23460 for ; Mon, 2 Feb 2004 12:20:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA05491236; Mon, 2 Feb 2004 12:19:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FFA491237; Mon, 2 Feb 2004 12:19:58 -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 49A1091236 for ; Mon, 2 Feb 2004 12:19:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6CB845DDDF; Mon, 2 Feb 2004 12:19:56 -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 7D13E5DDEB for ; Mon, 2 Feb 2004 12:19:55 -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 i12HJqM28804 for ; Mon, 2 Feb 2004 19:19:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Feb 2004 19:19:49 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 19:19:49 +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]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 19:19:49 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C836D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPpr5VG+YnUuHZdTqCcoZtJKVEFjwAAGQ4A From: To: Cc: , , X-OriginalArrivalTime: 02 Feb 2004 17:19:49.0809 (UTC) FILETIME=[C3635A10:01C3E9B0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, Chris Richards wrote: >I'm interested in your statement that time based quotas have no = interaction between the=20 >client/server: >But for time based services there is no need for any interaction = between server and client >as also stated by John P . >Could you explain your reasoning? The reasoning was clearly explained already. Here is an extract of the = mail with the explanation, I'm of the same opinion. Regards Marco John Prudhoe wrote: >For time-based services there is no need to report the = Tariff-Time-Change AVP to the=20 >client. It doesn't even need to know that the tariff has changed. = When the server knows=20 >that there is tariff change due it can take this into account when = rating the granted=20 >units. There is no need for any additional Diameter traffic for = time-based services when=20 >there is a tariff change.=20 From owner-aaa-wg@merit.edu Mon Feb 2 12:24:24 2004 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 MAA23598 for ; Mon, 2 Feb 2004 12:24:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 672209123A; Mon, 2 Feb 2004 12:24:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1886A91239; Mon, 2 Feb 2004 12:24:07 -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 423B591237 for ; Mon, 2 Feb 2004 12:24:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 296C45DE72; Mon, 2 Feb 2004 12:24:05 -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 D580A5DE45 for ; Mon, 2 Feb 2004 12:23:57 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Mon, 2 Feb 2004 17:28:09 +0000 To: "Christopher Richards" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, John.Prudhoe@vodafone.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Mon, 2 Feb 2004 17:23:46 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 02/02/2004 05:23:49 PM, Serialize complete at 02/02/2004 05:23:49 PM Content-Type: multipart/alternative; boundary="=_alternative 005F8CF980256E2E_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005F8CF980256E2E_= Content-Type: text/plain; charset="us-ascii" Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. ****************************************************************************** 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 ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --=_alternative 005F8CF980256E2E_= Content-Type: text/html; charset="us-ascii"
Hi Chris,

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards.

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change.

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.





"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 17:11

       
        To:        "'marco.stura@nokia.com'" <marco.stura@nokia.com>
        cc:        aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism



Hi Marco, All,
 
Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.
 
I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?

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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
   [CR] That's OK for voice traffic. I guess we need the
  input from some of some data OCS vendors. Interestingly,
  3GPP went with the new proposal for IMS in Release 5 -
  this was a Diameter protocol.
 
3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.
 
However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.
 
Thank you
Marco
 
 
 -----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,

Thanks for the reply. I have added some comments below.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
  input from some of some data OCS vendors. Interestingly,
  3GPP went with the new proposal for IMS in Release 5 -
  this was a Diameter protocol.

Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
  existing mechanism. Except that in the existing mechanism,
  since only one allocation can actually be given, the OCS
  must make the allocation based upon the worst case scenario
  and provide quota in small enough amounts so that the usage
  at a potentially higher cost can be covered by the users
  account. In other words the OCS has to make decisions up
  front that it can then only really reconcile after the usage.

 If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
  quota to allocate because it knows how much is available in the
  users account because it has already allocated the "before"
  quota. It now has the power to allocate as much or as little
  "after" quota as it sees fit - smaller chunks to avoid credit
  fragmentation - but this is also a function of how long before
  a tariff change that the quota is requested. I.e. 30 seconds
  before a TC, it can allocate more to the "after" quota. However,
  if the request is being made 30 minutes before a TC, then it
  would allocate less to the "after" quota.

If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
  it was to replace the existing scheme. I think we all agree
  that 2 parallel mechanisms would be best to avoid. It will
  make it more difficult for OCS vendors to implement.

John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
       
       To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
       cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
       Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.


Thanks for the reply John,
 
Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris,

The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,

John.



"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
      To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
      cc:        
      Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.



All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.
TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.
  When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
      Granted-Service-Unit ::= < AVP Header: 431 >
                               [ Tariff-Time-Change ]  
                               [ CC-Time ]
                               [ CC-Money ]  
                               [ CC-Total-Octets ]
                               [ CC-Input-Octets ]
                               [ CC-Output-Octets ]
                               [ CC-Service-Specific-Units ]
                              *[ Service-Identifier ]
                               [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
      Granted-Service-Unit ::= < AVP Header: 431 >
                               [ Tariff-Time-Change ]  
                               [Tariff-Change-Usage ]
                               [ CC-Time ]
                               [ CC-Money ]  
                               [ CC-Total-Octets ]
                               [ CC-Input-Octets ]
                               [ CC-Output-Octets ]
                               [ CC-Service-Specific-Units ]
                              *[ Service-Identifier ]
                               [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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.  
 
TO:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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 optionally enabled by the server for a
Diameter credit control session or sub-session.
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
defines whether units are used before, after or straddled tariff
change when a tariff change has occurred during the reporting period.
Omission of this AVP means that no tariff change has been occurred.
 
Tariff-Change-Usage can be one of the following.
 
 UNIT_BEFORE_TARIFF_CHANGE                                  0
 
  The used units contains the amount of the units before 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.
 
 UNIT_INDETERMINATE                                         2
 
  The used units contains the amount of units that straddle the
  tariff change (e.g. the metering process reports to the credit-
  control client in blocks of n octets and one block straddled the
  tariff change).
TO:    
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
  When present in the Granted-Service-Units AVP, this AVP defines whether
units are allocated to be used before or after a tariff change event.
  When present in the Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during the reporting
period.
  Omission of this AVP means that no tariff change is to be reported and/or
none has occurred.
 
Tariff-Change-Usage can be one of the following.
 
 UNIT_BEFORE_TARIFF_CHANGE                                  0
 
  When present in the Granted-Service-Units AVP, this value indicates
  the amount of the units allocated for use before a tariff change
  occurs.
    When present in the Reported-Service-Units AVP, this value indicates
  the amount of resource units used before a tariff change had occurred.
 
 UNIT_AFTER_TARIFF_CHANGE                                   1
 
  When present in the Granted-Service-Units AVP, this value indicates
  the amount of the units allocated for use after a tariff change
  occurs.
    When present in the Reported-Service-Units AVP, this value indicates
  the amount of resource units used after tariff change had occurred.
   
- end of changes
Best Regards,
Chris Richards.

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

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

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--=_alternative 005F8CF980256E2E_=-- From owner-aaa-wg@merit.edu Mon Feb 2 13:03:06 2004 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 NAA26542 for ; Mon, 2 Feb 2004 13:03:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E0DF91238; Mon, 2 Feb 2004 13:02:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7E9E91239; Mon, 2 Feb 2004 13:02:54 -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 C0E3F91238 for ; Mon, 2 Feb 2004 13:02:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id A127D5DDAC; Mon, 2 Feb 2004 13:02:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 086695DDA4 for ; Mon, 2 Feb 2004 13:02:41 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12I2V628362; Mon, 2 Feb 2004 18:02:31 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 18:02:32 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'harri.hakala@ericsson.com'" , "'leena.mattila@ericsson.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Benni.Alexander@nokia.com'" , "'patrik.teppo@ericsson.com'" Subject: RE: [AAA-WG]: Issue: DCC: Independent handling of services within a session Date: Mon, 2 Feb 2004 18:02:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9B6.B790DDB0" 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_01C3E9B6.B790DDB0 Content-Type: text/plain Hi Marco, Thanks for your response - comments/answers below... I guess we can work on an updated proposal offline based on your comments below. Regards...Mark > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: 30 January 2004 15:51 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: aaa-wg@merit.edu; harri.hakala@ericsson.com; > leena.mattila@ericsson.com; john.loughney@nokia.com; > juha-pekka.koskinen@nokia.com; Benni.Alexander@nokia.com; > patrik.teppo@ericsson.com > Subject: RE: [AAA-WG]: Issue: DCC: Independent handling of > services within a session > > > Hi Mark, > > I'm glad to see your proposal, I finally think to understand > what you exactly want. You mainly want to manage each > service/rating-group (re-)authorization in a way > independently and you want to be able to add/remove services > at any time, right? MW: Yes, and to decouple from the pooling concept, so that pooling can still take place across independently managed services/rating-groups in order to avoid fragmentation. > > One minor detail.....such a structured proposal would have > avoided months of loop discussion. > > I think in principle we are fine with your proposal. We would > however prefere a more clear functional split in the protocol > for this feature, I mean more clear separation of say basic > features and complex > functionalities. For that reason we may perhaps consider to define a > new grouped AVP that would include G-S-U, R-S-U, U-S-U, F-U-I > etc. rather > than lifting everything at G-S-U level. But, let agree the > basic principles > first and then discuss this other details. > > More comments in line. > > Regards > Marco > > >Handling of services or rating groups within a single session or > >sub-session can only be > >done 'en-bloc' according to the grouping of those services > of rating groups into (sub-) > >sessions by the client. In particular: > >- all services or rating groups must be re-authorised at the > same time > >- adding an additional service or rating group requires > re-authorisation of all other > >services/rating groups in the (sub-)session > > MST: This is not exactly true, in particular it is true > relative to the flow example I provided in our discussion but > is not an absolute statement. Since the client knows how much > of the credit reservation it has been used for service 1 > (C1/Q1), it can authorize only the new service request e.g. > service 2 (CCR (Service 2)) if so wanted and safe enough > (e.g. if the total amount of credit used by the acive > service(s) is below some configurable threshold). So, all the > listed disadvantages and 'en-bloc' consideration vanishes. > The disatvantage of not enabling adding/removing > "reservations" in the pool stays. > MW: Ok, I understand. We can add/remove services from the 'pool' but the amount of credit in the pool (the reservation) cannot be changed. > >- the construction in which multiple quotas representing the *same* > >monetary allocation are > >passed down from client to server is counter-intuitive and > liable to major mis- > >interpretation > > MSt: I may argue the same for your proposal, but as long as > we clearly define the semantic there shouldn't be any > problems with either proposals. > MW: Well, I guess there is a sense in which whatever you are most familiar with is 'intuitive' and the opposite is 'counter-intuitive'. But really, every credit control system I have come across has a concept of delegating the authorisation for a certain amount of a particular service. The idea that the authorisation for a particular volume is not absolute, but qualified by some other services does seem a little strange - 'baroque' was the term which came up internally ;-) > >In order to handle quotas within a pool separately, it is > necessary to > >be more explicit > >within the protocol about the relationship between quotas. > This is presently communicated > >implicitly based on the assumption that all quotas are > derived from the same credit > >reservation in the server. > >For each service/rating group and unit, we provide a > 'Multiplier' value which is used to > >express the ratios between services in terms of resource usage. > >If service 1 has multiplier M1 and service 2 has multiplier > M2 then resources from service >1 can be converted to those > of service 2 by multiplying by M1/M2. > > MSt: If service 1 cost $1/MB, service 2 cost $0.5/MB and > service 3 cost $0.1/MB, the multiplier indicates that 10MB of > service 1 correspond to 20MB of service 2 and 100MB of > service 3, that 20MB of service 2 correspond to 10MB of > service 1 and 100MB of service 2 etc. right? In other word, > the multiplier is the rating value associated to the > service/rating-group. In the above example M1=1, M2=0.5 and > M3=0.1. So why don't you say this more explicitly? > MW: M1=10, M2=5 and M3=1 would do just as well. We have found a lot of sensitivity about doing rating in the client. Of course that is not what is proposed here - the server does the rating and communicates the *result* to the client. But still, that is the reason for avoiding terminology such as 'rating value' for things handled at the client. We can work offline on clearer wording. > >The formula for determining the exhaustion of the credit for a given > >pool of quotas at the > >client is modified as follows: the credit pool is exhausted when > > C1*M1 + C2*M2 + ... + Cn*Mn >= M > >Where M is the total credit for the credit-pool. M is > initially calculated from the granted > >quotas in the pool as follows: > > M = Q1*M1 + Q2*M2 + ... + Qn*Mn > > MSt: This mechanism seems to imply that one reservation is > kept for each of the services/rating-groups because you sum > up all the active credit reservations (i.e. Q1*M1=$ reserved > for service 1, Q2*M2=$ reserved for service 2 etc.). This > equation won't be valid if Q1, Q2,..., Qn were derived from > the same credit reservation. In principle I'm fine with this > even though we may end up in a huge amount of credit > reservations that the server need to handle. > MW: Right - the server calculates how much it would reserve for each service separately and makes all of these reservations against the account. Now, whether the server remembers how much was associated with each service, or whether it just remembers the total is probably internal to the server. > The equation C1*M1+C2*M2+...+Cn*Mn >= M allows each of the > services to draw resources from any of the reservations so > long as the total amount of reserved credit is not exceeded. > Then I have a question. Suppose the server reserved $2 for > service 1, $5 for service 2 and $2 for service 3. Service 1 > consumed $6, Service 2 consumed $1 and Service 3 consumed > $0.5. The total amount of used credit is not exceeding M > (that is 9 in this case) and e.g Validity-time for Q1 expires > then CCR reporting the corresponding amount of $6 is sent to > the server. Would the server then commit $2 from reservation > 1 and $4 from reservation 2 and make two new reservation, one > of $5 as before (for service 2) and one to re-authorize > service 1 or...? MW: I am not sure we need to specify the internal behaviour of the server so long as the protocol is well-defined. It's clear that at the client, the value of M is reduced by 6 when it indicates the $6 for Service 1 to the server. At the server, the total credit reserved is reduced by $6 and a real $6 deducted from the account. Then the server decides what new reservation, if any, to make. Whavever the client gets back in terms of new credit for Service 1 is added to M (times the multiplier). > > >Additional considerations: > >This proposal raised some additional considerations which > require discussion. 1) Since we > >propose that quotas are handled independently, it MAY be > necessary to associate the > >DIAMETER CC state machine with each *quota* rather than with > a (sub-)session. Equivalently, > >the CCR/CCA messages could be extended to handle > requests/answers for multiple sub-sessions > >within a single message. Due to the need for further > discussion, the detailed changes for > >this are not included below yet. > > MSt: The DCC state machine described in the draft it is > mandatory and common to all the DCC client. The state machine > descibes the DCC (sub-)session and controls the messages sent > in it, according to the Diameter concept of session. Since > this feature is optional I don't want to see modification to > the state machine because of it. Perhaps some text as follow > could be added e.g. to section 5. > > " How the independent quota objects are handled in > conjunction with the state machine defined in section 7 is > regarded as an implementation issue. Implementations of > DIAMETER credit control client and server MUST, however, > ensure a failure handling behavior for each of the quota > objects fully consistent with the section 5.6 of this > specification and MUST enable for credit (re-)authorization > of a service/rating-group while a (re-)authorization for one > or more other services/rating-groups is ongoing. To achieve > this it may be necessary to instantiate one DCC state machine > for each of the quota objects active within a (sub-)session." > > ...or something to that effect. > MW: Ok, well I included that text based on the list discussion which seemed to suggest that it would not be possible to handle quotas separately without associating the state machine with the quotas. So perhaps this is something you & Harri could discuss. As long as it is well-defined and works I don't have a strong opinion about the state machine stuff. > >2) It MAY be necessary to perform actions on a credit pool > as a whole > >(for example, server- initiated re-auth, setting of a > Validity-Time). > >In this case a Granted-Service-Units-Pool AVP could be > defined within > >the CCA message which supports such actions. This is not shown below > >either. > > Yes, we have to define how to do this. For server initiated > re-authorization one possibility could be to add the > Granted-Service-Units-Pool, the service-identifier and the > rating-group AVPs to the RAR message. > MW: Ok, sounds good. > >Detailed changes: > >- Section 5, fifth paragraph, amend as follows: > FROM: > When multiple services are used within one user session and each > service or group of services are subject to different > cost, making use > of credit control sub-sessions will result in increased > signaling load > and resources usage in both the credit control client and > the credit > control server. For instance, during one network access > session the > end user may use several http-services subject to different access > cost. To optimally support these scenarios, the credit control > application enables for multiple services credit control > in a single > credit control session. It is possible to request and allocate > multiple quotas as a credit pool that is shared between multiple > services. The services can be further grouped into rating > groups in > order to achieve even further aggregation of credit > allocation. It is > also possible to request and allocate multiple quotas on a > per service > basis. The mechanism is illustrated in Appendix A (Flow X). > TO: > When multiple services are used within one user session and each > service or group of services are subject to different > cost, making use > of credit control sub-sessions will result in increased > signaling load > and resources usage in both the credit control client and > the credit > control server. For instance, during one network access > session the > end user may use several http-services subject to different access > cost. To optimally support these scenarios, the credit control > application enables for multiple services credit control > in a single > credit control session or sub-session. It is possible to > request and > allocate resource as a credit pool that is shared between multiple > services. The services can be further grouped into rating > groups in > order to achieve even further aggregation of credit > allocation. It is > also possible to request and allocate multiple quotas on a > per service > basis. Where quotas are allocated to a pool, the quotas > remain independent > objects which can be re-authorised independently at any > time. Quotas can > also be given independent validity times and > Final-Unit-Indications. The > mechanism to share units across services and rating groups > is described > further in Section 5.X. > > MSt: I think this is fine. > > > 5.X Sharing of units across services and rating groups > To avoid credit fragmentation and unnecessary load on the > credit control > server, it is possible for service units to be provided > to multiple > services or rating groups as a pool. > This is achieved by providing the service units in the > form of a quota for > a particular service or rating group in the usual way, > but also including > a reference to a credit pool for that unit type. The > reference includes a > multiplier which translates from service units of a > specific type to the > abstract service units in the pool. > > MSt: I think it should be clarified what is this > 'multiplier'. Why don't you refer more explicitely to the > rating value (i.e. if cost $1/MB the multiplier is 1 as far > as I understand). MW: We can work on some text offline - I think you have a correct understanding of the concept. As I mentioned we just wanted to avoid people getting sensitive about 'rating' in the client. > > Where multiple G-S-U-Pool-Reference AVPs with the same > G-S-U-Pool > Identifier are provided within a Granted-Service-Units > AVP then these > MUST have different CC-Unit-Type values and they all draw > on the credit > pool separately. > > MSt: perhaps it would be good to expalin this with an > example, similarly as you did in the introduction. > >(e.g. Time and Volume) then multipliers can be provided for > one or more > >of them. Where two >multipliers are provided (e.g. M1t for > time and M1v > >for volume) then the used resource from >the pool is the sum > C1t*M1t + > >C1v*M1v. > MW: Ok. > 8.16 Granted-Service-Unit AVP > > > The Granted-Service-Unit AVP has the following ABNF grammar: > > Granted-Service-Unit ::= < AVP Header: 431 > > [ Tariff-Time-Change ] > [ CC-Time ] > [ CC-Money ] > [ CC-Total-Octets ] > [ CC-Input-Octets ] > [ CC-Output-Octets ] > [ CC-Service-Specific-Units ] > *[ G-S-U-Pool-Reference ] > *[ Service-Identifier ] > [ Rating-Group ] > [ Validity-Time ] > [ Final-Unit-Indication ] > > MSt: it may be that the server returns a failed Result-Code > in the CCA caused by only one service/rating-group. In that > case we would close the whole (sub-)session even though other > services can continue. Perhaps it is apropriate to also > include the Result-Code in the G-S-U. > MW: Ok, makes sense - or it could be in this intermediate level grouped AVC that you suggested, right ? ------_=_NextPart_001_01C3E9B6.B790DDB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC: Independent handling of services = within a session

Hi Marco,

Thanks for your response - comments/answers = below...

I guess we can work on an updated proposal offline = based on your comments below.

Regards...Mark

> -----Original Message-----
> From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
> Sent: 30 January 2004 15:51
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: aaa-wg@merit.edu; = harri.hakala@ericsson.com;
> leena.mattila@ericsson.com; = john.loughney@nokia.com;
> juha-pekka.koskinen@nokia.com; = Benni.Alexander@nokia.com;
> patrik.teppo@ericsson.com
> Subject: RE: [AAA-WG]: Issue: DCC: Independent = handling of
> services within a session
>
>
> Hi Mark,
>
> I'm glad to see your proposal, I finally think = to understand
> what you exactly want. You mainly want to = manage each
> service/rating-group (re-)authorization in a = way
> independently and you want to be able to = add/remove services
> at any time, right?

MW: Yes, and to decouple from the pooling concept, so = that pooling can still take place across independently managed = services/rating-groups in order to avoid fragmentation.

>
> One minor detail.....such a structured proposal = would have
> avoided months of loop discussion.
>
> I think in principle we are fine with your = proposal. We would
> however prefere a more clear functional split = in the protocol
> for this feature, I mean more clear separation = of say basic
> features and complex
> functionalities. For that reason we may perhaps = consider to define a
> new grouped AVP that would include G-S-U, = R-S-U, U-S-U, F-U-I
> etc. rather
> than lifting everything at G-S-U level. But, = let agree the
> basic principles
> first and then discuss this other = details.
>
> More comments in line.
>
> Regards
> Marco
>
> >Handling of services or rating groups = within a single session or
> >sub-session can only be
> >done 'en-bloc' according to the grouping of = those services
> of rating groups into (sub-)
> >sessions by the client. In = particular:
> >- all services or rating groups must be = re-authorised at the
> same time
> >- adding an additional service or rating = group requires
> re-authorisation of all other
> >services/rating groups in the = (sub-)session
>
> MST: This is not exactly true, in particular it = is true
> relative to the flow example I provided in our = discussion but
> is not an absolute statement. Since the client = knows how much
> of the credit reservation it has been used for = service 1
> (C1/Q1), it can authorize only the new service = request e.g.
> service 2 (CCR (Service 2)) if so wanted and = safe enough
> (e.g. if the total amount of credit used by the = acive
> service(s) is below some configurable = threshold). So, all the
> listed disadvantages and 'en-bloc' = consideration vanishes.
> The disatvantage of not enabling = adding/removing
> "reservations" in the pool = stays.
>

MW: Ok, I understand. We can add/remove services from = the 'pool' but the amount of credit in the pool (the reservation) = cannot be changed.

> >- the construction in which multiple quotas = representing the *same*
> >monetary allocation are
> >passed down from client to server is = counter-intuitive and
> liable to major mis-
> >interpretation
>
> MSt: I may argue the same for your proposal, = but as long as
> we clearly define the semantic there shouldn't = be any
> problems with either proposals.
>

MW: Well, I guess there is a sense in which whatever = you are most familiar with is 'intuitive' and the opposite is = 'counter-intuitive'. But really, every credit control system I have = come across has a concept of delegating the authorisation for a certain = amount of a particular service. The idea that the authorisation for a = particular volume is not absolute, but qualified by some other services = does seem a little strange - 'baroque' was the term which came up = internally ;-)

> >In order to handle quotas within a pool = separately, it is
> necessary to
> >be more explicit
> >within the protocol about the relationship = between quotas.
> This is presently communicated
> >implicitly based on the assumption that all = quotas are
> derived from the same credit
> >reservation in the server.
> >For each service/rating group and unit, we = provide a
> 'Multiplier' value which is used to
> >express the ratios between services in = terms of resource usage.
> >If service 1 has multiplier M1 and service = 2 has multiplier
> M2 then resources from service >1 can be = converted to those
> of service 2 by multiplying by M1/M2.
>
> MSt: If  service 1 cost $1/MB, service 2 = cost $0.5/MB and
> service 3 cost $0.1/MB, the multiplier = indicates that 10MB of
> service 1 correspond to 20MB of service 2 and = 100MB of
> service 3, that 20MB of service 2 correspond to = 10MB of
> service 1 and 100MB of service 2 etc. right? In = other word,
> the multiplier is the rating value associated = to the
> service/rating-group. In the above example = M1=3D1, M2=3D0.5 and
> M3=3D0.1. So why don't you say this more = explicitly?
>

MW: M1=3D10, M2=3D5 and M3=3D1 would do just as well. = We have found a lot of sensitivity about doing rating in the client. Of = course that is not what is proposed here - the server does the rating = and communicates the *result* to the client. But still, that is the = reason for avoiding terminology such as 'rating value' for things = handled at the client. We can work offline on clearer = wording.

> >The formula for determining the exhaustion = of the credit for a given
> >pool of quotas at the
> >client is modified as follows: the credit = pool is exhausted when
> >    C1*M1 + C2*M2 + ... + = Cn*Mn >=3D M
> >Where M is the total credit for the = credit-pool. M is
> initially calculated from the granted
> >quotas in the pool as follows:
> >    M =3D Q1*M1 + Q2*M2 + = ... + Qn*Mn
>
> MSt: This mechanism seems to imply that one = reservation is
> kept for each of the services/rating-groups = because you sum
> up all the active credit reservations (i.e. = Q1*M1=3D$ reserved
> for service 1, Q2*M2=3D$ reserved for service 2 = etc.). This
> equation won't be valid if Q1, Q2,..., Qn were = derived from
> the same credit reservation. In principle I'm = fine with this
> even though we may end up in a huge amount of = credit
> reservations that the server need to = handle.
>

MW: Right - the server calculates how much it would = reserve for each service separately and makes all of these reservations = against the account. Now, whether the server remembers how much was = associated with each service, or whether it just remembers the total is = probably internal to the server.

> The equation C1*M1+C2*M2+...+Cn*Mn >=3D M = allows each of the
> services to draw resources from any of the = reservations so
> long as the total amount of reserved credit is = not exceeded.
> Then I have a question. Suppose the server = reserved $2 for
> service 1, $5 for service 2 and $2 for service = 3. Service 1
> consumed $6, Service 2 consumed $1 and Service = 3 consumed
> $0.5. The total amount of used credit is not = exceeding M
> (that is 9 in this case) and e.g Validity-time = for Q1 expires
> then CCR reporting the corresponding amount of = $6 is sent to
> the server. Would the server then commit $2 = from reservation
> 1 and $4 from reservation 2 and make two new = reservation, one
> of $5 as before (for service 2) and one to = re-authorize
> service 1 or...?

MW: I am not sure we need to specify the internal = behaviour of the server so long as the protocol is well-defined. It's = clear that at the client, the value of M is reduced by 6 when it = indicates the $6 for Service 1 to the server. At the server, the total = credit reserved is reduced by $6 and a real $6 deducted from the = account. Then the server decides what new reservation, if any, to make. = Whavever the client gets back in terms of new credit for Service 1 is = added to M (times the multiplier).

>
> >Additional considerations:
> >This proposal raised some additional = considerations which
> require discussion. 1) Since we
> >propose that quotas are handled = independently, it MAY be
> necessary to associate the
> >DIAMETER CC state machine with each *quota* = rather than with
> a (sub-)session. Equivalently,
> >the CCR/CCA messages could be extended to = handle
> requests/answers for multiple sub-sessions =
> >within a single message. Due to the need = for further
> discussion, the detailed changes for
> >this are not included below yet.
>
> MSt: The DCC state machine described in the = draft it is
> mandatory and common to all the DCC client. The = state machine
> descibes the DCC (sub-)session and controls the = messages sent
> in it, according to the Diameter concept of = session. Since
> this feature is optional I don't want to see = modification to
> the state machine because of it. Perhaps some = text as follow
> could be added e.g. to section 5.
>
> " How the independent quota objects are = handled in
> conjunction with the state machine defined in = section 7 is
> regarded as an implementation issue. = Implementations of
> DIAMETER credit control client and server MUST, = however,
> ensure a failure handling behavior for each of = the quota
> objects fully consistent with the section 5.6 = of this
> specification and MUST enable for credit = (re-)authorization
> of a service/rating-group while a = (re-)authorization for one
> or more other services/rating-groups is = ongoing. To achieve
> this it may be necessary to instantiate one DCC = state machine
> for each of the quota objects active within a = (sub-)session." 
>
> ...or something to that effect.
>

MW: Ok, well I included that text based on the list = discussion which seemed to suggest that it would not be possible to = handle quotas separately without associating the state machine with the = quotas. So perhaps this is something you & Harri could discuss. As = long as it is well-defined and works I don't have a strong opinion = about the state machine stuff.

> >2) It MAY be necessary to perform actions on = a credit pool
> as a whole
> >(for example, server- initiated re-auth, = setting of a
> Validity-Time).
> >In this case a Granted-Service-Units-Pool = AVP could be
> defined within
> >the CCA message which supports such = actions. This is not shown below
> >either.
>
> Yes, we have to define how to do this. For = server initiated
> re-authorization one possibility  could be = to add the
> Granted-Service-Units-Pool, the = service-identifier and the
> rating-group AVPs to the RAR message.
>

MW: Ok, sounds good.
 
> >Detailed changes:
> >- Section 5, fifth paragraph, amend as = follows:
> FROM:
>    When multiple services are = used within one user session and each
>    service or group of services = are subject to different
> cost, making use
>    of credit control = sub-sessions will result in increased
> signaling load
>    and resources usage in both = the credit control client and
> the credit
>    control server. For instance, = during one network access
> session the
>    end user may use several = http-services subject to different access
>    cost. To optimally support = these scenarios, the credit control
>    application enables for = multiple services credit control
> in a single
>    credit control session. It is = possible to request and allocate
>    multiple quotas as a credit = pool that is shared between multiple
>    services. The services can be = further grouped into rating
> groups in
>    order to achieve even further = aggregation of credit
> allocation. It is
>    also possible to request and = allocate multiple quotas on a
> per service
>    basis. The mechanism is = illustrated in Appendix A (Flow X).
> TO:
>    When multiple services are = used within one user session and each
>    service or group of services = are subject to different
> cost, making use
>    of credit control = sub-sessions will result in increased
> signaling load
>    and resources usage in both = the credit control client and
> the credit
>    control server. For instance, = during one network access
> session the
>    end user may use several = http-services subject to different access
>    cost. To optimally support = these scenarios, the credit control
>    application enables for = multiple services credit control
> in a single
>    credit control session or = sub-session. It is possible to
> request and
>    allocate resource as a credit = pool that is shared between multiple
>    services. The services can be = further grouped into rating
> groups in
>    order to achieve even further = aggregation of credit
> allocation. It is
>    also possible to request and = allocate multiple quotas on a
> per service
>    basis. Where quotas are = allocated to a pool, the quotas
> remain independent
>    objects which can be = re-authorised independently at any
> time. Quotas can
>    also be given independent = validity times and
> Final-Unit-Indications. The
>    mechanism to share units = across services and rating groups
> is described
>    further in Section = 5.X.
>
> MSt: I think this is fine.
>
> > 5.X Sharing of units across services and = rating groups
>     To avoid credit = fragmentation and unnecessary load on the
> credit control
>     server, it is possible = for service units to be provided
> to multiple
>     services or rating = groups as a pool.
>     This is achieved by = providing the service units in the
> form of a quota for
>     a particular service or = rating group in the usual way,
> but also including
>     a reference to a credit = pool for that unit type. The
> reference includes a
>     multiplier which = translates from service units of a
> specific type to the
>     abstract service units = in the pool.
>
> MSt: I think it should be clarified what is = this
> 'multiplier'. Why don't you refer more = explicitely to the
> rating value (i.e. if cost $1/MB the multiplier = is 1 as far
> as I understand).

MW: We can work on some text offline - I think you = have a correct understanding of the concept. As I mentioned we just = wanted to avoid people getting sensitive about 'rating' in the = client.

>
>       Where = multiple G-S-U-Pool-Reference AVPs with the same
> G-S-U-Pool
>     Identifier are provided = within a Granted-Service-Units
> AVP then these
>     MUST have different = CC-Unit-Type values and they all draw
> on the credit
>     pool separately. =
>
> MSt: perhaps it would be good to expalin this = with an
> example, similarly as you did in the = introduction.
> >(e.g. Time and Volume) then multipliers can = be provided for
> one or more
> >of them. Where two >multipliers are = provided (e.g. M1t for
> time and M1v
> >for volume) then the used resource from = >the pool is the sum
> C1t*M1t +
> >C1v*M1v.
>

MW: Ok.

> 8.16 Granted-Service-Unit AVP 
>         =
>      
>    The Granted-Service-Unit AVP = has the following ABNF grammar:  
>          = ;   
>          = Granted-Service-Unit ::=3D < AVP Header: 431 >
>          = ;            = ;            = ; [ Tariff-Time-Change ]  
>          = ;            = ;            = ; [ CC-Time ]
>          = ;            = ;            = ; [ CC-Money ]  
>          = ;            = ;            = ; [ CC-Total-Octets ]
>          = ;            = ;            = ; [ CC-Input-Octets ]
>          = ;            = ;            = ; [ CC-Output-Octets ]
>          = ;            = ;            = ; [ CC-Service-Specific-Units ]
>          = ;            = ;            *[ = G-S-U-Pool-Reference ]
>          = ;            = ;            *[ = Service-Identifier ]
>          = ;            = ;            = ; [ Rating-Group ]
>          = ;            = ;            = ; [ Validity-Time ]
>          = ;            = ;            = ; [ Final-Unit-Indication ]
>
> MSt: it may be that the server returns a failed = Result-Code
> in the CCA caused by only one = service/rating-group. In that
> case we would close the whole (sub-)session = even though other
> services can continue. Perhaps it is apropriate = to also
> include the Result-Code in the G-S-U.
>

MW: Ok, makes sense - or it could be in this = intermediate level grouped AVC that you suggested, right ?

------_=_NextPart_001_01C3E9B6.B790DDB0-- From owner-aaa-wg@merit.edu Mon Feb 2 13:16:51 2004 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 NAA28478 for ; Mon, 2 Feb 2004 13:16:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC26991239; Mon, 2 Feb 2004 13:16:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7FCC9123B; Mon, 2 Feb 2004 13:16: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 9639691239 for ; Mon, 2 Feb 2004 13:16:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8046F5DD8F; Mon, 2 Feb 2004 13:16:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 7483E5DD92 for ; Mon, 2 Feb 2004 13:16:32 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12IGS629553; Mon, 2 Feb 2004 18:16:28 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 18:16:29 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'harri.hakala@ericsson.com'" , "'leena.mattila@ericsson.com'" , "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Benni.Alexander@nokia.com'" , "'patrik.teppo@ericsson.com'" Subject: RE: [AAA-WG]: Issue: DCC: Credit pooling should be under server c ontrol Date: Mon, 2 Feb 2004 18:16:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9B8.A9E11C64" 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_01C3E9B8.A9E11C64 Content-Type: text/plain Hi Marco, Comments on this one inline too. Again, happy to work offline to get a revised proposal together. Just for clarity, Issue 16 builds on and changes some of the things proposed in this one (17). It is probably best if we focus on the text from Issue 16 since I think that basically addresses both problems - I submitted two just because I saw two distinct problems. But that can have a common solution, I hope. Regards...Mark > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: 30 January 2004 16:36 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: aaa-wg@merit.edu; harri.hakala@ericsson.com; > leena.mattila@ericsson.com; john.loughney@nokia.com; > juha-pekka.koskinen@nokia.com; Benni.Alexander@nokia.com; > patrik.teppo@ericsson.com > Subject: RE: [AAA-WG]: Issue: DCC: Credit pooling should be > under server control > > > Hi Mark, > > >Therefore it's clear that it is the CC Client that controls the > >grouping of services or > >rating-groups into a single session or sub-session and hence > into a single credit pool. > > MSt: perhaps this is your interpretation. As stated many > times during our discussion the CC client doesn't control the > grouping of services in a single credit pool. But, this is > just clarification. > MW: I guess the point was just that as presently drafted the credit is pooled across all services in a sub-session & it is the client which decides how to group services into sub-sessions. Or were you referring to the funding of services from separate accounts, as described below ? > >Finally, the current draft omits to describe how credit pooling is > >applied in the case of > >services with multiple unit types (for example both time and volume). > > I think the Flow X exactly depict this case, but ok we need > to rewrite it. > MW: Ok. I meant the case where one service has both a time and a volume quota, not where there is a time-based service together in a sub-session with a different volume-based service. For example a service may be charged per MB but has a time quota of 2 hours as well because the per MB rate is only valid for the first 2 hours. The current draft is not clear about how to interpret multiple unit types in a single G-S-U, but in one interpretation, the passing of time for this service would reduce the available quota for other services (it would be counted towards the current %age of the reservation that has been used), whereas this is not the intention. > >In order to let the responsibility of grouping to the sever, > i.e, the > >server decides what > >services can be shared with the credit allocated, we should > introduce a new AVP in the CCA >called "G-S-U-Pool-Reference" > AVP within the Granted-Service-Unit. > >The G-S-U-Pool-Reference represents a reference from the > Granted-Service-Units to a > >'Granted Service Units Pool'. The Granted Service Units Pool > is identified by a unique > >identifier (new G-S-U-Pool-Identifier AVP). The reference is > specific to a particular kind >of unit (i.e. Time/Money/Volume). > > MSt: Agree. > > >Granted-Service-Units within a session which refer to the > same Granted > >Service Units Pool > >are considered to draw from a single pool of credit. This > applies even when they are in > >different sub-sessions. > > MSt: I agree with the concept you propose except that CCR > sent in one (sub-)session MUST not include quotas given in > another (sub-)session even thoguh they draw from the same > account i.e. each (sub-)session is handled separately, no mixing. > MW: Yes, agreed. That was the intention. > > Note that this concept implies that one single credit reservation > is kept and allocated to all the services/rating groups > within a credit > pool. All the quotas associated with the credit pool are > derived from that > entire credit reservation i.e. assuming each given > service/rating group > consumes the whole amount. Therefore the quotas conveyed > to the Diameter > Credit control client are not independent entities - that > is the client can > completely consume only a single one of them, or partially > consume some > combination. Where a single service or rating group has > multiple quotas of > different types (e.g. time and volume), these are > considered as separate > quotas within the credit pool. An example of this > mechanism is illustrated > in Appendix A (Flow X). > > MSt: since each service/rating-group seems to have its own > reservation, the above text is now inaccurate. What about > removing or rewriting it? MW: Yes, if we go forward with both Issues 16 and 17 then this text is replaced by text from Issue 16. What we have above is a way to give the client control of the pooling, but for the pools then to operate in the same way as in the present draft (i.e. using the existing formula). > > >8.16 Granted-Service-Unit AVP > > Re-authorisation must be sought when the credit pool is > exhausted. A credit > pool is considered exhausted when the sum of the > fractional amounts of the > granted credit for all the quotas associated with the same > credit pool > reaches unity. > > >8.X G-S-U-Pool-Identifier AVP > > Granted-Service-Units associated > within a single Credit Pool are assumed to be drawn from > a common credit > reservation. Therefore, re-authorisation MUST be sought > when the combined > resource used by all the services or rating groups within > the credit pool > reaches 100% of the amount granted. > > MSt: to me these sounds a bit inaccurate descriptions, it > doesn't reflect the equations defined in the other issue > (issue 16). I would perhaps consider rewriting. > MW: Yes - Issue 16 changes this text too (or it should!) > > 8.Y G-S-U-Pool-Reference AVP > The G-S-U-Pool-Reference AVP (AVP code tbd) is of type > Grouped and > associates the Granted-Service-Units AVP within which it > appears with a > credit pool within the session for a single unit type. > The CC-Unit-Type > AVP specifies the type of units for which credit is > pooled. The Credit- > Pool-Identifier AVP specifies the credit pool from which > credit is drawn > for this unit type. > G-S-U-Pool-Reference ::= < AVP Header: tbd > > ( G-S-U-Pool-Identifier ) > ( CC-Unit-Type ) > > MSt: I think there is better description in issue 16. The > ABNF grammar should be: > > G-S-U-Pool-Reference ::= < AVP Header: tbd > > { G-S-U-Pool-Identifier } > [ CC-Unit-Type ] > [ Unit-Value ] > MW: What would be the meaning of a G-S-U-Pool-Reference with no CC-Unit-Type ? > Regards > Marco > ------_=_NextPart_001_01C3E9B8.A9E11C64 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC: Credit pooling should be under server = control

Hi Marco,

Comments on this one inline too. Again, happy to work = offline to get a revised proposal together.

Just for clarity, Issue 16 builds on and changes some = of the things proposed in this one (17). It is probably best if we = focus on the text from Issue 16 since I think that basically addresses = both problems - I submitted two just because I saw two distinct = problems. But that can have a common solution, I hope.

Regards...Mark

> -----Original Message-----
> From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
> Sent: 30 January 2004 16:36
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: aaa-wg@merit.edu; = harri.hakala@ericsson.com;
> leena.mattila@ericsson.com; = john.loughney@nokia.com;
> juha-pekka.koskinen@nokia.com; = Benni.Alexander@nokia.com;
> patrik.teppo@ericsson.com
> Subject: RE: [AAA-WG]: Issue: DCC: Credit = pooling should be
> under server control
>
>
> Hi Mark,
>
> >Therefore it's clear that it is the CC = Client that controls the
> >grouping of services or
> >rating-groups into a single session or = sub-session and hence
> into a single credit pool.
>
> MSt: perhaps this is your interpretation. As = stated many
> times during our discussion the CC client = doesn't control the
> grouping of services in a single credit pool. = But, this is
> just clarification.
>

MW: I guess the point was just that as presently = drafted the credit is pooled across all services in a sub-session & = it is the client which decides how to group services into sub-sessions. = Or were you referring to the funding of services from separate = accounts, as described below ?

> >Finally, the current draft omits to describe = how credit pooling is
> >applied in the case of
> >services with multiple unit types (for = example both time and volume).
>
> I think the Flow X exactly depict this case, = but ok we need
> to rewrite it.
>

MW: Ok. I meant the case where one service has both a = time and a volume quota, not where there is a time-based service = together in a sub-session with a different volume-based service. For = example a service may be charged per MB but has a time quota of 2 hours = as well because the per MB rate is only valid for the first 2 hours. = The current draft is not clear about how to interpret multiple unit = types in a single G-S-U, but in one interpretation, the passing of time = for this service would reduce the available quota for other services = (it would be counted towards the current %age of the reservation that = has been used), whereas this is not the intention.

> >In order to let the responsibility of = grouping to the sever,
> i.e, the
> >server decides what
> >services can be shared with the credit = allocated, we should
> introduce a new AVP in the CCA >called = "G-S-U-Pool-Reference"
> AVP within the Granted-Service-Unit.
> >The G-S-U-Pool-Reference represents a = reference from the
> Granted-Service-Units to a
> >'Granted Service Units Pool'. The Granted = Service Units Pool
> is identified by a unique
> >identifier (new G-S-U-Pool-Identifier AVP). = The reference is
> specific to a particular kind >of unit (i.e. = Time/Money/Volume).
>
> MSt: Agree.
>
> >Granted-Service-Units within a session = which refer to the
> same Granted
> >Service Units Pool
> >are considered to draw from a single pool = of credit. This
> applies even when they are in
> >different sub-sessions.
>
> MSt: I agree with the concept you propose = except that CCR
> sent in one (sub-)session MUST not include = quotas given in
> another (sub-)session even thoguh they draw = from the same
> account i.e. each (sub-)session is handled = separately, no mixing.
>

MW: Yes, agreed. That was the intention.

>  >  Note that this concept implies = that one single credit reservation
>    is kept and allocated to all = the services/rating groups
> within a credit
>    pool. All the quotas = associated with the credit pool are
> derived from that
>    entire credit reservation = i.e. assuming each given
> service/rating group
>    consumes the whole amount. = Therefore the quotas conveyed
> to the Diameter
>    Credit control client are not = independent entities - that
> is the client can
>    completely consume only a = single one of them, or partially
> consume some
>    combination. Where a single = service or rating group has
> multiple quotas of
>    different types (e.g. time = and volume), these are
> considered as separate
>    quotas within the credit = pool. An example of this
> mechanism is illustrated
>    in Appendix A (Flow X). =
>
> MSt: since each service/rating-group seems to = have its own
> reservation, the above text is now inaccurate. = What about
> removing or rewriting it?

MW: Yes, if we go forward with both Issues 16 and 17 = then this text is replaced by text from Issue 16. What we have above is = a way to give the client control of the pooling, but for the pools then = to operate in the same way as in the present draft (i.e. using the = existing formula).

>
> >8.16 Granted-Service-Unit AVP
> 
>    Re-authorisation must be = sought when the credit pool is
> exhausted. A credit
>    pool is considered exhausted = when the sum of the
> fractional amounts of the
>    granted credit for all the = quotas associated with the same
> credit pool
>    reaches unity.
>
> >8.X G-S-U-Pool-Identifier AVP
>
>     Granted-Service-Units = associated
>     within a single Credit = Pool are assumed to be drawn from
> a common credit
>     reservation. Therefore, = re-authorisation MUST be sought
> when the combined
>     resource used by all = the services or rating groups within
> the credit pool
>     reaches 100% of the = amount granted.
>
> MSt: to me these sounds a bit inaccurate = descriptions, it
> doesn't reflect the equations defined in the = other issue
> (issue 16). I would perhaps consider = rewriting.
>

MW: Yes - Issue 16 changes this text too (or it = should!)

> > 8.Y G-S-U-Pool-Reference AVP
>     The = G-S-U-Pool-Reference AVP (AVP code tbd) is of type
> Grouped and
>     associates the = Granted-Service-Units AVP within which it
> appears with a
>     credit pool within the = session for a single unit type.
> The CC-Unit-Type
>     AVP specifies the type = of units for which credit is
> pooled. The Credit-
>     Pool-Identifier AVP = specifies the credit pool from which
> credit is drawn
>     for this unit type. =
>          = G-S-U-Pool-Reference    ::=3D < AVP Header: tbd > =
>          = ;            = ;            = ; ( G-S-U-Pool-Identifier )
>          = ;            = ;            = ; ( CC-Unit-Type )
>
> MSt: I think there is better description in = issue 16. The
> ABNF grammar should be:
>
>          = ;   G-S-U-Pool-Reference ::=3D < AVP Header: tbd > =
>          = ;            = ;            = ;    { G-S-U-Pool-Identifier }
>          = ;            = ;            = ;    [ CC-Unit-Type ]
>          = ;            = ;            = ;    [ Unit-Value ]
>

MW: What would be the meaning of a = G-S-U-Pool-Reference with no CC-Unit-Type ?
 
> Regards
> Marco
>

------_=_NextPart_001_01C3E9B8.A9E11C64-- From owner-aaa-wg@merit.edu Mon Feb 2 13:32:44 2004 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 NAA29266 for ; Mon, 2 Feb 2004 13:32:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 538F59123B; Mon, 2 Feb 2004 13:32:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1745D9123C; Mon, 2 Feb 2004 13:32:24 -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 D23259123B for ; Mon, 2 Feb 2004 13:32:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id A90025DDC4; Mon, 2 Feb 2004 13:32:20 -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 9635D5DD8E for ; Mon, 2 Feb 2004 13:32:19 -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 i12IWE304466; Mon, 2 Feb 2004 12:32:14 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVXJF6>; Mon, 2 Feb 2004 12:32:14 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8F1F@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'John.Prudhoe@vodafone.com'" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 12:32:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9BA.DC6F81F0" 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_01C3E9BA.DC6F81F0 Content-Type: text/plain Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 11:24 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. **************************************************************************** ** 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 **************************************************************************** ** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3E9BA.DC6F81F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the = only limitation being that when allocating quotas in time, there is no = way to tell what events or bytes were used when during the quota usage. = E.g. the user pays the operator based upon time, but a third party = content provider pays the operator based upon bytes/events used by the = user at a particular time. Perhaps that's not a big deal and there are = ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC = is not an issue either (Although, as an operator, I'd have to = disagree!) - it is a limitation due to implementation rather than due = to the specification.

With that in mind, here is the updated = proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May = fix ]
Sections: 5.0, 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change = capability by allowing the Used-Service-Units to report back the used = resources before and after a tariff change. However, the resources = supplied by the DCC server are given in a single Granted-Service-Units = AVP. However, using this mechanism has a number of drawbacks and = practical issues:

1. It is complex for the DCC server since it must = reserve credit on the basis of which will be more expensive before or = after consumption (As acknowledged in section 5 of the draft). This is = particularly inconvenient when the model changes e.g. some bundled = minutes after the duration, or rates change to a minimum of x or any = other model. As a result, either the server will have to allocate = smaller quotas resulting in increased quota activity and possibly = impacted subscriber experience, or it will have to reserve a larger = amount of credit exacerbating credit fragmentation concerns.


Requested changes:

- Section 5, last paragraph:

FROM:
   The Diameter credit-control server and = client may optionally support a
   tariff change mechanism. The Diameter = credit-control server may
   include a Tariff-Time-Change AVP in the = answer message. Note that the
   granted units should be allocated based = on the worst-case scenario in
   case of forthcoming tariff change, so = that the overall reported used
   units would never exceed the credit = reservation. 
   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. In case = some units straddled the tariff
   change, the credit-control client = SHOULD itemize those units as well.

TO:
   The Diameter credit-control server and = client may optionally support a
   tariff change mechanism. The Diameter = credit-control server may
   include both the Tariff-Time-Change and = Tariff-Change-Usage AVPs in
   two quota allocations in the answer = message. One of the granted units is
   allocated to be used before the = potential tariff change while the
   second granted units are used after a = tariff change. Both granted unit
   quotas MUST contain the same = Service-Identifier and Rating-Group values.
   This dual quota mechanism ensures that = the overall reported used
   units would never exceed the credit = reservation. 
   The Diameter credit-control client = reports both the used units before
   and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
   The Tariff-Change-Usage AVP is included = when the Tariff-Time-Change AVP is
   present. It instructs the client when = the resources in the Granted-Service-
   Unit AVP should be used.

   When both the Tariff-Time-Change and = Tariff-Change-Usage AVPs are present,
   the server MUST include two separate = Granted-Service-Unit AVPs (for the
   same Service-Identifier and/or = Rating-Group when either the Service-
   Identifier or Rating-Group AVP is = included). One of the Granted-Service-
   Units resources are used before a = tariff change occurs, while the other
   is to be used after the tariff change = has occurred.

- Section 8.16, last paragraph:

FROM:
   The Granted-Service-Unit AVP has the = following ABNF grammar:  
          &nb= sp; 
         = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &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 ]
TO:
   The Granted-Service-Unit AVP has the = following ABNF grammar:  
          &nb= sp; 
         = Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;           [ = Tariff-Time-Change ]  
          &nb= sp;           &nb= sp;           = [Tariff-Change-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 ]


- end of changes


Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.c= om]
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; = John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism



Hi Chris,

My reasoning behind this is that time based quotas = are consumed at a regular rate (60 seconds per minute to be = exact).  So imagine that the rating engine allocates 300 seconds = at a time 130 seconds before the tariff time change.  At that = point it already knows that 130seconds will be consumed at the before = rate and 170 seconds will be consumed at the rate afterwards. =

The client only knows it has been given 300s not how = much it costs and it need never know about the tariff time = change.  If the session continues, the client will come back at = the end of the 300s and not at the time of the tariff change. =

If the session ends after, say, 90s the rating engine = knows that has all been consumed at the before rate.  If it ends = after 140seconds, the rating engine knows it can be split into 130s at = the before rate and 10s at the after rate.  In neither of these = circumstances does the client need to know about the tariff time change = nor does it need to return to the server at the time of the tariff = change.

I hope this explains it.

Regards,

John.





"Christopher Richards" = <crich@nortelnetworks.com>
02/02/2004 17:11
       
        = To:        = "'marco.stura@nokia.com'" <marco.stura@nokia.com> =
        = cc:        aaa-wg@merit.edu, = John.Prudhoe@vodafone.com, john.loughney@nokia.com
        = Subject:        RE: [AAA-WG]: DCC: = Issue: Tariff Change mechanism



Hi Marco, All,
 
Agreed, no need to talk 3GPP or any specific = standards organisation other than IETF here.
 
I'm interested in your statement that time based = quotas have no interaction between the client/server:
But for time based services there is no need for any = interaction between server and client as
also stated by John P .
Could you explain your reasoning?
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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; = john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism

   [CR] That's OK for voice traffic. I = guess we need the
  input from some of some data OCS vendors. = Interestingly,
  3GPP went with the new proposal for IMS in = Release 5 -
  this was a Diameter protocol.
 
3GPP uses Diameter DCC in the context of IMS online = charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed = there for time based services sometime ago.
But for time based services there is no need for any = interaction between server and client as
also stated by John P.  Interestingly, there = are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, = so apparently not all in the 3GPP community
are of the same opinion. So the statement that = "3GPP went  with the new proposal etc." is rather =
inaccurate.
 
However, I think the AAA mailing list is not the = appropriate place to discuss 3GPP specific
issues.
 
Thank you
Marco
 
 
 -----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; = Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism

Hi Leena,
Thanks for the reply. I have added some comments = below.
Best Regards,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; = 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism
Hi Chris,
the way it is proposed in the draft-02 is similar as = currently implemented in the IN/CAMEL systems and we are not aware of = any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I = guess we need the
  input from some of some data OCS vendors. = Interestingly,
  3GPP went with the new proposal for IMS in = Release 5 -
  this was a Diameter protocol.
Concerning the proposed mechanism it seems the = server would need to allocate credit both before and after the tariff = change.

   [CR] Yes. But this is effectively the = same for the
  existing mechanism. Except that in the = existing mechanism,
  since only one allocation can actually be = given, the OCS
  must make the allocation based upon the worst = case scenario
  and provide quota in small enough amounts so = that the usage
  at a potentially higher cost can be covered = by the users
  account. In other words the OCS has to make = decisions up
  front that it can then only really reconcile = after the usage.
 If the server wants to minimize the likelihood = of higher
re-authorization traffic load, it would have to = allocate bigger credit in both categories since it doesn't know whether = more units will be consumed before or after.

   [CR] Not at all. It can make a decision = about how much "after"
  quota to allocate because it knows how much = is available in the
  users account because it has already = allocated the "before"
  quota. It now has the power to allocate as = much or as little
  "after" quota as it sees fit - = smaller chunks to avoid credit
  fragmentation - but this is also a function = of how long before
  a tariff change that the quota is requested. = I.e. 30 seconds
  before a TC, it can allocate more to the = "after" quota. However,
  if the request is being made 30 minutes = before a TC, then it
  would allocate less to the "after" = quota.
If the server wants to minimize the credit = fragmentation would need to allocate smaller credit, at the expences of = higher re-autht traffic load. So, I fully agree with John P. in that = the proposed mechanism defeats both the objectives of trying to reduce = credit fragmentation and trying to minimize the re-auth traffic load. =

   [CR] The intention of my proposal was = not to make it optional:
  it was to replace the existing scheme. I = think we all agree
  that 2 parallel mechanisms would be best to = avoid. It will
  make it more difficult for OCS vendors to = implement.
John Loughney wrote:
>I am quite worried about additional optional = mechanisms.  Already the
>specification is quite complicated and I worry = that additional optional
>mechansisms will create extremely complicated = mechanisms.
>
>I favor simplication at this point, so I'd hope = we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more = optionality. We should support only one way of doing tariff switch (tsw = itself is optional already, optionality within one option is not = desirable).

BR,
Leena
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu =
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism
Hi Chris,
I've no objection myself in principle to your = mechanism of allocating quotas together for both units before and units = after the tariff change.  As long as it is all optional. =

The question is: how likely is the client to run out = of the before units before the time of the tariff change.  This = would trigger an re-authorisation even though the units after are = unused.  To avoid this, the server would have to allocated a = higher quota in that category.  Alternatively, if the user did = little before the tariff change and lots after they would be likely to = consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't = reduce the volume of authorisation traffic in practice unless larger = quotas are allocated, which I think defeats your objective of trying to = reduce credit fragmentation.

Regards,
John.




"Christopher Richards" = <crich@nortelnetworks.com>
30/01/2004 16:27
      
       = To:        = "'John.Prudhoe@vodafone.com'" = <John.Prudhoe@vodafone.com>
       = cc:        = "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, = owner-aaa-wg@merit.edu
       = Subject:        RE: [AAA-WG]: DCC: = Issue: Tariff Change mechanism.


Thanks for the reply John,
 
Since there are implementations that can generate = straddling usage counts today, I don't have a problem leaving this = value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed = mechanism in the draft should address it's shortcomings as I described = in the Issue email I sent. Will the change proposal be accepted as an = issue to discuss? If so, should I resubmit the issue with the change = described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.c= om]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu =
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change = mechanism.
Hi Chris,
The option to specify units straddlling a tariff = time change was suggested by us as we have an implemented system that = behaves like this.

There is a fundamental difference between tariffs = changing for a service that is consumed at a regular rate (i.e. time = based such as circuit-switched calls) and one that is consumed at an = irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report = the Tariff-Time-Change AVP to the client.  It doesn't even need to = know that the tariff has changed.  When the server knows that = there is tariff change due it can take this into account when rating = the granted units.  There is no need for any additional Diameter = traffic for time-based services when there is a tariff change. =

Regards,
John.



"Christopher Richards" = <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 = 16:09        
      = To:        = "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
      = cc:        
      = Subject:        [AAA-WG]: DCC: = Issue: Tariff Change mechanism.



All,
Please find enclosed issue regarding the current = tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May = fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change = capability by allowing the Used-Service-Units to report back the used = resources before and after a tariff change. However, the resources = supplied by the DCC server are given in a single Granted-Service-Units = AVP. However, using this mechanism has a number of drawbacks and = practical issues:

1. It is complex for the DCC server since it must = reserve credit on the basis of which will be more expensive before or = after consumption (As acknowledged in section 5 of the draft). This is = particularly inconvenient when the model changes e.g. some bundled = minutes after the duration, or rates change to a minimum of x or any = other model. As a result, either the server will have to allocate = smaller quotas resulting in increased quota activity or it will have to = reserve a larger amount of credit exacerbating credit fragmentation = concerns.

2. The draft document states that the mechanism is = not used when the resource unit is time. However, in order to perform = tariff time changes, the client will have to re-authorise all quotas = for all sessions that react to the same tariff time change - this will = lead to a flood of messaging and processing on the client and server = which will result in delayed responses and inaccurate time change = values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), = a different mechanism has been introduced for the Diameter IMS charging = application which avoids the problems stated above - there are no = longer used resources that straddle a tariff change thus removing this = indeterminate charging scenario. It would seem highly desirable to = align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may = optionally support a
tariff change mechanism. The Diameter credit-control = server may
include a Tariff-Time-Change AVP in the answer = message. Note that the
granted units should be allocated based on the = worst-case scenario in
case of forthcoming tariff change, so that the = overall reported used
units would never exceed the credit = reservation. 
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. In case some units = straddled the tariff
change, the credit-control client SHOULD itemize = those units as well.
TO:
The Diameter credit-control server and client may = optionally support a
tariff change mechanism. The Diameter credit-control = server may
include both the Tariff-Time-Change and = Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. = One of the granted units is
allocated to be used before the potential tariff = change while the
second granted units are used after a tariff change. = Both granted unit
quotas MUST contain the same Service-Identifier and = Rating-Group values.
This dual quota mechanism ensures that the overall = reported used
units would never exceed the credit = reservation. 
The Diameter credit-control client reports both the = used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the = Tariff-Time-Change AVP is
present. It instructs the client when the resources = in the Granted-Service-
Unit AVP should be used.
  When both the Tariff-Time-Change and = Tariff-Change-Usage AVPs are present,
the server MUST include two separate = Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when = either the Service-
Identifier or Rating-Group AVP is included). One of = the Granted-Service-
Units resources are used before a tariff change = occurs, while the other
is to be used after the tariff change has occurred. =
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF = grammar:  
         
      Granted-Service-Unit = ::=3D < AVP Header: 431 >
          &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 ]
         = ;            = ;          [ Rating-Group = ]
TO:
The Granted-Service-Unit AVP has the following ABNF = grammar:  
         
      Granted-Service-Unit = ::=3D < AVP Header: 431 >
          &nb= sp;           &nb= sp;        [ Tariff-Time-Change = ]  
          &nb= sp;           &nb= sp;        [Tariff-Change-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 ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type = Time, and
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. 
 
TO:
The Tariff-Time-Change AVP (AVP code 451) is of type = Time, and
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 optionally = enabled by the server for a
Diameter credit control session or sub-session. =
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of = type Enumerated and
defines whether units are used before, after or = straddled tariff
change when a tariff change has occurred during the = reporting period.
Omission of this AVP means that no tariff change has = been occurred.
 
Tariff-Change-Usage can be one of the following. =
 
 UNIT_BEFORE_TARIFF_CHANGE     &n= bsp;           &n= bsp;           &n= bsp;    0
 
  The used units contains the amount of the = units before 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     &nb= sp;           &nb= sp;           &nb= sp;     1
   The used units contains the amount of = the units after tariff change
  has been occurred.
 
 UNIT_INDETERMINATE      &nb= sp;           &nb= sp;           &nb= sp;          2
 
  The used units contains the amount of units = that straddle the
  tariff change (e.g. the metering process = reports to the credit-
  control client in blocks of n octets and one = block straddled the
  tariff change).
TO:   
The Tariff-Change-Usage AVP (AVP code 452) is of = type Enumerated.
  When present in the Granted-Service-Units = AVP, this AVP defines whether
units are allocated to be used before or after a = tariff change event.
  When present in the Used-Service-Units AVP, = this AVP identified what
resources where used before or after a tariff change = during the reporting
period.
  Omission of this AVP means that no tariff = change is to be reported and/or
none has occurred.
 
Tariff-Change-Usage can be one of the following. =
 
 UNIT_BEFORE_TARIFF_CHANGE     &n= bsp;           &n= bsp;           &n= bsp;    0
 
  When present in the Granted-Service-Units = AVP, this value indicates
  the amount of the units allocated for use = before a tariff change
  occurs.
    When present in the = Reported-Service-Units AVP, this value indicates
  the amount of resource units used before a = tariff change had occurred.
 
 UNIT_AFTER_TARIFF_CHANGE     &nb= sp;           &nb= sp;           &nb= sp;     1
 
  When present in the Granted-Service-Units = AVP, this value indicates
  the amount of the units allocated for use = after a tariff change
  occurs.
    When present in the = Reported-Service-Units AVP, this value indicates
  the amount of resource units used after = tariff change had occurred.
  
- end of changes
Best Regards,
Chris Richards.
***************************************************************= ***************
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
***************************************************************= ***************
This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank you. =

E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

------_=_NextPart_001_01C3E9BA.DC6F81F0-- From owner-aaa-wg@merit.edu Mon Feb 2 14:08:45 2004 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 OAA03192 for ; Mon, 2 Feb 2004 14:08:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1A8F9123D; Mon, 2 Feb 2004 14:08:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D63191240; Mon, 2 Feb 2004 14:08: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 873C99123D for ; Mon, 2 Feb 2004 14:08:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 669F25DDA4; Mon, 2 Feb 2004 14:08:25 -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 1080F5DDA3 for ; Mon, 2 Feb 2004 14:08:23 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Mon, 2 Feb 2004 19:12:31 +0000 To: "Christopher Richards" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Mon, 2 Feb 2004 19:08:07 +0000 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 02/02/2004 07:08:11 PM, Serialize complete at 02/02/2004 07:08:11 PM Content-Type: multipart/alternative; boundary="=_alternative 00691A1D80256E2E_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00691A1D80256E2E_= Content-Type: text/plain; charset="us-ascii" Hi Chris, I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism. I'm making up these examples entirely at random to compare the cases. Example 1: old mechanism. A client wants a quota to send data over GPRS. It is 15 minutes before the tariff change. The tariff is higher before the change. The server allocates 50K with a validity time of 30 minutes, say. The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards). This is rated at that time and some of the monetary reservation is returned to the subscribers balance. This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported. Example 2: new mechanism. The client still wants a quota to send data over GPRS. The server allocates 25K at the expensive rate and 25K at the cheap rate. (That's already two rating events in the billing system). Validity time again 30 minutes. I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS). Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted. Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K. When the client next returns it will reports the usage in these categories, which will again have to be rated. So in example one, there are three rating events and the exchange of two Diameter command pairs. In example two there are between six and eight rating events and the exchange of three Diameter command pairs. Even in the best case with your method I believe there will be four rating events. I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it. Regards, John "Christopher Richards" 02/02/2004 18:32 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 11:24 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. ****************************************************************************** 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 ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --=_alternative 00691A1D80256E2E_= Content-Type: text/html; charset="us-ascii"
Hi Chris,

I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism.  I'm making up these examples entirely at random to compare the cases.

Example 1: old mechanism.

A client wants a quota to send data over GPRS.  It is 15 minutes before the tariff change.  The tariff is higher before the change.  The server allocates 50K with a validity time of 30 minutes, say.

The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards).  This is rated at that time and some of the monetary reservation is returned to the subscribers balance.  This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported.

Example 2: new mechanism.

The client still wants a quota to send data over GPRS.  The server allocates 25K at the expensive rate and 25K at the cheap rate.  (That's already two rating events in the billing system).  Validity time again 30 minutes.

I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS).

Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted.  Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K.  When the client next returns it will reports the usage in these categories, which will again have to be rated.


So in example one, there are three rating events and the exchange of two Diameter command pairs.  In example two there are between six and eight rating events and the exchange of three Diameter command pairs.  Even in the best case with your method I believe there will be four rating events.

I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it.

Regards,

John




"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 18:32

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism



Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification.

With that in mind, here is the updated proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 5.0, 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

Requested changes:

- Section 5, last paragraph:

FROM:
  The Diameter credit-control server and client may optionally support a
  tariff change mechanism. The Diameter credit-control server may
  include a Tariff-Time-Change AVP in the answer message. Note that the
  granted units should be allocated based on the worst-case scenario in
  case of forthcoming tariff change, so that the overall reported used
  units would never exceed the credit reservation.  
  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. In case some units straddled the tariff
  change, the credit-control client SHOULD itemize those units as well.

TO:
  The Diameter credit-control server and client may optionally support a
  tariff change mechanism. The Diameter credit-control server may
  include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
  two quota allocations in the answer message. One of the granted units is
  allocated to be used before the potential tariff change while the
  second granted units are used after a tariff change. Both granted unit
  quotas MUST contain the same Service-Identifier and Rating-Group values.
  This dual quota mechanism ensures that the overall reported used
  units would never exceed the credit reservation.  
  The Diameter credit-control client reports both the used units before
  and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
  The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
  present. It instructs the client when the resources in the Granted-Service-
  Unit AVP should be used.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
  the server MUST include two separate Granted-Service-Unit AVPs (for the
  same Service-Identifier and/or Rating-Group when either the Service-
  Identifier or Rating-Group AVP is included). One of the Granted-Service-
  Units resources are used before a tariff change occurs, while the other
  is to be used after the tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
  The Granted-Service-Unit AVP has the following ABNF grammar:  
           
        Granted-Service-Unit ::= < AVP Header: 431 >
                                 [ Tariff-Time-Change ]  
                                 [ CC-Time ]
                                 [ CC-Money ]  
                                 [ CC-Total-Octets ]
                                 [ CC-Input-Octets ]
                                 [ CC-Output-Octets ]
                                 [ CC-Service-Specific-Units ]
                                *[ Service-Identifier ]
                                 [ Rating-Group ]
TO:
  The Granted-Service-Unit AVP has the following ABNF grammar:  
           
        Granted-Service-Unit ::= < AVP Header: 431 >
                                 [ Tariff-Time-Change ]  
                                 [Tariff-Change-Usage ]
                                 [ CC-Time ]
                                 [ CC-Money ]  
                                 [ CC-Total-Octets ]
                                 [ CC-Input-Octets ]
                                 [ CC-Output-Octets ]
                                 [ CC-Service-Specific-Units ]
                                *[ Service-Identifier ]
                                 [ Rating-Group ]

- end of changes

Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards.

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change.

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>
02/02/2004 17:11
       
       To:        "'marco.stura@nokia.com'" <marco.stura@nokia.com>
       cc:        aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com
       Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Marco, All,
 
Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.
 
I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?
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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I guess we need the
 input from some of some data OCS vendors. Interestingly,
 3GPP went with the new proposal for IMS in Release 5 -
 this was a Diameter protocol.
 
3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.
 
However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.
 
Thank you
Marco
 
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,
Thanks for the reply. I have added some comments below.
Best Regards,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
 input from some of some data OCS vendors. Interestingly,
 3GPP went with the new proposal for IMS in Release 5 -
 this was a Diameter protocol.
Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
 existing mechanism. Except that in the existing mechanism,
 since only one allocation can actually be given, the OCS
 must make the allocation based upon the worst case scenario
 and provide quota in small enough amounts so that the usage
 at a potentially higher cost can be covered by the users
 account. In other words the OCS has to make decisions up
 front that it can then only really reconcile after the usage.
If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
 quota to allocate because it knows how much is available in the
 users account because it has already allocated the "before"
 quota. It now has the power to allocate as much or as little
 "after" quota as it sees fit - smaller chunks to avoid credit
 fragmentation - but this is also a function of how long before
 a tariff change that the quota is requested. I.e. 30 seconds
 before a TC, it can allocate more to the "after" quota. However,
 if the request is being made 30 minutes before a TC, then it
 would allocate less to the "after" quota.
If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
 it was to replace the existing scheme. I think we all agree
 that 2 parallel mechanisms would be best to avoid. It will
 make it more difficult for OCS vendors to implement.
John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,
John.



"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
     
      To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
      cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
      Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Thanks for the reply John,
 
Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.
Hi Chris,
The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,
John.


"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
     To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
     cc:        
     Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.


All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.
TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.
 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
     Granted-Service-Unit ::= < AVP Header: 431 >
                              [ Tariff-Time-Change ]  
                              [ CC-Time ]
                              [ CC-Money ]  
                              [ CC-Total-Octets ]
                              [ CC-Input-Octets ]
                              [ CC-Output-Octets ]
                              [ CC-Service-Specific-Units ]
                             *[ Service-Identifier ]
                              [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
     Granted-Service-Unit ::= < AVP Header: 431 >
                              [ Tariff-Time-Change ]  
                              [Tariff-Change-Usage ]
                              [ CC-Time ]
                              [ CC-Money ]  
                              [ CC-Total-Octets ]
                              [ CC-Input-Octets ]
                              [ CC-Output-Octets ]
                              [ CC-Service-Specific-Units ]
                             *[ Service-Identifier ]
                              [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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.  
 
TO:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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 optionally enabled by the server for a
Diameter credit control session or sub-session.
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
defines whether units are used before, after or straddled tariff
change when a tariff change has occurred during the reporting period.
Omission of this AVP means that no tariff change has been occurred.
 
Tariff-Change-Usage can be one of the following.
 
UNIT_BEFORE_TARIFF_CHANGE                                  0
 
 The used units contains the amount of the units before 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.
 
UNIT_INDETERMINATE                                         2
 
 The used units contains the amount of units that straddle the
 tariff change (e.g. the metering process reports to the credit-
 control client in blocks of n octets and one block straddled the
 tariff change).
TO:    
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
 When present in the Granted-Service-Units AVP, this AVP defines whether
units are allocated to be used before or after a tariff change event.
 When present in the Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during the reporting
period.
 Omission of this AVP means that no tariff change is to be reported and/or
none has occurred.
 
Tariff-Change-Usage can be one of the following.
 
UNIT_BEFORE_TARIFF_CHANGE                                  0
 
 When present in the Granted-Service-Units AVP, this value indicates
 the amount of the units allocated for use before a tariff change
 occurs.
   When present in the Reported-Service-Units AVP, this value indicates
 the amount of resource units used before a tariff change had occurred.
 
UNIT_AFTER_TARIFF_CHANGE                                   1
 
 When present in the Granted-Service-Units AVP, this value indicates
 the amount of the units allocated for use after a tariff change
 occurs.
   When present in the Reported-Service-Units AVP, this value indicates
 the amount of resource units used after tariff change had occurred.
 
- end of changes
Best Regards,
Chris Richards.
******************************************************************************
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
******************************************************************************
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--=_alternative 00691A1D80256E2E_=-- From owner-aaa-wg@merit.edu Mon Feb 2 14:59:32 2004 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 OAA05197 for ; Mon, 2 Feb 2004 14:59:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 50ACC91240; Mon, 2 Feb 2004 14:59:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 183DC91241; Mon, 2 Feb 2004 14:59:16 -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 0DE7A91240 for ; Mon, 2 Feb 2004 14:59:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA3B15DE01; Mon, 2 Feb 2004 14:59:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 658CF5DDFF for ; Mon, 2 Feb 2004 14:59:11 -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 i12Jx4A27707; Mon, 2 Feb 2004 11:59:04 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVXL35>; Mon, 2 Feb 2004 13:59:04 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8F24@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'John.Prudhoe@vodafone.com'" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 2 Feb 2004 13:58:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9C6.FEFB4A86" 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_01C3E9C6.FEFB4A86 Content-Type: text/plain Hi John, Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:- Old mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small. New mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate. In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests. In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate. Cheers, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 1:08 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism. I'm making up these examples entirely at random to compare the cases. Example 1: old mechanism. A client wants a quota to send data over GPRS. It is 15 minutes before the tariff change. The tariff is higher before the change. The server allocates 50K with a validity time of 30 minutes, say. The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards). This is rated at that time and some of the monetary reservation is returned to the subscribers balance. This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported. Example 2: new mechanism. The client still wants a quota to send data over GPRS. The server allocates 25K at the expensive rate and 25K at the cheap rate. (That's already two rating events in the billing system). Validity time again 30 minutes. I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS). Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted. Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K. When the client next returns it will reports the usage in these categories, which will again have to be rated. So in example one, there are three rating events and the exchange of two Diameter command pairs. In example two there are between six and eight rating events and the exchange of three Diameter command pairs. Even in the best case with your method I believe there will be four rating events. I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it. Regards, John "Christopher Richards" 02/02/2004 18:32 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 11:24 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. **************************************************************************** ** 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 **************************************************************************** ** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3E9C6.FEFB4A86 Content-Type: text/html Message

Hi John,
 
Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:-
 
Old mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small.
New mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate.
 
In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests.
 
In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate.

Cheers,
Chris.

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism.  I'm making up these examples entirely at random to compare the cases.

Example 1: old mechanism.

A client wants a quota to send data over GPRS.  It is 15 minutes before the tariff change.  The tariff is higher before the change.  The server allocates 50K with a validity time of 30 minutes, say.

The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards).  This is rated at that time and some of the monetary reservation is returned to the subscribers balance.  This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported.

Example 2: new mechanism.

The client still wants a quota to send data over GPRS.  The server allocates 25K at the expensive rate and 25K at the cheap rate.  (That's already two rating events in the billing system).  Validity time again 30 minutes.

I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS).

Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted.  Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K.  When the client next returns it will reports the usage in these categories, which will again have to be rated.


So in example one, there are three rating events and the exchange of two Diameter command pairs.  In example two there are between six and eight rating events and the exchange of three Diameter command pairs.  Even in the best case with your method I believe there will be four rating events.

I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it.

Regards,

John




"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 18:32

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism



Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification.

With that in mind, here is the updated proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 5.0, 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

Requested changes:

- Section 5, last paragraph:

FROM:
  The Diameter credit-control server and client may optionally support a
  tariff change mechanism. The Diameter credit-control server may
  include a Tariff-Time-Change AVP in the answer message. Note that the
  granted units should be allocated based on the worst-case scenario in
  case of forthcoming tariff change, so that the overall reported used
  units would never exceed the credit reservation.  
  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. In case some units straddled the tariff
  change, the credit-control client SHOULD itemize those units as well.

TO:
  The Diameter credit-control server and client may optionally support a
  tariff change mechanism. The Diameter credit-control server may
  include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
  two quota allocations in the answer message. One of the granted units is
  allocated to be used before the potential tariff change while the
  second granted units are used after a tariff change. Both granted unit
  quotas MUST contain the same Service-Identifier and Rating-Group values.
  This dual quota mechanism ensures that the overall reported used
  units would never exceed the credit reservation.  
  The Diameter credit-control client reports both the used units before
  and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
  The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
  present. It instructs the client when the resources in the Granted-Service-
  Unit AVP should be used.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
  the server MUST include two separate Granted-Service-Unit AVPs (for the
  same Service-Identifier and/or Rating-Group when either the Service-
  Identifier or Rating-Group AVP is included). One of the Granted-Service-
  Units resources are used before a tariff change occurs, while the other
  is to be used after the tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
  The Granted-Service-Unit AVP has the following ABNF grammar:  
           
        Granted-Service-Unit ::= < AVP Header: 431 >
                                 [ Tariff-Time-Change ]  
                                 [ CC-Time ]
                                 [ CC-Money ]  
                                 [ CC-Total-Octets ]
                                 [ CC-Input-Octets ]
                                 [ CC-Output-Octets ]
                                 [ CC-Service-Specific-Units ]
                                *[ Service-Identifier ]
                                 [ Rating-Group ]
TO:
  The Granted-Service-Unit AVP has the following ABNF grammar:  
           
        Granted-Service-Unit ::= < AVP Header: 431 >
                                 [ Tariff-Time-Change ]  
                                 [Tariff-Change-Usage ]
                                 [ CC-Time ]
                                 [ CC-Money ]  
                                 [ CC-Total-Octets ]
                                 [ CC-Input-Octets ]
                                 [ CC-Output-Octets ]
                                 [ CC-Service-Specific-Units ]
                                *[ Service-Identifier ]
                                 [ Rating-Group ]

- end of changes

Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards.

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change.

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>
02/02/2004 17:11
       
       To:        "'marco.stura@nokia.com'" <marco.stura@nokia.com>
       cc:        aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com
       Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Marco, All,
 
Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.
 
I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?
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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I guess we need the
 input from some of some data OCS vendors. Interestingly,
 3GPP went with the new proposal for IMS in Release 5 -
 this was a Diameter protocol.
 
3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.
 
However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.
 
Thank you
Marco
 
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,
Thanks for the reply. I have added some comments below.
Best Regards,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
 input from some of some data OCS vendors. Interestingly,
 3GPP went with the new proposal for IMS in Release 5 -
 this was a Diameter protocol.
Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
 existing mechanism. Except that in the existing mechanism,
 since only one allocation can actually be given, the OCS
 must make the allocation based upon the worst case scenario
 and provide quota in small enough amounts so that the usage
 at a potentially higher cost can be covered by the users
 account. In other words the OCS has to make decisions up
 front that it can then only really reconcile after the usage.
If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
 quota to allocate because it knows how much is available in the
 users account because it has already allocated the "before"
 quota. It now has the power to allocate as much or as little
 "after" quota as it sees fit - smaller chunks to avoid credit
 fragmentation - but this is also a function of how long before
 a tariff change that the quota is requested. I.e. 30 seconds
 before a TC, it can allocate more to the "after" quota. However,
 if the request is being made 30 minutes before a TC, then it
 would allocate less to the "after" quota.
If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
 it was to replace the existing scheme. I think we all agree
 that 2 parallel mechanisms would be best to avoid. It will
 make it more difficult for OCS vendors to implement.
John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,
John.



"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
     
      To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
      cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
      Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Thanks for the reply John,
 
Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.
Hi Chris,
The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,
John.


"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
     To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
     cc:        
     Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.


All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.
TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.
 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
     Granted-Service-Unit ::= < AVP Header: 431 >
                              [ Tariff-Time-Change ]  
                              [ CC-Time ]
                              [ CC-Money ]  
                              [ CC-Total-Octets ]
                              [ CC-Input-Octets ]
                              [ CC-Output-Octets ]
                              [ CC-Service-Specific-Units ]
                             *[ Service-Identifier ]
                              [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
     Granted-Service-Unit ::= < AVP Header: 431 >
                              [ Tariff-Time-Change ]  
                              [Tariff-Change-Usage ]
                              [ CC-Time ]
                              [ CC-Money ]  
                              [ CC-Total-Octets ]
                              [ CC-Input-Octets ]
                              [ CC-Output-Octets ]
                              [ CC-Service-Specific-Units ]
                             *[ Service-Identifier ]
                              [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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.  
 
TO:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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 optionally enabled by the server for a
Diameter credit control session or sub-session.
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
defines whether units are used before, after or straddled tariff
change when a tariff change has occurred during the reporting period.
Omission of this AVP means that no tariff change has been occurred.
 
Tariff-Change-Usage can be one of the following.
 
UNIT_BEFORE_TARIFF_CHANGE                                  0
 
 The used units contains the amount of the units before 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.
 
UNIT_INDETERMINATE                                         2
 
 The used units contains the amount of units that straddle the
 tariff change (e.g. the metering process reports to the credit-
 control client in blocks of n octets and one block straddled the
 tariff change).
TO:    
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
 When present in the Granted-Service-Units AVP, this AVP defines whether
units are allocated to be used before or after a tariff change event.
 When present in the Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during the reporting
period.
 Omission of this AVP means that no tariff change is to be reported and/or
none has occurred.
 
Tariff-Change-Usage can be one of the following.
 
UNIT_BEFORE_TARIFF_CHANGE                                  0
 
 When present in the Granted-Service-Units AVP, this value indicates
 the amount of the units allocated for use before a tariff change
 occurs.
   When present in the Reported-Service-Units AVP, this value indicates
 the amount of resource units used before a tariff change had occurred.
 
UNIT_AFTER_TARIFF_CHANGE                                   1
 
 When present in the Granted-Service-Units AVP, this value indicates
 the amount of the units allocated for use after a tariff change
 occurs.
   When present in the Reported-Service-Units AVP, this value indicates
 the amount of resource units used after tariff change had occurred.
 
- end of changes
Best Regards,
Chris Richards.
******************************************************************************
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
******************************************************************************
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

------_=_NextPart_001_01C3E9C6.FEFB4A86-- From owner-aaa-wg@merit.edu Tue Feb 3 00:22:22 2004 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 AAA07744 for ; Tue, 3 Feb 2004 00:22:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 26FB091255; Tue, 3 Feb 2004 00:22:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEB7D91257; Tue, 3 Feb 2004 00:22: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 44B6591255 for ; Tue, 3 Feb 2004 00:22:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21F9B5DE4C; Tue, 3 Feb 2004 00:22:03 -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 B0A4B5DE08 for ; Tue, 3 Feb 2004 00:22: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 i135Lu225552 for ; Tue, 3 Feb 2004 07:21:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 07:21:54 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 07:21:53 +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_01C3EA15.A2119464" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Tue, 3 Feb 2004 07:21:53 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPpuugoGjORdqyRSsyCrlk71nx0MgAWrFHw From: To: , Cc: , X-OriginalArrivalTime: 03 Feb 2004 05:21:53.0290 (UTC) FILETIME=[A231EEA0:01C3EA15] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EA15.A2119464 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I updated issue 18 accordingly. =20 John -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 02 February, 2004 20:32 To: 'John.Prudhoe@vodafone.com' Cc: aaa-wg@merit.edu; Loughney John (Nokia-NRC/Helsinki); Stura Marco = (Nokia-NET/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John,=20 Thanks for the explanation.=20 Time units then are not such a big issue for TC - the only limitation = being that when allocating quotas in time, there is no way to tell what = events or bytes were used when during the quota usage. E.g. the user = pays the operator based upon time, but a third party content provider = pays the operator based upon bytes/events used by the user at a = particular time. Perhaps that's not a big deal and there are ways around = it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue = either (Although, as an operator, I'd have to disagree!) - it is a = limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:-=20 Description of issue: Tariff Change=20 Submitter name: Chris Richards, Tim Roberts=20 Date first submitted: 29.01.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-02.txt=20 Comment type: T=20 Priority: ['S' Must fix | '1' Should fix | '2' May fix ]=20 Sections: 5.0, 8.16=20 Rationale/Explanation of issues:=20 The current draft implements a tariff time change capability by allowing = the Used-Service-Units to report back the used resources before and = after a tariff change. However, the resources supplied by the DCC server = are given in a single Granted-Service-Units AVP. However, using this = mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the = basis of which will be more expensive before or after consumption (As = acknowledged in section 5 of the draft). This is particularly = inconvenient when the model changes e.g. some bundled minutes after the = duration, or rates change to a minimum of x or any other model. As a = result, either the server will have to allocate smaller quotas resulting = in increased quota activity and possibly impacted subscriber experience, = or it will have to reserve a larger amount of credit exacerbating credit = fragmentation concerns. Requested changes:=20 - Section 5, last paragraph:=20 FROM:=20 The Diameter credit-control server and client may optionally support = a=20 tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message. Note that the = granted units should be allocated based on the worst-case scenario in = case of forthcoming tariff change, so that the overall reported used=20 units would never exceed the credit reservation. =20 When the Diameter credit-control client reports the used units and a=20 tariff change has occurred during the reporting period then the=20 Diameter credit-control client SHOULD itemize the units used before=20 and after the tariff change. In case some units straddled the tariff=20 change, the credit-control client SHOULD itemize those units as well. = TO:=20 The Diameter credit-control server and client may optionally support = a=20 tariff change mechanism. The Diameter credit-control server may=20 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in=20 two quota allocations in the answer message. One of the granted units = is=20 allocated to be used before the potential tariff change while the=20 second granted units are used after a tariff change. Both granted = unit=20 quotas MUST contain the same Service-Identifier and Rating-Group = values.=20 This dual quota mechanism ensures that the overall reported used=20 units would never exceed the credit reservation. =20 The Diameter credit-control client reports both the used units before = and after the tariff change.=20 - Section 8.16, new paragraphs:=20 NEW:=20 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change = AVP is=20 present. It instructs the client when the resources in the = Granted-Service-=20 Unit AVP should be used.=20 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are = present,=20 the server MUST include two separate Granted-Service-Unit AVPs (for = the=20 same Service-Identifier and/or Rating-Group when either the Service-=20 Identifier or Rating-Group AVP is included). One of the = Granted-Service-=20 Units resources are used before a tariff change occurs, while the = other=20 is to be used after the tariff change has occurred.=20 - Section 8.16, last paragraph:=20 FROM:=20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=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 TO:=20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] =20 [Tariff-Change-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 - end of changes=20 Best Regards,=20 Chris.=20 -----Original Message-----=20 From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com]=20 Sent: Monday, February 02, 2004 11:24 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: aaa-wg@merit.edu; john.loughney@nokia.com; = John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Chris,=20 My reasoning behind this is that time based quotas are consumed at a = regular rate (60 seconds per minute to be exact). So imagine that the = rating engine allocates 300 seconds at a time 130 seconds before the = tariff time change. At that point it already knows that 130seconds will = be consumed at the before rate and 170 seconds will be consumed at the = rate afterwards.=20 The client only knows it has been given 300s not how much it costs and = it need never know about the tariff time change. If the session = continues, the client will come back at the end of the 300s and not at = the time of the tariff change.=20 If the session ends after, say, 90s the rating engine knows that has all = been consumed at the before rate. If it ends after 140seconds, the = rating engine knows it can be split into 130s at the before rate and 10s = at the after rate. In neither of these circumstances does the client = need to know about the tariff time change nor does it need to return to = the server at the time of the tariff change.=20 I hope this explains it.=20 Regards,=20 John.=20 "Christopher Richards" =20 02/02/2004 17:11=20 =20 To: "'marco.stura@nokia.com'" =20 cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, = john.loughney@nokia.com=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism=20 Hi Marco, All,=20 =20 Agreed, no need to talk 3GPP or any specific standards organisation = other than IETF here.=20 =20 I'm interested in your statement that time based quotas have no = interaction between the client/server:=20 But for time based services there is no need for any interaction between = server and client as=20 also stated by John P .=20 Could you explain your reasoning?=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: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Monday, February 02, 2004 10:50 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com = Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 [CR] That's OK for voice traffic. I guess we need the=20 input from some of some data OCS vendors. Interestingly,=20 3GPP went with the new proposal for IMS in Release 5 -=20 this was a Diameter protocol.=20 =20 3GPP uses Diameter DCC in the context of IMS online charging (TS = 32.225), the mechanism=20 of allocating quotas before and after was proposed there for time based = services sometime ago.=20 But for time based services there is no need for any interaction between = server and client as=20 also stated by John P. Interestingly, there are couple of pending = Change Requests against the=20 concerned IMS Release 5 TS to remove the mechanism, so apparently not = all in the 3GPP community=20 are of the same opinion. So the statement that "3GPP went with the new = proposal etc." is rather=20 inaccurate.=20 =20 However, I think the AAA mailing list is not the appropriate place to = discuss 3GPP specific=20 issues.=20 =20 Thank you=20 Marco=20 =20 =20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf = Of ext Christopher Richards=20 Sent: 02 February, 2004 18:07=20 To: 'Leena Mattila (TU/LMF)'=20 Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John = (Nokia-NRC/Helsinki)=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Leena,=20 Thanks for the reply. I have added some comments below.=20 Best Regards,=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: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com]=20 Sent: Monday, February 02, 2004 6:10 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; = 'john.loughney@nokia.com'=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Chris,=20 the way it is proposed in the draft-02 is similar as currently = implemented in the IN/CAMEL systems and we are not aware of any problem = associated with it, it just works nicely.=20 [CR] That's OK for voice traffic. I guess we need the=20 input from some of some data OCS vendors. Interestingly,=20 3GPP went with the new proposal for IMS in Release 5 -=20 this was a Diameter protocol.=20 Concerning the proposed mechanism it seems the server would need to = allocate credit both before and after the tariff change.=20 [CR] Yes. But this is effectively the same for the=20 existing mechanism. Except that in the existing mechanism,=20 since only one allocation can actually be given, the OCS=20 must make the allocation based upon the worst case scenario=20 and provide quota in small enough amounts so that the usage=20 at a potentially higher cost can be covered by the users=20 account. In other words the OCS has to make decisions up=20 front that it can then only really reconcile after the usage.=20 If the server wants to minimize the likelihood of higher=20 re-authorization traffic load, it would have to allocate bigger credit = in both categories since it doesn't know whether more units will be = consumed before or after.=20 [CR] Not at all. It can make a decision about how much "after"=20 quota to allocate because it knows how much is available in the=20 users account because it has already allocated the "before"=20 quota. It now has the power to allocate as much or as little=20 "after" quota as it sees fit - smaller chunks to avoid credit=20 fragmentation - but this is also a function of how long before=20 a tariff change that the quota is requested. I.e. 30 seconds=20 before a TC, it can allocate more to the "after" quota. However,=20 if the request is being made 30 minutes before a TC, then it=20 would allocate less to the "after" quota.=20 If the server wants to minimize the credit fragmentation would need to = allocate smaller credit, at the expences of higher re-autht traffic = load. So, I fully agree with John P. in that the proposed mechanism = defeats both the objectives of trying to reduce credit fragmentation and = trying to minimize the re-auth traffic load.=20 [CR] The intention of my proposal was not to make it optional:=20 it was to replace the existing scheme. I think we all agree=20 that 2 parallel mechanisms would be best to avoid. It will=20 make it more difficult for OCS vendors to implement.=20 John Loughney wrote:=20 >I am quite worried about additional optional mechanisms. Already the=20 >specification is quite complicated and I worry that additional optional = >mechansisms will create extremely complicated mechanisms.=20 >=20 >I favor simplication at this point, so I'd hope we could discuss the=20 >options and focus on a single mechansim.=20 >=20 I agree with this, we shouldn't introduce more optionality. We should = support only one way of doing tariff switch (tsw itself is optional = already, optionality within one option is not desirable).=20 BR,=20 Leena=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf = Of John.Prudhoe@vodafone.com=20 Sent: 30. tammikuuta 2004 19:08=20 To: Christopher Richards=20 Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Chris,=20 I've no objection myself in principle to your mechanism of allocating = quotas together for both units before and units after the tariff change. = As long as it is all optional.=20 The question is: how likely is the client to run out of the before units = before the time of the tariff change. This would trigger an = re-authorisation even though the units after are unused. To avoid this, = the server would have to allocated a higher quota in that category. = Alternatively, if the user did little before the tariff change and lots = after they would be likely to consume the units after much more quickly. = Therefore, I suspect that this mechanism won't reduce the volume of = authorisation traffic in practice unless larger quotas are allocated, = which I think defeats your objective of trying to reduce credit = fragmentation.=20 Regards,=20 John.=20 "Christopher Richards" =20 30/01/2004 16:27=20 =20 To: "'John.Prudhoe@vodafone.com'" = =20 cc: "'aaa-wg@merit.edu'" , = owner-aaa-wg@merit.edu=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism.=20 Thanks for the reply John,=20 =20 Since there are implementations that can generate straddling usage = counts today, I don't have a problem leaving this value in the = Tariff-Change-Usage AVP.=20 However, I still think that the current proposed mechanism in the draft = should address it's shortcomings as I described in the Issue email I = sent. Will the change proposal be accepted as an issue to discuss? If = so, should I resubmit the issue with the change described above?=20 Best Regards,=20 Chris.=20 -----Original Message-----=20 From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com]=20 Sent: Friday, January 30, 2004 10:18 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu=20 Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.=20 Hi Chris,=20 The option to specify units straddlling a tariff time change was = suggested by us as we have an implemented system that behaves like this. = There is a fundamental difference between tariffs changing for a service = that is consumed at a regular rate (i.e. time based such as = circuit-switched calls) and one that is consumed at an irregular rate = (such as GPRS or 3G data services).=20 For time-based services there is no need to report the = Tariff-Time-Change AVP to the client. It doesn't even need to know that = the tariff has changed. When the server knows that there is tariff = change due it can take this into account when rating the granted units. = There is no need for any additional Diameter traffic for time-based = services when there is a tariff change.=20 Regards,=20 John.=20 "Christopher Richards" =20 Sent by: owner-aaa-wg@merit.edu=20 30/01/2004 16:09 =20 To: "'aaa-wg@merit.edu'" =20 cc: =20 Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism.=20 All,=20 Please find enclosed issue regarding the current tariff change mechanism = specified in the DCC draft.=20 Best Regards,=20 Chris Richards.=20 Description of issue: Tariff Change=20 Submitter name: Chris Richards, Tim Roberts=20 Date first submitted: 29.01.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-02.txt=20 Comment type: T=20 Priority: ['S' Must fix | '1' Should fix | '2' May fix ]=20 Sections: 8.16, 8.41 and 8.42=20 Rationale/Explanation of issues:=20 The current draft implements a tariff time change capability by allowing = the Used-Service-Units to report back the used resources before and = after a tariff change. However, the resources supplied by the DCC server = are given in a single Granted-Service-Units AVP. However, using this = mechanism has a number of drawbacks and practical issues:=20 1. It is complex for the DCC server since it must reserve credit on the = basis of which will be more expensive before or after consumption (As = acknowledged in section 5 of the draft). This is particularly = inconvenient when the model changes e.g. some bundled minutes after the = duration, or rates change to a minimum of x or any other model. As a = result, either the server will have to allocate smaller quotas resulting = in increased quota activity or it will have to reserve a larger amount = of credit exacerbating credit fragmentation concerns.=20 2. The draft document states that the mechanism is not used when the = resource unit is time. However, in order to perform tariff time changes, = the client will have to re-authorise all quotas for all sessions that = react to the same tariff time change - this will lead to a flood of = messaging and processing on the client and server which will result in = delayed responses and inaccurate time change values.=20 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different = mechanism has been introduced for the Diameter IMS charging application = which avoids the problems stated above - there are no longer used = resources that straddle a tariff change thus removing this indeterminate = charging scenario. It would seem highly desirable to align with this = mechanism so all applications can benefit.=20 Requested changes:=20 - Section 5, last paragraph:=20 FROM:=20 The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message. Note that the=20 granted units should be allocated based on the worst-case scenario in=20 case of forthcoming tariff change, so that the overall reported used=20 units would never exceed the credit reservation. =20 When the Diameter credit-control client reports the used units and a=20 tariff change has occurred during the reporting period then the=20 Diameter credit-control client SHOULD itemize the units used before=20 and after the tariff change. In case some units straddled the tariff=20 change, the credit-control client SHOULD itemize those units as well.=20 TO:=20 The Diameter credit-control server and client may optionally support a=20 tariff change mechanism. The Diameter credit-control server may=20 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in=20 two quota allocations in the answer message. One of the granted units = is=20 allocated to be used before the potential tariff change while the=20 second granted units are used after a tariff change. Both granted unit=20 quotas MUST contain the same Service-Identifier and Rating-Group values. = This dual quota mechanism ensures that the overall reported used=20 units would never exceed the credit reservation. =20 The Diameter credit-control client reports both the used units before=20 and after the tariff change.=20 - Section 8.16, new paragraphs:=20 NEW:=20 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP = is=20 present. It instructs the client when the resources in the = Granted-Service-=20 Unit AVP should be used.=20 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are = present,=20 the server MUST include two separate Granted-Service-Unit AVPs (for the=20 same Service-Identifier and/or Rating-Group when either the Service-=20 Identifier or Rating-Group AVP is included). One of the Granted-Service- = Units resources are used before a tariff change occurs, while the other=20 is to be used after the tariff change has occurred.=20 - Section 8.16, last paragraph:=20 FROM:=20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=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 TO:=20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=20 [ Tariff-Time-Change ] =20 [Tariff-Change-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 - Section 8.41, first and second paragraphs:=20 FROM:=20 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the=20 tariff of the service will be changed.=20 =20 The tariff change mechanism is optional for client and server and it=20 is not used for unit type time, since the server has full control of=20 the time. =20 =20 TO:=20 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and=20 includes the time in seconds since January 1, 1900 00:00 UTC when the=20 tariff of the service will be changed.=20 The tariff change mechanism is optionally enabled by the server for a=20 Diameter credit control session or sub-session.=20 - Section 8.42:=20 FROM:=20 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and=20 defines whether units are used before, after or straddled tariff=20 change when a tariff change has occurred during the reporting period.=20 Omission of this AVP means that no tariff change has been occurred.=20 =20 Tariff-Change-Usage can be one of the following.=20 =20 UNIT_BEFORE_TARIFF_CHANGE 0=20 =20 The used units contains the amount of the units before tariff=20 change, that is units measured from the point when the previous=20 measurement ended to the point when tariff change occurred.=20 =20 UNIT_AFTER_TARIFF_CHANGE 1=20 The used units contains the amount of the units after tariff change=20 has been occurred.=20 =20 UNIT_INDETERMINATE 2=20 =20 The used units contains the amount of units that straddle the=20 tariff change (e.g. the metering process reports to the credit-=20 control client in blocks of n octets and one block straddled the=20 tariff change).=20 TO: =20 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.=20 When present in the Granted-Service-Units AVP, this AVP defines = whether=20 units are allocated to be used before or after a tariff change event.=20 When present in the Used-Service-Units AVP, this AVP identified what=20 resources where used before or after a tariff change during the = reporting=20 period.=20 Omission of this AVP means that no tariff change is to be reported = and/or=20 none has occurred.=20 =20 Tariff-Change-Usage can be one of the following.=20 =20 UNIT_BEFORE_TARIFF_CHANGE 0=20 =20 When present in the Granted-Service-Units AVP, this value indicates=20 the amount of the units allocated for use before a tariff change=20 occurs.=20 When present in the Reported-Service-Units AVP, this value indicates = the amount of resource units used before a tariff change had occurred. = =20 UNIT_AFTER_TARIFF_CHANGE 1=20 =20 When present in the Granted-Service-Units AVP, this value indicates=20 the amount of the units allocated for use after a tariff change=20 occurs.=20 When present in the Reported-Service-Units AVP, this value indicates = the amount of resource units used after tariff change had occurred.=20 =20 - end of changes=20 Best Regards,=20 Chris Richards.=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=20 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=20 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=20 (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.=20 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=20 *************************************************************************= *****=20 This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you.=20 E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof.=20 ------_=_NextPart_001_01C3EA15.A2119464 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
I=20 updated issue 18 accordingly.
 
John
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 02 February, 2004=20 20:32
To: 'John.Prudhoe@vodafone.com'
Cc:=20 aaa-wg@merit.edu; Loughney John (Nokia-NRC/Helsinki); Stura Marco=20 (Nokia-NET/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: = Tariff=20 Change mechanism

Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - = the only=20 limitation being that when allocating quotas in time, there is no way = to tell=20 what events or bytes were used when during the quota usage. E.g. the = user pays=20 the operator based upon time, but a third party content provider pays = the=20 operator based upon bytes/events used by the user at a particular = time.=20 Perhaps that's not a big deal and there are ways around it (Allocate = quota in=20 bytes/events always).

It also appears that resource usage straddling a TC = is not an=20 issue either (Although, as an operator, I'd have to disagree!) - it is = a=20 limitation due to implementation rather than due to the=20 specification.

With that in mind, here is the updated = proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:=20
Document: = draft-ietf-aaa-diameter-cc-02.txt=20
Comment type: T
Priority: = ['S' Must=20 fix | '1' Should fix | '2' May fix ]
Sections: 5.0,=20 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change = capability=20 by allowing the Used-Service-Units to report back the used resources = before=20 and after a tariff change. However, the resources supplied by the DCC = server=20 are given in a single Granted-Service-Units AVP. However, using this = mechanism=20 has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must = reserve=20 credit on the basis of which will be more expensive before or after=20 consumption (As acknowledged in section 5 of the draft). This is = particularly=20 inconvenient when the model changes e.g. some bundled minutes after = the=20 duration, or rates change to a minimum of x or any other model. As a = result,=20 either the server will have to allocate smaller quotas resulting in = increased=20 quota activity and possibly impacted subscriber experience, or it will = have to=20 reserve a larger amount of credit exacerbating credit fragmentation=20 concerns.


Requested changes:

- Section 5, last paragraph:

FROM:
   The = Diameter=20 credit-control server and client may optionally support a =
   tariff change mechanism. The Diameter = credit-control=20 server may
   include a = Tariff-Time-Change=20 AVP in the answer message. Note that the
  =20 granted units should be allocated based on the worst-case scenario in=20
   case of forthcoming tariff = change, so=20 that the overall reported used
   = units=20 would never exceed the credit reservation. 
   When the Diameter credit-control client reports = the used=20 units and a
   tariff change has = occurred=20 during the reporting period then the
  =20 Diameter credit-control client SHOULD itemize the units used before=20
   and after the tariff change. In = case some=20 units straddled the tariff
   = change, the=20 credit-control client SHOULD itemize those units as well.

TO:
   The = Diameter=20 credit-control server and client may optionally support a =
   tariff change mechanism. The Diameter = credit-control=20 server may
   include both the=20 Tariff-Time-Change and Tariff-Change-Usage AVPs in
   two quota allocations in the answer message. One = of the=20 granted units is
   allocated to = be used=20 before the potential tariff change while the
   second granted units are used after a tariff = change. Both=20 granted unit
   quotas MUST = contain the same=20 Service-Identifier and Rating-Group values.
   This dual quota mechanism ensures that the = overall=20 reported used
   units would never = exceed=20 the credit reservation. 
   = The=20 Diameter credit-control client reports both the used units before=20
   and after the tariff = change.

- Section 8.16, new paragraphs:

NEW:
   The=20 Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP = is=20
   present. It instructs the client when = the=20 resources in the Granted-Service-
   Unit=20 AVP should be used.

   When both the Tariff-Time-Change and=20 Tariff-Change-Usage AVPs are present,
   the=20 server MUST include two separate Granted-Service-Unit AVPs (for = the=20
   same Service-Identifier and/or = Rating-Group when=20 either the Service-
   Identifier = or=20 Rating-Group AVP is included). One of the Granted-Service- =
   Units resources are used before a tariff change = occurs,=20 while the other
   is to be used = after the=20 tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
   The=20 Granted-Service-Unit AVP has the following ABNF grammar:  =20
          &nbs= p; =20
        =20 Granted-Service-Unit ::=3D < AVP Header: 431 >
          &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 ]
TO:
   The Granted-Service-Unit AVP has the following = ABNF=20 grammar:  
          &nbs= p; =20
        =20 Granted-Service-Unit ::=3D < AVP Header: 431 >
          &nbs= p;            = ;          =20 [ Tariff-Time-Change ]  
          &nbs= p;            = ;          =20 [Tariff-Change-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 ]


- end of changes


Best Regards,
Chris. =
-----Original Message-----
From:=20 John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.co= m]=20
Sent: Monday, February 02, 2004 11:24 = AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: aaa-wg@merit.edu; john.loughney@nokia.com;=20 John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism=20



Hi Chris,

My reasoning behind this is that time based quotas = are=20 consumed at a regular rate (60 seconds per minute to be exact).  = So=20 imagine that the rating engine allocates 300 seconds at a time 130 = seconds=20 before the tariff time change.  At that point it already knows = that=20 130seconds will be consumed at the before rate and 170 seconds will be = consumed at the rate afterwards.

The client only knows it has been given 300s not how = much it=20 costs and it need never know about the tariff time change.  If = the=20 session continues, the client will come back at the end of the 300s = and not at=20 the time of the tariff change.

If the session ends after, say, 90s the rating = engine knows=20 that has all been consumed at the before rate.  If it ends after=20 140seconds, the rating engine knows it can be split into 130s at the = before=20 rate and 10s at the after rate.  In neither of these = circumstances does=20 the client need to know about the tariff time change nor does it need = to=20 return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.





"Christopher Richards" = <crich@nortelnetworks.com>=20
02/02/2004 17:11
       
       =20 To:        = "'marco.stura@nokia.com'"=20 <marco.stura@nokia.com>
       =20 cc:        aaa-wg@merit.edu,=20 John.Prudhoe@vodafone.com, john.loughney@nokia.com
       =20 Subject:        RE: [AAA-WG]: DCC: = Issue:=20 Tariff Change mechanism



Hi Marco, All,
  =
Agreed, no need to talk 3GPP or any specific standards = organisation=20 other than IETF here.
  =
I'm interested in your statement that time based quotas have = no=20 interaction between the client/server:
But = for time=20 based services there is no need for any interaction between server and = client=20 as
also stated by John P .
Could you explain your reasoning?
Cheers,=20
Chris.
Shasta = Wireless=20 Development
Nortel Networks
Telephone:
+1 972 684 3281 =
ESN 444 3281
-----Original = Message-----=20
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Monday, February 02, 2004 10:50 = AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com;=20 john.loughney@nokia.com
Subject: RE: = [AAA-WG]: DCC:=20 Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I = guess we need=20 the
  input from some of some data OCS = vendors.=20 Interestingly,
  3GPP went with the new = proposal=20 for IMS in Release 5 -
  this was a = Diameter=20 protocol.
 
3GPP uses=20 Diameter DCC in the context of IMS online charging (TS 32.225), the = mechanism=20
of allocating quotas before and after was = proposed=20 there for time based services sometime ago.
But for=20 time based services there is no need for any interaction between = server and=20 client as
also stated by John P.  = Interestingly,=20 there are couple of pending Change Requests against the =
concerned IMS Release 5 TS to remove the mechanism, so = apparently not=20 all in the 3GPP community
are of the same = opinion. So=20 the statement that "3GPP went  with the new proposal etc." is = rather=20
inaccurate.
  =
However, I think the AAA mailing list is not = the=20 appropriate place to discuss 3GPP specific
issues.=20
 
Thank you=20
Marco
  =
 
 -----Original = Message-----=20
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of ext Christopher Richards
Sent: 02 = February,=20 2004 18:07
To: 'Leena Mattila = (TU/LMF)'=20
Cc: 'aaa-wg@merit.edu'; = 'John.Prudhoe@vodafone.com'; Loughney=20 John (Nokia-NRC/Helsinki)
Subject: RE: = [AAA-WG]: DCC:=20 Issue: Tariff Change mechanism

Hi Leena,
Thanks for the = reply. I have=20 added some comments below.
Best Regards,=20
Chris.
Shasta = Wireless=20 Development
Nortel Networks
Telephone:
+1 972 684 3281 =
ESN 444 3281
-----Original = Message-----=20
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.= com]=20
Sent: Monday, February 02, 2004 6:10 AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH]=20
Cc: 'aaa-wg@merit.edu'; = 'John.Prudhoe@vodafone.com';=20 'john.loughney@nokia.com'
Subject: RE: = [AAA-WG]: DCC:=20 Issue: Tariff Change mechanism
Hi Chris,=20
the way it is proposed in the draft-02 is = similar as=20 currently implemented in the IN/CAMEL systems and we are not aware of = any=20 problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I = guess we need=20 the
  input from some of some data OCS = vendors.=20 Interestingly,
  3GPP went with the new = proposal=20 for IMS in Release 5 -
  this was a = Diameter=20 protocol.
Concerning the proposed mechanism = it seems=20 the server would need to allocate credit both before and after the = tariff=20 change.

   [CR] Yes. But this is effectively the = same for=20 the
  existing mechanism. Except that = in the=20 existing mechanism,
  since only one = allocation=20 can actually be given, the OCS
  must = make the=20 allocation based upon the worst case scenario
 =20 and provide quota in small enough amounts so that the usage =
  at a potentially higher cost can be covered by the = users=20
  account. In other words the OCS has = to make=20 decisions up
  front that it can then = only really=20 reconcile after the usage.
 If the = server wants=20 to minimize the likelihood of higher
re-authorization=20 traffic load, it would have to allocate bigger credit in both = categories since=20 it doesn't know whether more units will be consumed before or after.=20

   [CR] Not at all. It can make a decision = about how=20 much "after"
  quota to allocate = because it knows=20 how much is available in the
  users = account=20 because it has already allocated the "before"
 =20 quota. It now has the power to allocate as much or as little =
  "after" quota as it sees fit - smaller chunks to avoid = credit=20
  fragmentation - but this is also a = function of=20 how long before
  a tariff change that = the quota=20 is requested. I.e. 30 seconds
  before = a TC, it=20 can allocate more to the "after" quota. However,
  if the request is being made 30 minutes before a TC, = then it=20
  would allocate less to the "after" = quota.=20
If the server wants to minimize the credit=20 fragmentation would need to allocate smaller credit, at the expences = of higher=20 re-autht traffic load. So, I fully agree with John P. in that the = proposed=20 mechanism defeats both the objectives of trying to reduce credit = fragmentation=20 and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was = not to make=20 it optional:
  it was to replace the = existing=20 scheme. I think we all agree
  that 2 = parallel=20 mechanisms would be best to avoid. It will
  make=20 it more difficult for OCS vendors to implement.
John=20 Loughney wrote:
>I am quite worried about = additional optional mechanisms.  Already the
>specification is quite complicated and I worry that = additional=20 optional
>mechansisms will create = extremely=20 complicated mechanisms.
> =
>I favor simplication at this point, so I'd hope we could = discuss=20 the
>options and focus on a single = mechansim.=20
>
I agree with = this, we=20 shouldn't introduce more optionality. We should support only one way = of doing=20 tariff switch (tsw itself is optional already, optionality within one = option=20 is not desirable).

BR,
Leena
-----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of John.Prudhoe@vodafone.com
Sent: = 30.=20 tammikuuta 2004 19:08
To: Christopher = Richards=20
Cc: 'aaa-wg@merit.edu'; = owner-aaa-wg@merit.edu=20
Subject: RE: [AAA-WG]: DCC: Issue: Tariff = Change=20 mechanism
Hi Chris,
I've no=20 objection myself in principle to your mechanism of allocating quotas = together=20 for both units before and units after the tariff change.  As long = as it=20 is all optional.

The question is: how likely is the client to run out = of the=20 before units before the time of the tariff change.  This would = trigger an=20 re-authorisation even though the units after are unused.  To = avoid this,=20 the server would have to allocated a higher quota in that = category. =20 Alternatively, if the user did little before the tariff change and = lots after=20 they would be likely to consume the units after much more quickly. =


Therefore, I suspect that = this=20 mechanism won't reduce the volume of authorisation traffic in practice = unless=20 larger quotas are allocated, which I think defeats your objective of = trying to=20 reduce credit fragmentation.

Regards,
John. =




"Christopher Richards" = <crich@nortelnetworks.com>=20
30/01/2004 16:27
      
      =20 To:        = "'John.Prudhoe@vodafone.com'"=20 <John.Prudhoe@vodafone.com>
      =20 cc:        "'aaa-wg@merit.edu'"=20 <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
      =20 Subject:        RE: [AAA-WG]: DCC: = Issue:=20 Tariff Change mechanism.


Thanks for the reply John,
 
Since there are = implementations that can=20 generate straddling usage counts today, I don't have a problem leaving = this=20 value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed = mechanism in=20 the draft should address it's shortcomings as I described in the Issue = email I=20 sent. Will the change proposal be accepted as an issue to discuss? If = so,=20 should I resubmit the issue with the change described above? =


Best Regards, =
Chris.
-----Original Message-----=20
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.co= m]=20
Sent: Friday, January 30, 2004 10:18 AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH]=20
Cc: 'aaa-wg@merit.edu'; = owner-aaa-wg@merit.edu=20
Subject: Re: [AAA-WG]: DCC: Issue: Tariff = Change=20 mechanism.
Hi Chris,
The=20 option to specify units straddlling a tariff time change was suggested = by us=20 as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs = changing for=20 a service that is consumed at a regular rate (i.e. time based such as=20 circuit-switched calls) and one that is consumed at an irregular rate = (such as=20 GPRS or 3G data services).

For time-based services there is no need to report = the=20 Tariff-Time-Change AVP to the client.  It doesn't even need to = know that=20 the tariff has changed.  When the server knows that there is = tariff=20 change due it can take this into account when rating the granted = units. =20 There is no need for any additional Diameter traffic for time-based = services=20 when there is a tariff change.

Regards,
John. =



"Christopher Richards" = <crich@nortelnetworks.com>=20
Sent by: owner-aaa-wg@merit.edu =
30/01/2004 = 16:09        =20
     =20 To:        "'aaa-wg@merit.edu'"=20 <aaa-wg@merit.edu>
     =20 cc:        
     =20 Subject:        [AAA-WG]: DCC: = Issue:=20 Tariff Change mechanism.



All,
Please find enclosed = issue=20 regarding the current tariff change mechanism specified in the DCC = draft.=20
Best Regards,
Chris Richards.=20
Description of issue: Tariff Change =
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:=20
Document: draft-ietf-aaa-diameter-cc-02.txt=20
Comment type: T
Priority: ['S'=20 Must fix | '1' Should fix | '2' May fix ]
Sections:=20 8.16, 8.41 and 8.42
Rationale/Explanation of = issues:=20
The current draft implements a tariff time = change=20 capability by allowing the Used-Service-Units to report back the used=20 resources before and after a tariff change. However, the resources = supplied by=20 the DCC server are given in a single Granted-Service-Units AVP. = However, using=20 this mechanism has a number of drawbacks and practical issues: =

1. It is complex for the DCC server since it must = reserve=20 credit on the basis of which will be more expensive before or after=20 consumption (As acknowledged in section 5 of the draft). This is = particularly=20 inconvenient when the model changes e.g. some bundled minutes after = the=20 duration, or rates change to a minimum of x or any other model. As a = result,=20 either the server will have to allocate smaller quotas resulting in = increased=20 quota activity or it will have to reserve a larger amount of credit=20 exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is = not used=20 when the resource unit is time. However, in order to perform tariff = time=20 changes, the client will have to re-authorise all quotas for all = sessions that=20 react to the same tariff time change - this will lead to a flood of = messaging=20 and processing on the client and server which will result in delayed = responses=20 and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), = a=20 different mechanism has been introduced for the Diameter IMS charging=20 application which avoids the problems stated above - there are no = longer used=20 resources that straddle a tariff change thus removing this = indeterminate=20 charging scenario. It would seem highly desirable to align with this = mechanism=20 so all applications can benefit.

Requested changes:
- = Section 5, last=20 paragraph:
FROM:
The Diameter=20 credit-control server and client may optionally support a =
tariff change mechanism. The Diameter credit-control server = may=20
include a Tariff-Time-Change AVP in the = answer=20 message. Note that the
granted units should = be=20 allocated based on the worst-case scenario in
case of=20 forthcoming tariff change, so that the overall reported used =
units would never exceed the credit reservation.  =
When the Diameter credit-control client reports the used = units and a=20
tariff change has occurred during the = reporting period=20 then the
Diameter credit-control client = SHOULD itemize=20 the units used before
and after the tariff = change. In=20 case some units straddled the tariff
change, = the=20 credit-control client SHOULD itemize those units as well. =
TO:
The Diameter credit-control = server and=20 client may optionally support a
tariff = change=20 mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage = AVPs in=20
 two quota allocations in the answer = message. One=20 of the granted units is
allocated to be used = before=20 the potential tariff change while the
second = granted=20 units are used after a tariff change. Both granted unit =
quotas MUST contain the same Service-Identifier and = Rating-Group=20 values.
This dual quota mechanism ensures = that the=20 overall reported used
units would never = exceed the=20 credit reservation. 
The Diameter = credit-control=20 client reports both the used units before
and after=20 the tariff change.
- Section 8.16, new = paragraphs:=20
NEW:
The = Tariff-Change-Usage=20 AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the=20 Granted-Service-
Unit AVP should be used.=20
  When both the Tariff-Time-Change and=20 Tariff-Change-Usage AVPs are present,
the = server MUST=20 include two separate Granted-Service-Unit AVPs (for the =
same Service-Identifier and/or Rating-Group when either the = Service-=20
Identifier or Rating-Group AVP is included). = One of=20 the Granted-Service-
Units resources are = used before a=20 tariff change occurs, while the other
is to = be used=20 after the tariff change has occurred.
- = Section 8.16,=20 last paragraph:
FROM:
The=20 Granted-Service-Unit AVP has the following ABNF grammar:  =20
         =20
      = Granted-Service-Unit=20 ::=3D < AVP Header: 431 >
          &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 ]
TO:
The=20 Granted-Service-Unit AVP has the following ABNF grammar:  =20
         =20
      = Granted-Service-Unit=20 ::=3D < AVP Header: 431 >
          &nbs= p;            = ;       =20 [ Tariff-Time-Change ]  
          &nbs= p;            = ;       =20 [Tariff-Change-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 ]
- Section 8.41, first and = second=20 paragraphs:
FROM:
The=20 Tariff-Time-Change AVP (AVP code 451) is of type Time, and =
includes the time in seconds since January 1, 1900 00:00 UTC = when the=20
tariff of the service will be changed.=20
 
The tariff = change=20 mechanism is optional for client and server and it
is=20 not used for unit type time, since the server has full control of=20
the time. 
 =20
TO:
The = Tariff-Time-Change AVP (AVP=20 code 451) is of type Time, and
includes the = time in=20 seconds since January 1, 1900 00:00 UTC when the
tariff of the service will be changed.
 =20 The tariff change mechanism is optionally enabled by the server for a=20
Diameter credit control session or = sub-session.=20
- Section 8.42:
FROM:=20
The Tariff-Change-Usage AVP (AVP code 452) = is of type=20 Enumerated and
defines whether units are = used before,=20 after or straddled tariff
change when a = tariff change=20 has occurred during the reporting period.
Omission of=20 this AVP means that no tariff change has been occurred. =
 
Tariff-Change-Usage can be = one of the=20 following.
 
 UNIT_BEFORE_TARIFF_CHANGE     &nb= sp;           &nbs= p;            = ;   =20 0
 
  = The used units=20 contains the amount of the units before tariff
 =20 change, that is units measured from the point when the previous=20
  measurement ended to the point when = tariff=20 change occurred.
 
 UNIT_AFTER_TARIFF_CHANGE     &nbs= p;            = ;            =     =20 1
   The used units contains the = amount of=20 the units after tariff change
  has = been=20 occurred.
 
 UNIT_INDETERMINATE      &nbs= p;            = ;            =          =20 2
 
  = The used units=20 contains the amount of units that straddle the
 =20 tariff change (e.g. the metering process reports to the credit-=20
  control client in blocks of n octets = and one=20 block straddled the
  tariff change).=20
TO:   
The=20 Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. =
  When present in the Granted-Service-Units AVP, this = AVP defines=20 whether
units are allocated to be used = before or after=20 a tariff change event.
  When present = in the=20 Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during = the=20 reporting
period.
 =20 Omission of this AVP means that no tariff change is to be reported = and/or=20
none has occurred.
 
Tariff-Change-Usage can be = one of the=20 following.
 
 UNIT_BEFORE_TARIFF_CHANGE     &nb= sp;           &nbs= p;            = ;   =20 0
 
  = When present=20 in the Granted-Service-Units AVP, this value indicates =
  the amount of the units allocated for use before a = tariff change=20
  occurs.
    When present in the Reported-Service-Units = AVP, this=20 value indicates
  the amount of = resource units=20 used before a tariff change had occurred.
 
 UNIT_AFTER_TARIFF_CHANGE     &nbs= p;            = ;            =     =20 1
 
  = When present=20 in the Granted-Service-Units AVP, this value indicates =
  the amount of the units allocated for use after a = tariff change=20
  occurs.
    When present in the Reported-Service-Units = AVP, this=20 value indicates
  the amount of = resource units=20 used after tariff change had occurred.
  =20
- end of changes
Best Regards,=20
Chris Richards.
****************************************************************= **************=20
The content of this e-mail may be privileged = and/or=20 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=20 such
case, you should destroy this message = and kindly=20 notify the
sender and postmaster@vodafone.ie = by reply=20 email. Please
note that in such = circumstances any=20 review, dissemination,
disclosure, = alteration,=20 printing, copying or further transmission of this e-mail and/or any = file=20 transmitted with it is prohibited

and may be unlawful. Please advise us immediately if = you or=20 your employer do not consent to Internet email for messages =

of this kind. The opinions, conclusions and other = information=20
in this message are of the author and shall = be=20 understood as
neither given nor endorsed by = Vodafone=20 Ireland Limited
unless it is otherwise = indicated by an=20 authorised representative
independent of = this message.=20 Internet e-mail is
transmitted over the = public=20 internet over which Vodafone
Ireland Limited = has no=20 control. As such, there is no guarantee that
(i) this=20 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=20
(iv) the contents of this e-mail are = unaltered from=20 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=20 responsibility of
the recipient to ensure = that the=20 message (and attachments)
are safe and = authorised for=20 use in their environment.
Vodafone Ireland = Ltd=20 Directors: Peter Bamford Chairman (UK),
Pauline Best=20 (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy,=20 Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in = Ireland at=20 MountainView, Leopardstown, Dublin 18.

Number 326967 VAT Reg No. IE6346967G =
****************************************************************= **************=20
This communication is confidential and = intended solely=20 for the addressee(s). Any unauthorized review, use, disclosure or = distribution=20 is prohibited. If you believe this message has been sent to you in = error,=20 please notify the sender by replying to this transmission and delete = the=20 message without disclosing it. Thank you.

E-mail including attachments is susceptible to data=20 corruption, interruption, unauthorized amendment, tampering and = viruses, and=20 we only send and receive e-mails on the basis that we are not liable = for any=20 such corruption, interception, amendment, tampering or viruses or any=20 consequences thereof.

------_=_NextPart_001_01C3EA15.A2119464-- From owner-aaa-wg@merit.edu Tue Feb 3 02:23:42 2004 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 CAA25266 for ; Tue, 3 Feb 2004 02:23:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 586689125B; Tue, 3 Feb 2004 02:23:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 281D09125C; Tue, 3 Feb 2004 02:23:24 -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 1EA699125B for ; Tue, 3 Feb 2004 02:23:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9F2A5DEC0; Tue, 3 Feb 2004 02:23:21 -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 BCA0D5DEA2 for ; Tue, 3 Feb 2004 02:23:20 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i137NJ204218 for ; Tue, 3 Feb 2004 09:23:19 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 09:23:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 09:23:14 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 09:23:14 +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_01C3EA26.95ABE9FC" Subject: RE: [AAA-WG]: Issue: DCC: Independent handling of services within a session Date: Tue, 3 Feb 2004 09:23:13 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C836E@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC: Independent handling of services within a session Thread-Index: AcPptr47J5SQBWEaRLKV/onCI+8PbAAb1GfA From: To: Cc: , , , , , , X-OriginalArrivalTime: 03 Feb 2004 07:23:14.0111 (UTC) FILETIME=[95E70CF0:01C3EA26] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EA26.95ABE9FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 >I guess we can work on an updated proposal offline based on your = comments below.=20 =20 Agreed. Once the proposal will be ready we need to update the issues 16 = and 17. =20 Regards Marco ------_=_NextPart_001_01C3EA26.95ABE9FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC: Independent handling of services within = a session
Hi=20 Mark,
 
>I guess we can = work on an=20 updated proposal offline based on your comments below.=20
 
Agreed. Once the proposal will be ready we = need to=20 update the issues 16 and 17.
 
Regards
Marco
= ------_=_NextPart_001_01C3EA26.95ABE9FC-- From owner-aaa-wg@merit.edu Tue Feb 3 03:06:42 2004 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 DAA26644 for ; Tue, 3 Feb 2004 03:06:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7D9691259; Tue, 3 Feb 2004 03:06:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F246491257; Tue, 3 Feb 2004 03:06: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 2228391259 for ; Tue, 3 Feb 2004 03:06:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 336105DEC5; Tue, 3 Feb 2004 03:06:13 -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 2D4695DEC3 for ; Tue, 3 Feb 2004 03:06:11 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1386AYG025464 for ; Tue, 3 Feb 2004 09:06:10 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 09:06:09 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1AZ5GLZG>; Tue, 3 Feb 2004 09:06:35 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Christopher Richards'" Cc: "'aaa-wg@merit.edu'" , "'John.Prudhoe@vodafone.com'" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Tue, 3 Feb 2004 09:05:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EA2C.8602B30C" X-OriginalArrivalTime: 03 Feb 2004 08:06:09.0874 (UTC) FILETIME=[952D4B20:01C3EA2C] 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_01C3EA2C.8602B30C Content-Type: text/plain; charset="iso-8859-1" Hi Chris, we still seem to have some quite big differences in our reasonings. Who said I was talking about voice traffic only? CAMEL is used for data charging, and the method described in the current draft is fully backwards compatible with that. Besides, implementations for that mechanism exist and haven't heard of any problems with that. I strongly disagree with your arguments about better efficiency of this new proposal. Yes, it may cause less signaling in some exeptional cases (as you have illustrated in other mails) but as John P. very well pointed out, your proposal actually increases signaling in most of the cases and involves much more rating rounds. We should not design a protocol to optimize the behavior in some extreme cases with the expense of more complexity and most likely poorer performance in normal cases. So, my vote remains against this (even updated) issue. I do agree with you with that that we should only support one mechanism. But I think that mechanism should be the one described currently in the draft. And as far as I understand that is the opinion of the others involved as well. BR, Leena -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 2. helmikuuta 2004 18:07 To: Leena Mattila (TU/LMF) Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com ] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu ]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com ] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. ****************************************************************************** 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 ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3EA2C.8602B30C Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
 
we still seem to have some quite big differences in our reasonings.
Who said I was talking about voice traffic only? CAMEL is used for data charging, and the method described in the current
draft is fully backwards compatible with that. Besides, implementations for that mechanism exist and haven't heard
of any problems with that.
 
I strongly disagree with your arguments about better efficiency of this new proposal. Yes, it may cause less signaling in some exeptional cases (as you have illustrated in other mails) but as John P. very well pointed out, your proposal actually increases signaling in most of the cases and involves much more rating rounds. We should not design a protocol to optimize the behavior in some extreme cases with the expense of more complexity and most likely poorer performance in normal cases. So, my vote remains against this (even updated) issue.
 
I do agree with you with that that we should only support one mechanism. But I think that mechanism should be the one described currently in the draft. And as far as I understand that is the opinion of the others involved as well.
 
BR,
Leena
-----Original Message-----
From: Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 2. helmikuuta 2004 18:07
To: Leena Mattila (TU/LMF)
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,

Thanks for the reply. I have added some comments below.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
   input from some of some data OCS vendors. Interestingly,
   3GPP went with the new proposal for IMS in Release 5 -
   this was a Diameter protocol.

Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
   existing mechanism. Except that in the existing mechanism,
   since only one allocation can actually be given, the OCS
   must make the allocation based upon the worst case scenario
   and provide quota in small enough amounts so that the usage
   at a potentially higher cost can be covered by the users
   account. In other words the OCS has to make decisions up
   front that it can then only really reconcile after the usage.

 If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
   quota to allocate because it knows how much is available in the
   users account because it has already allocated the "before"
   quota. It now has the power to allocate as much or as little
   "after" quota as it sees fit - smaller chunks to avoid credit
   fragmentation - but this is also a function of how long before
   a tariff change that the quota is requested. I.e. 30 seconds
   before a TC, it can allocate more to the "after" quota. However,
   if the request is being made 30 minutes before a TC, then it
   would allocate less to the "after" quota.

If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
   it was to replace the existing scheme. I think we all agree
   that 2 parallel mechanisms would be best to avoid. It will
   make it more difficult for OCS vendors to implement.

John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.


The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,

John.





"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.



Thanks for the reply John,
 
Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.


Hi Chris,

The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
       To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
       cc:        
       Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.




All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include a Tariff-Time-Change AVP in the answer message. Note that the
 granted units should be allocated based on the worst-case scenario in
 case of forthcoming tariff change, so that the overall reported used
 units would never exceed the credit reservation. 
 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. In case some units straddled the tariff
 change, the credit-control client SHOULD itemize those units as well.
TO:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. One of the granted units is
 allocated to be used before the potential tariff change while the
 second granted units are used after a tariff change. Both granted unit
 quotas MUST contain the same Service-Identifier and Rating-Group values.
 This dual quota mechanism ensures that the overall reported used
 units would never exceed the credit reservation. 
 The Diameter credit-control client reports both the used units before
 and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
 present. It instructs the client when the resources in the Granted-Service-
 Unit AVP should be used.
   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
 the server MUST include two separate Granted-Service-Unit AVPs (for the
 same Service-Identifier and/or Rating-Group when either the Service-
 Identifier or Rating-Group AVP is included). One of the Granted-Service-
 Units resources are used before a tariff change occurs, while the other
 is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
          
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]
TO:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
          
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [Tariff-Change-Usage ]
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
 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. 
 
TO:
 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
 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 optionally enabled by the server for a
 Diameter credit control session or sub-session.
- Section 8.42:
FROM:
 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
 defines whether units are used before, after or straddled tariff
 change when a tariff change has occurred during the reporting period.
 Omission of this AVP means that no tariff change has been occurred.
 
 Tariff-Change-Usage can be one of the following.
 
  UNIT_BEFORE_TARIFF_CHANGE                                  0
 
   The used units contains the amount of the units before 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.
 
  UNIT_INDETERMINATE                                         2
 
   The used units contains the amount of units that straddle the
   tariff change (e.g. the metering process reports to the credit-
   control client in blocks of n octets and one block straddled the
   tariff change).
TO:   
 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
   When present in the Granted-Service-Units AVP, this AVP defines whether
 units are allocated to be used before or after a tariff change event.
   When present in the Used-Service-Units AVP, this AVP identified what
 resources where used before or after a tariff change during the reporting
 period.
   Omission of this AVP means that no tariff change is to be reported and/or
 none has occurred.
 
 Tariff-Change-Usage can be one of the following.
 
  UNIT_BEFORE_TARIFF_CHANGE                                  0
 
   When present in the Granted-Service-Units AVP, this value indicates
   the amount of the units allocated for use before a tariff change
   occurs.
     When present in the Reported-Service-Units AVP, this value indicates
   the amount of resource units used before a tariff change had occurred.
 
  UNIT_AFTER_TARIFF_CHANGE                                   1
 
   When present in the Granted-Service-Units AVP, this value indicates
   the amount of the units allocated for use after a tariff change
   occurs.
     When present in the Reported-Service-Units AVP, this value indicates
   the amount of resource units used after tariff change had occurred.
   
- end of changes
Best Regards,
Chris Richards.


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

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

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3EA2C.8602B30C-- From owner-aaa-wg@merit.edu Tue Feb 3 03:33:32 2004 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 DAA28002 for ; Tue, 3 Feb 2004 03:33:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06A279125C; Tue, 3 Feb 2004 03:33:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C87E29125D; Tue, 3 Feb 2004 03:33:16 -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 4CC219125C for ; Tue, 3 Feb 2004 03:33:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35EA05DD8D; Tue, 3 Feb 2004 03:33:15 -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 734775DDBF for ; Tue, 3 Feb 2004 03:33:14 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i138XDqY002738 for ; Tue, 3 Feb 2004 09:33:13 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 09:33:16 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1AZ5GVHG>; Tue, 3 Feb 2004 09:33:38 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" , "'John.Prudhoe@vodafone.com'" , "Leena Mattila (TU/LMF)" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Tue, 3 Feb 2004 09:32:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Feb 2004 08:33:16.0200 (UTC) FILETIME=[5E8AF280:01C3EA30] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, Our point is that the mechanism defined in the draft-02 is similar as currently implemented in several systems and existing standardized protocol (CAP v.3) works similar way as well. As you know CAP v.3 is not used only for voice traffic, it is valid also for GPRS data, i.e. there exists own GPRS charging procedures. As Leena said we are not aware of any problem associated with this mechanisms so why we should change something which works very well in existing implementations? I think also that this principle is fully in line with the backwards compatibility requirements with existing systems. If the tariff switch for data charging works in this way for one node (access) I don't understand why we should have a different TSw mechanism for the other node (gateway), when the charging of these nodes are under same server's control. Regards.........Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 2. helmikuuta 2004 20:32 To: 'John.Prudhoe@vodafone.com' Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Tue Feb 3 05:18:01 2004 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 FAA00674 for ; Tue, 3 Feb 2004 05:17:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B1EA9125F; Tue, 3 Feb 2004 05:17:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A90991262; Tue, 3 Feb 2004 05:17:38 -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 99C859125F for ; Tue, 3 Feb 2004 05:17:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CE605DDEB; Tue, 3 Feb 2004 05:17:34 -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 CFC235DDF9 for ; Tue, 3 Feb 2004 05:17:31 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Tue, 3 Feb 2004 09:55:20 +0000 To: "Christopher Richards" Cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'John.Prudhoe@vodafone.com'" , "'marco.stura@nokia.com'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Tue, 3 Feb 2004 09:50:57 +0000 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 02/03/2004 09:51:00 AM, Serialize complete at 02/03/2004 09:51:00 AM Content-Type: multipart/alternative; boundary="=_alternative 0036180580256E2F_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0036180580256E2F_= Content-Type: text/plain; charset="us-ascii" Hi Chris, Thanks for the reply. It's a good example, but I'd argue it is a rare case. My thinking at the moment is that as the subscribers balance gets very low we would have to reduce the validity time of any quota anyway so there is at least adequate co-ordination between the expiry of, say, parallel voice & data sessions. The unfortunate subscriber who is running out of balance just as the rate is about to increase five-fold shouldn't cause as much of a problem as you envisage. Because the validity time is being reduced anyway there is a much smaller time window that could include the tariff change. Regards, John. "Christopher Richards" 02/02/2004 19:58 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:- Old mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small. New mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate. In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests. In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate. Cheers, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 1:08 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism. I'm making up these examples entirely at random to compare the cases. Example 1: old mechanism. A client wants a quota to send data over GPRS. It is 15 minutes before the tariff change. The tariff is higher before the change. The server allocates 50K with a validity time of 30 minutes, say. The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards). This is rated at that time and some of the monetary reservation is returned to the subscribers balance. This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported. Example 2: new mechanism. The client still wants a quota to send data over GPRS. The server allocates 25K at the expensive rate and 25K at the cheap rate. (That's already two rating events in the billing system). Validity time again 30 minutes. I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS). Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted. Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K. When the client next returns it will reports the usage in these categories, which will again have to be rated. So in example one, there are three rating events and the exchange of two Diameter command pairs. In example two there are between six and eight rating events and the exchange of three Diameter command pairs. Even in the best case with your method I believe there will be four rating events. I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it. Regards, John "Christopher Richards" 02/02/2004 18:32 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 11:24 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. ****************************************************************************** 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 ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --=_alternative 0036180580256E2F_= Content-Type: text/html; charset="us-ascii"
Hi Chris,

Thanks for the reply.  It's a good example, but I'd argue it is a rare case.

My thinking at the moment is that as the subscribers balance gets very low we would have to reduce the validity time of any quota anyway so there is at least adequate co-ordination between the expiry of, say, parallel voice & data sessions.

The unfortunate subscriber who is running out of balance just as the rate is about to increase five-fold shouldn't cause as much of a problem as you envisage.  Because the validity time is being reduced anyway there is a much smaller time window that could include the tariff change.

Regards,

John.





"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 19:58

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism



Hi John,
 
Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:-
 
Old mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small.
New mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate.
 
In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests.
 
In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate.

Cheers,
Chris.

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism.  I'm making up these examples entirely at random to compare the cases.

Example 1: old mechanism.

A client wants a quota to send data over GPRS.  It is 15 minutes before the tariff change.  The tariff is higher before the change.  The server allocates 50K with a validity time of 30 minutes, say.

The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards).  This is rated at that time and some of the monetary reservation is returned to the subscribers balance.  This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported.

Example 2: new mechanism.

The client still wants a quota to send data over GPRS.  The server allocates 25K at the expensive rate and 25K at the cheap rate.  (That's already two rating events in the billing system).  Validity time again 30 minutes.

I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS).

Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted.  Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K.  When the client next returns it will reports the usage in these categories, which will again have to be rated.


So in example one, there are three rating events and the exchange of two Diameter command pairs.  In example two there are between six and eight rating events and the exchange of three Diameter command pairs.  Even in the best case with your method I believe there will be four rating events.

I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it.

Regards,

John



"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 18:32

       
       To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
       cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
       Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism




Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification.

With that in mind, here is the updated proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 5.0, 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

Requested changes:

- Section 5, last paragraph:

FROM:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include a Tariff-Time-Change AVP in the answer message. Note that the
 granted units should be allocated based on the worst-case scenario in
 case of forthcoming tariff change, so that the overall reported used
 units would never exceed the credit reservation.  
 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. In case some units straddled the tariff
 change, the credit-control client SHOULD itemize those units as well.

TO:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. One of the granted units is
 allocated to be used before the potential tariff change while the
 second granted units are used after a tariff change. Both granted unit
 quotas MUST contain the same Service-Identifier and Rating-Group values.
 This dual quota mechanism ensures that the overall reported used
 units would never exceed the credit reservation.  
 The Diameter credit-control client reports both the used units before
 and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
 present. It instructs the client when the resources in the Granted-Service-
 Unit AVP should be used.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
 the server MUST include two separate Granted-Service-Unit AVPs (for the
 same Service-Identifier and/or Rating-Group when either the Service-
 Identifier or Rating-Group AVP is included). One of the Granted-Service-
 Units resources are used before a tariff change occurs, while the other
 is to be used after the tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
           
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]
TO:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
           
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [Tariff-Change-Usage ]
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]

- end of changes

Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards.

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change.

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.



"Christopher Richards" <crich@nortelnetworks.com>
02/02/2004 17:11
     
      To:        "'marco.stura@nokia.com'" <marco.stura@nokia.com>
      cc:        aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com
      Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco, All,

Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.

I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?
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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I guess we need the
input from some of some data OCS vendors. Interestingly,
3GPP went with the new proposal for IMS in Release 5 -
this was a Diameter protocol.

3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.

However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.

Thank you
Marco


-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,
Thanks for the reply. I have added some comments below.
Best Regards,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
input from some of some data OCS vendors. Interestingly,
3GPP went with the new proposal for IMS in Release 5 -
this was a Diameter protocol.
Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
existing mechanism. Except that in the existing mechanism,
since only one allocation can actually be given, the OCS
must make the allocation based upon the worst case scenario
and provide quota in small enough amounts so that the usage
at a potentially higher cost can be covered by the users
account. In other words the OCS has to make decisions up
front that it can then only really reconcile after the usage.
If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
quota to allocate because it knows how much is available in the
users account because it has already allocated the "before"
quota. It now has the power to allocate as much or as little
"after" quota as it sees fit - smaller chunks to avoid credit
fragmentation - but this is also a function of how long before
a tariff change that the quota is requested. I.e. 30 seconds
before a TC, it can allocate more to the "after" quota. However,
if the request is being made 30 minutes before a TC, then it
would allocate less to the "after" quota.
If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
it was to replace the existing scheme. I think we all agree
that 2 parallel mechanisms would be best to avoid. It will
make it more difficult for OCS vendors to implement.
John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,
John.


"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
     
     To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
     cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
     Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Thanks for the reply John,

Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.
Hi Chris,
The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,
John.

"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
    To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
    cc:        
    Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.

All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.
TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
       
    Granted-Service-Unit ::= < AVP Header: 431 >
                             [ Tariff-Time-Change ]  
                             [ CC-Time ]
                             [ CC-Money ]  
                             [ CC-Total-Octets ]
                             [ CC-Input-Octets ]
                             [ CC-Output-Octets ]
                             [ CC-Service-Specific-Units ]
                            *[ Service-Identifier ]
                             [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
       
    Granted-Service-Unit ::= < AVP Header: 431 >
                             [ Tariff-Time-Change ]  
                             [Tariff-Change-Usage ]
                             [ CC-Time ]
                             [ CC-Money ]  
                              [ CC-Total-Octets ]
                             [ CC-Input-Octets ]
                             [ CC-Output-Octets ]
                             [ CC-Service-Specific-Units ]
                            *[ Service-Identifier ]
                             [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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.  

TO:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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 optionally enabled by the server for a
Diameter credit control session or sub-session.
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
defines whether units are used before, after or straddled tariff
change when a tariff change has occurred during the reporting period.
Omission of this AVP means that no tariff change has been occurred.

Tariff-Change-Usage can be one of the following.

UNIT_BEFORE_TARIFF_CHANGE                                  0

The used units contains the amount of the units before 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.

UNIT_INDETERMINATE                                         2

The used units contains the amount of units that straddle the
tariff change (e.g. the metering process reports to the credit-
control client in blocks of n octets and one block straddled the
tariff change).
TO:    
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
When present in the Granted-Service-Units AVP, this AVP defines whether
units are allocated to be used before or after a tariff change event.
When present in the Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during the reporting
period.
Omission of this AVP means that no tariff change is to be reported and/or
none has occurred.

Tariff-Change-Usage can be one of the following.

UNIT_BEFORE_TARIFF_CHANGE                                  0

When present in the Granted-Service-Units AVP, this value indicates
the amount of the units allocated for use before a tariff change
occurs.
  When present in the Reported-Service-Units AVP, this value indicates
 the amount of resource units used before a tariff change had occurred.

UNIT_AFTER_TARIFF_CHANGE                                   1

When present in the Granted-Service-Units AVP, this value indicates
the amount of the units allocated for use after a tariff change
occurs.
  When present in the Reported-Service-Units AVP, this value indicates
the amount of resource units used after tariff change had occurred.
 
- end of changes
Best Regards,
Chris Richards.
******************************************************************************
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
******************************************************************************
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--=_alternative 0036180580256E2F_=-- From owner-aaa-wg@merit.edu Wed Feb 4 01:57:26 2004 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 BAA24862 for ; Wed, 4 Feb 2004 01:57:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7ABF29129B; Wed, 4 Feb 2004 01:57:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48456912A8; Wed, 4 Feb 2004 01:57: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 EB80E9129B for ; Wed, 4 Feb 2004 01:57:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id D400F5DF0A; Wed, 4 Feb 2004 01:57:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from flora.securenet.com.au (ns1.securenet.com.au [202.125.0.72]) by segue.merit.edu (Postfix) with ESMTP id 0C8635DE4E for ; Wed, 4 Feb 2004 01:57:11 -0500 (EST) Received: from leal.securenet.com.au (leal.isecure.com.au [202.125.0.94] (may be forged)) by flora.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i146v4Cr028511 for ; Wed, 4 Feb 2004 17:57:04 +1100 Received: (from root@localhost) by leal.securenet.com.au (8.12.6/8.12.6) id i146v3WL004226 for ; Wed, 4 Feb 2004 17:57:03 +1100 (EST) Received: from nodnsquery(10.11.3.10) by leal.securenet.com.au via csmap (V6.0) id srcAAAJwaiqi; Wed, 4 Feb 04 17:57:03 +1100 Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i146ulr8013501 for ; Wed, 4 Feb 2004 17:57:03 +1100 Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Wed, 4 Feb 2004 17:52:54 +1100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EAEB.88B844D5" Subject: [AAA-WG]: Question on the use of IPSEC with Diameter X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 4 Feb 2004 17:53:02 +1100 Message-ID: <85DA9C6C3DD8C74F8A8611815C635F8D415287@AMALTHEA.securenet.com.au> Thread-Topic: Question on the use of IPSEC with Diameter Thread-Index: AcPq64LMBUCRzAL4RXK/i+HVGWNcPw== From: "James Jing" To: X-OriginalArrivalTime: 04 Feb 2004 06:52:54.0171 (UTC) FILETIME=[838BFEB0:01C3EAEB] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EAEB.88B844D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Diameter transport profile mandates the use of IPSEC and requires conforming implementation to support IPSEC. My question is whether a Diameter server needs to be aware of IPSEC, as my understanding is that IPSEC is a network layer protocol, and Diameter is an application. More specifically, if a Diameter server is setup on a host, with the host providing IPSEC security, would this be a conforming configuration for Diameter? Thanks. James Jing ------_=_NextPart_001_01C3EAEB.88B844D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on the use of IPSEC with Diameter

Diameter transport profile mandates the = use of IPSEC and requires conforming implementation to support = IPSEC.

My question is whether a Diameter = server needs to be aware of IPSEC, as my understanding is that IPSEC is = a network layer protocol, and Diameter is an application. More = specifically, if a Diameter server is setup on a host, with the host = providing IPSEC security, would this be a conforming configuration for = Diameter?

Thanks.

James Jing

------_=_NextPart_001_01C3EAEB.88B844D5-- From owner-aaa-wg@merit.edu Wed Feb 4 03:40:38 2004 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 DAA25785 for ; Wed, 4 Feb 2004 03:40:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38C94912AA; Wed, 4 Feb 2004 03:40:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 044DE912AE; Wed, 4 Feb 2004 03:40:24 -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 D632E912AA for ; Wed, 4 Feb 2004 03:40:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id C292E5DF85; Wed, 4 Feb 2004 03:40:23 -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 150D15DF6F for ; Wed, 4 Feb 2004 03:40:23 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 45A1A6A903; Wed, 4 Feb 2004 10:40:06 +0200 (EET) Message-ID: <4020AF87.2000409@kolumbus.fi> Date: Wed, 04 Feb 2004 10:38:31 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Jing Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question on the use of IPSEC with Diameter References: <85DA9C6C3DD8C74F8A8611815C635F8D415287@AMALTHEA.securenet.com.au> In-Reply-To: <85DA9C6C3DD8C74F8A8611815C635F8D415287@AMALTHEA.securenet.com.au> 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 James Jing wrote: > Diameter transport profile mandates the use of IPSEC and requires > conforming implementation to support IPSEC. > > My question is whether a Diameter server needs to be aware of IPSEC, as > my understanding is that IPSEC is a network layer protocol, and Diameter > is an application. More specifically, if a Diameter server is setup on a > host, with the host providing IPSEC security, would this be a conforming > configuration for Diameter? Strictly speaking, I don't think it is required that Diameter is aware of IPsec. However, the usage of IPsec is less flexible than TLS where such awareness is easily available, and this can cause issues in the configuration of suitable CAs and the simultaneous usage of TLS and IPsec. In short, the independent host and application implementation is conformant, but may not offer quite the same ease and flexibility compared to the sole use of TLS or the ability of the application to be aware of IPsec. Here's some text from RFC 3588 that explains the issues in more detail: As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. When certificate authentication Diameter peers may not be known beforehand, and therefore peer discovery may be required. Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications. This implies, for example, that a root CA trusted for use with Diameter must also be trusted to protect SNMP. These restrictions can be awkward at best. Since TLS supports application-level granularity in certificate policy, TLS SHOULD be used to protect Diameter connections between administrative domains. IPsec is most appropriate for intra-domain usage when pre-shared keys are used as a security mechanism. When pre-shared key authentication is used with IPsec to protect Diameter, unique pre-shared keys are configured with Diameter peers, who are identified by their IP address (Main Mode), or possibly their FQDN (Aggressive Mode). As a result, it is necessary for the set of Diameter peers to be known beforehand. Therefore, peer discovery is typically not necessary. The following is intended to provide some guidance on the issue. It is recommended that a Diameter peer implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections. Inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g., TLS over IPsec) or worse, potential security vulnerabilities. When IPsec is used with Diameter, a typical security policy for outbound traffic is "Initiate IPsec, from me to any, destination port Diameter"; for inbound traffic, the policy would be "Require IPsec, from any to me, destination port Diameter". This policy causes IPsec to be used whenever a Diameter peer initiates a connection to another Diameter peer, and to be required whenever an inbound Diameter connection occurs. This policy is attractive, since it does not require policy to be set for each peer or dynamically modified each time a new Diameter connection is created; an IPsec SA is automatically created based on a simple static policy. Since IPsec extensions are typically not available to the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route to IPsec-enabling a Diameter implementation. One implication of the recommended policy is that if a node is using both TLS and IPsec, there is not a convenient way in which to use either TLS or IPsec, but not both, without reserving an additional port for TLS usage. Since Diameter uses the same port for TLS and non-TLS usage, where the recommended IPsec policy is put in place, a TLS-protected connection will match the IPsec policy, and both IPsec and TLS will be used to protect the Diameter connection. To avoid this, it would be necessary to plumb peer-specific policies either statically or dynamically. If IPsec is used to secure Diameter peer-to-peer connections, IPsec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and outbound filter policy. From owner-aaa-wg@merit.edu Wed Feb 4 05:07:28 2004 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 FAA28627 for ; Wed, 4 Feb 2004 05:07:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6687D912C7; Wed, 4 Feb 2004 05:05:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20210912C5; Wed, 4 Feb 2004 05:05:28 -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 056EB912C7 for ; Wed, 4 Feb 2004 05:04:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2B5C5DF5D; Wed, 4 Feb 2004 05:04:58 -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 DCBA15DF61 for ; Wed, 4 Feb 2004 05:04:57 -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 i14A4uM02261 for ; Wed, 4 Feb 2004 12:04:56 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 12:04:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 12:04:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Question on the use of IPSEC with Diameter Date: Wed, 4 Feb 2004 12:04:55 +0200 Message-ID: Thread-Topic: [AAA-WG]: Question on the use of IPSEC with Diameter Thread-Index: AcPq+2+869hf6/meS+KI3Z4D+LacWAACnbkw From: To: , Cc: X-OriginalArrivalTime: 04 Feb 2004 10:04:56.0710 (UTC) FILETIME=[5783EA60:01C3EB06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jari & James, > Strictly speaking, I don't think it is required that Diameter is aware > of IPsec. However, the usage of IPsec is less flexible than TLS where > such awareness is easily available, and this can cause issues in the > configuration of suitable CAs and the simultaneous usage of TLS and > IPsec. In short, the independent host and application implementation > is conformant, but may not offer quite the same ease and flexibility > compared to the sole use of TLS or the ability of the application to = be > aware of IPsec. Just to add to Jari's comment. Diameter by itself is (for the most = part) IPsec unaware, building AAA infrastructure is not. As shown in figure = 1, in section 2.5: http://www.ietf.org/rfc/rfc3588.txt There are multiple parts of the communication session between Diameter=20 clients and servers. Therefore special care needs to be made when including IPsec or TLS. Jari's text covered this issue well. thanks, John From owner-aaa-wg@merit.edu Wed Feb 4 17:09:09 2004 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 RAA03579 for ; Wed, 4 Feb 2004 17:09:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 32596912BE; Wed, 4 Feb 2004 17:08:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBD48912C4; Wed, 4 Feb 2004 17:08: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 F2D50912BE for ; Wed, 4 Feb 2004 17:08:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD1865DDE3; Wed, 4 Feb 2004 17:08:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by segue.merit.edu (Postfix) with ESMTP id 6871D5DDD6 for ; Wed, 4 Feb 2004 17:08:51 -0500 (EST) Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i14M8e4D021630; Thu, 5 Feb 2004 09:08:40 +1100 Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id i14M8eSL028809; Thu, 5 Feb 2004 09:08:40 +1100 (EST) Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAA49a4q4; Thu, 5 Feb 04 09:08:40 +1100 Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i14M8YuU023183; Thu, 5 Feb 2004 09:08:38 +1100 Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Thu, 5 Feb 2004 09:04:27 +1100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB6B.22FEA005" Subject: RE: [AAA-WG]: Question on the use of IPSEC with Diameter X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 5 Feb 2004 09:06:27 +1100 Message-ID: <85DA9C6C3DD8C74F8A8611815C635F8D415288@AMALTHEA.securenet.com.au> Thread-Topic: [AAA-WG]: Question on the use of IPSEC with Diameter Thread-Index: AcPq+j7vFjJZMuSrR2qArb5BFubOzQAbXozQ From: "James Jing" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 04 Feb 2004 22:04:27.0015 (UTC) FILETIME=[DB05B170:01C3EB6A] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EB6B.22FEA005 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Completely agree with Jari's elaboration of the inflexibility of using IPSEC, and the way it may even cause complications in an intranet environment, where the corporate LAN itself is constructed from segments linked together by IPSEC tunnels. If a single Diameter is then used for say external VPN access, there would be complications in configuring the Diameter server to use IPSEC to communicate with the VPN access server. =20 I wonder why TLS was not chosen as the mandatory security implementation for Diameter?=20 =20 The other practical difficulty is mandatory SCTP. Support and adoption for SCTP isn't widespread enough at the moment. =20 James _____ =20 From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]=20 Sent: Wednesday, February 04, 2004 7:39 PM To: James Jing Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question on the use of IPSEC with Diameter James Jing wrote:=20 > Diameter transport profile mandates the use of IPSEC and requires=20 > conforming implementation to support IPSEC.=20 >=20 > My question is whether a Diameter server needs to be aware of IPSEC, as=20 > my understanding is that IPSEC is a network layer protocol, and Diameter=20 > is an application. More specifically, if a Diameter server is setup on a=20 > host, with the host providing IPSEC security, would this be a conforming=20 > configuration for Diameter?=20 Strictly speaking, I don't think it is required that Diameter is aware=20 of IPsec. However, the usage of IPsec is less flexible than TLS where=20 such awareness is easily available, and this can cause issues in the=20 configuration of suitable CAs and the simultaneous usage of TLS and=20 IPsec. In short, the independent host and application implementation=20 is conformant, but may not offer quite the same ease and flexibility=20 compared to the sole use of TLS or the ability of the application to be=20 aware of IPsec.=20 Here's some text from RFC 3588 that explains the issues in more=20 detail:=20 As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When=20 certificates are used, it is necessary to configure the root=20 certificate authorities trusted by the Diameter peer. These root CAs=20 are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing.=20 In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization=20 hosting the Diameter peer and other organizations. As a result, a=20 Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. When certificate authentication Diameter=20 peers may not be known beforehand, and therefore peer discovery may=20 be required.=20 Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited=20 within IKE Phase 1, within IPsec it is not possible to uniquely=20 configure trusted root CAs for each application individually; the=20 same policy must be used for all applications. This implies, for=20 example, that a root CA trusted for use with Diameter must also be=20 trusted to protect SNMP. These restrictions can be awkward at best. Since TLS supports application-level granularity in certificate=20 policy, TLS SHOULD be used to protect Diameter connections between=20 administrative domains. IPsec is most appropriate for intra-domain=20 usage when pre-shared keys are used as a security mechanism.=20 When pre-shared key authentication is used with IPsec to protect=20 Diameter, unique pre-shared keys are configured with Diameter peers, who are identified by their IP address (Main Mode), or possibly their=20 FQDN (Aggressive Mode). As a result, it is necessary for the set of Diameter peers to be known beforehand. Therefore, peer discovery is typically not necessary.=20 The following is intended to provide some guidance on the issue.=20 It is recommended that a Diameter peer implement the same security=20 mechanism (IPsec or TLS) across all its peer-to-peer connections.=20 Inconsistent use of security mechanisms can result in redundant=20 security mechanisms being used (e.g., TLS over IPsec) or worse,=20 potential security vulnerabilities. When IPsec is used with=20 Diameter, a typical security policy for outbound traffic is "Initiate=20 IPsec, from me to any, destination port Diameter"; for inbound=20 traffic, the policy would be "Require IPsec, from any to me,=20 destination port Diameter".=20 This policy causes IPsec to be used whenever a Diameter peer=20 initiates a connection to another Diameter peer, and to be required=20 whenever an inbound Diameter connection occurs. This policy is=20 attractive, since it does not require policy to be set for each peer or dynamically modified each time a new Diameter connection is=20 created; an IPsec SA is automatically created based on a simple=20 static policy. Since IPsec extensions are typically not available to=20 the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route to IPsec-enabling a Diameter implementation.=20 One implication of the recommended policy is that if a node is using both TLS and IPsec, there is not a convenient way in which to use=20 either TLS or IPsec, but not both, without reserving an additional=20 port for TLS usage. Since Diameter uses the same port for TLS and=20 non-TLS usage, where the recommended IPsec policy is put in place, a TLS-protected connection will match the IPsec policy, and both IPsec and TLS will be used to protect the Diameter connection. To avoid=20 this, it would be necessary to plumb peer-specific policies either=20 statically or dynamically.=20 If IPsec is used to secure Diameter peer-to-peer connections, IPsec=20 policy SHOULD be set so as to require IPsec protection for inbound=20 connections, and to initiate IPsec protection for outbound=20 connections. This can be accomplished via use of inbound and=20 outbound filter policy.=20 This e-mail, and any attachments hereto, is intended only for use by the named addressee(s) and may contain legally privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments hereto, is strictly prohibited. If you have received this transmission in error, please notify me immediately and permanently delete the original and all copies and printouts of this e-mail. ------_=_NextPart_001_01C3EB6B.22FEA005 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: Question on the use of IPSEC with = Diameter
Completely agree with Jari's elaboration of = the=20 inflexibility of using IPSEC, and the way it may even cause = complications in an=20 intranet environment, where the corporate LAN itself is constructed from = segments linked together by IPSEC tunnels. If a single Diameter is then = used for=20 say external VPN access, there would be complications in configuring the = Diameter server to use IPSEC to communicate with the VPN access=20 server.
 
I wonder why TLS was not chosen as the = mandatory=20 security implementation for Diameter?
 
The other practical difficulty is mandatory = SCTP.=20 Support and adoption for SCTP isn't widespread enough at the=20 moment.
 

James

From: Jari Arkko = [mailto:jari.arkko@kolumbus.fi]=20
Sent: Wednesday, February 04, 2004 7:39 PM
To: = James=20 Jing
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: = Question on=20 the use of IPSEC with Diameter

James Jing wrote:
> = Diameter=20 transport profile mandates the use of IPSEC and requires =
> conforming implementation to support IPSEC. =
>
> My question is whether a = Diameter=20 server needs to be aware of IPSEC, as
> my=20 understanding is that IPSEC is a network layer protocol, and Diameter=20
> is an application. More specifically, if = a Diameter=20 server is setup on a
> host, with the host = providing=20 IPSEC security, would this be a conforming
>=20 configuration for Diameter?

Strictly speaking, I don't think it is required that = Diameter is=20 aware
of IPsec. However, the usage of IPsec is = less=20 flexible than TLS where
such awareness is = easily=20 available, and this can cause issues in the
configuration of suitable CAs and the simultaneous usage of TLS = and
IPsec. In short, the independent host and=20 application implementation
is conformant, but = may not=20 offer quite the same ease and flexibility
compared to=20 the sole use of TLS or the ability of the application to be =
aware of IPsec.

Here's some text from RFC 3588 that explains the = issues in=20 more
detail:

    As with any peer-to-peer protocol, = proper=20 configuration of the trust
    = model=20 within a Diameter peer is essential to security.  When =
    certificates are used, it is necessary to = configure=20 the root
    certificate = authorities=20 trusted by the Diameter peer.  These root CAs
    are likely to be unique to Diameter usage = and distinct=20 from the root
    CAs that = might be=20 trusted for other purposes such as Web browsing.
    In general, it is expected that those root = CAs will be=20 configured so
    as to reflect = the=20 business relationships between the organization
    hosting the Diameter peer and other=20 organizations.  As a result, a
   =20 Diameter peer will typically not be configured to allow = connectivity=20
    with any arbitrary peer.  = When=20 certificate authentication Diameter
   =20 peers may not be known beforehand, and therefore peer discovery = may=20
    be required.

    Note that IPsec is considerably = less flexible=20 than TLS when it comes
    to = configuring=20 root CAs.  Since use of Port identifiers is prohibited =
    within IKE Phase 1, within IPsec it is not = possible to=20 uniquely
    configure trusted = root CAs=20 for each application individually; the
    same policy must be used for all = applications. =20 This implies, for
    example, = that a=20 root CA trusted for use with Diameter must also be
    trusted to protect SNMP.  These = restrictions can=20 be awkward at best.
    Since = TLS=20 supports application-level granularity in certificate
    policy, TLS SHOULD be used to protect = Diameter=20 connections between
    = administrative=20 domains.  IPsec is most appropriate for intra-domain =
    usage when pre-shared keys are used as a = security=20 mechanism.

    When pre-shared key authentication = is used=20 with IPsec to protect
    = Diameter,=20 unique pre-shared keys are configured with Diameter peers, =
    who are identified by their IP address (Main = Mode), or=20 possibly their
    FQDN = (Aggressive=20 Mode).  As a result, it is necessary for the set of =
    Diameter peers to be known beforehand.  = Therefore, peer discovery is
   =20 typically not necessary.

    The following is intended to = provide some=20 guidance on the issue.

    It is recommended that a Diameter = peer=20 implement the same security
    = mechanism=20 (IPsec or TLS) across all its peer-to-peer connections.
    Inconsistent use of security mechanisms can = result in=20 redundant
    security = mechanisms being=20 used (e.g., TLS over IPsec) or worse,
   =20 potential security vulnerabilities.  When IPsec is used with =
    Diameter, a typical security = policy for=20 outbound traffic is "Initiate
    IPsec,=20 from me to any, destination port Diameter"; for inbound
    traffic, the policy would be "Require IPsec, = from any=20 to me,
    destination port=20 Diameter".

    This policy causes IPsec to be used = whenever=20 a Diameter peer
    initiates a = connection to another Diameter peer, and to be required
    whenever an inbound Diameter connection = occurs. =20 This policy is
    attractive, = since it=20 does not require policy to be set for each peer
    or dynamically modified each time a new = Diameter=20 connection is
    created; an = IPsec SA is=20 automatically created based on a simple
    static policy.  Since IPsec extensions = are=20 typically not available to
    = the=20 sockets API on most platforms, and IPsec policy functionality is=20
    implementation dependent, use of a = simple=20 static policy is the often
    = the=20 simplest route to IPsec-enabling a Diameter implementation.

    One implication of the recommended = policy is=20 that if a node is using
    = both TLS and=20 IPsec, there is not a convenient way in which to use
    either TLS or IPsec, but not both, without = reserving=20 an additional
    port for TLS=20 usage.  Since Diameter uses the same port for TLS and =
    non-TLS usage, where the recommended IPsec = policy is=20 put in place, a
    = TLS-protected=20 connection will match the IPsec policy, and both IPsec
    and TLS will be used to protect the Diameter = connection.  To avoid
    = this, it=20 would be necessary to plumb peer-specific policies either =
    statically or dynamically.

    If IPsec is used to secure Diameter = peer-to-peer connections, IPsec
   =20 policy SHOULD be set so as to require IPsec protection for = inbound=20
    connections, and to initiate IPsec = protection for outbound
   =20 connections.  This can be accomplished via use of inbound = and=20
    outbound filter policy. =
This e-mail, and any attachments hereto, is intended only for = use by the=20 named addressee(s) and may contain legally privileged and/or = confidential=20 information.  If you are not the intended recipient, you are hereby = notified that any dissemination, distribution or copying of this e-mail, = and any=20 attachments hereto, is strictly prohibited.  If you have received = this=20 transmission in error, please notify me immediately and permanently = delete the=20 original and all copies and printouts of this = e-mail.

------_=_NextPart_001_01C3EB6B.22FEA005-- From owner-aaa-wg@merit.edu Fri Feb 6 06:07:40 2004 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 GAA20551 for ; Fri, 6 Feb 2004 06:07:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B62E912EE; Fri, 6 Feb 2004 06:07:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECF7D912EF; Fri, 6 Feb 2004 06:07:27 -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 DD181912EE for ; Fri, 6 Feb 2004 06:07:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id C67EB5DEB6; Fri, 6 Feb 2004 06:07:26 -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 833215DE7D for ; Fri, 6 Feb 2004 06:07:26 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3FE986A905; Fri, 6 Feb 2004 13:07:09 +0200 (EET) Message-ID: <402374FC.7090501@kolumbus.fi> Date: Fri, 06 Feb 2004 13:05:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Jing Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question on the use of IPSEC with Diameter References: <85DA9C6C3DD8C74F8A8611815C635F8D415288@AMALTHEA.securenet.com.au> In-Reply-To: <85DA9C6C3DD8C74F8A8611815C635F8D415288@AMALTHEA.securenet.com.au> 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 James Jing wrote: > Completely agree with Jari's elaboration of the inflexibility of using > IPSEC, and the way it may even cause complications in an intranet > environment, where the corporate LAN itself is constructed from segments > linked together by IPSEC tunnels. If a single Diameter is then used for > say external VPN access, there would be complications in configuring the > Diameter server to use IPSEC to communicate with the VPN access server. > > I wonder why TLS was not chosen as the mandatory security implementation > for Diameter? It is mandatory for some nodes. For the NAS, the primary problem at the time was that there was support for IPsec for other reasons on typical NASes, so it seemed like a natural solution. If the decision were to be done today... we might end up with different requirements. > The other practical difficulty is mandatory SCTP. Support and > adoption for SCTP isn't widespread enough at the moment. I agree, though SCTP would be better suited for the kind of problem we have at hand. Its a typical issue: should we specify something that can be deployed fast and easily, no big increase in functionality? Or should we specify something that pushes the envelope a little bit, but may be deployed slower because it has additional requirements? As a practical matter though, remember that there is no protocol police. You need to make the decisions on what your products support and when they come out, on what platform, and how they compare to what your competition sells. --Jari From owner-aaa-wg@merit.edu Fri Feb 6 06:39:59 2004 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 GAA21513 for ; Fri, 6 Feb 2004 06:39:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 90060912F3; Fri, 6 Feb 2004 06:39:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F427912F8; Fri, 6 Feb 2004 06:39:45 -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 EF1D8912F3 for ; Fri, 6 Feb 2004 06:39:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id C76665DE6D; Fri, 6 Feb 2004 06:39:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 958495DDC1 for ; Fri, 6 Feb 2004 06:39:41 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i16Bddt25239 for ; Fri, 6 Feb 2004 11:39:39 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1FPW0GR5>; Fri, 6 Feb 2004 11:39:40 -0000 Message-ID: From: "Mark Watson" To: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue: Unnecessary service assumptions Date: Fri, 6 Feb 2004 11:39:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ECA5.E79AFBDE" 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_01C3ECA5.E79AFBDE Content-Type: text/plain All, Apologies for making comments on my own issue! Three improvements below (marked ******) I can provide complete updated issue text if you prefer. Regards...Mark -----Original Message----- From: Watson, Mark [MOP:EP10:EXCH] Sent: 28 January 2004 17:04 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: Issue: Unnecessary service assumptions ...not the one you are waiting for - this in uncontraversial, I hope. ...Mark Issue number: 15 Description of issue: Unnecessary service assumptions Submitter name: Mark Watson/Chris Richards Date first submitted: 28.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Various Rationale/Explanation of issues: The draft refers in various places to services which are 'zero-rated' or 'free-of-charge'. However, in general this is used to refer to services which will not be under control of the credit control server. It is not necessarily the case that such services are free-of-charge - for example, they may be charged offline, on a subscription basis or the user may be allowed limited access 'on credit'. ****** there is an unstated assumption that TERMINATE action implies all packets for the service are dropped (or at least this could be mis-understood if not intended). We should clarify that service-specific actions may be configured at the client for terminated flows. Requested change: - Section 5.5, first paragraph: FROM: When the user's account runs out of money the user must be denied to compile additional chargeable events. However, the home service provider may offer free access services, for instance access to a service portal where it is possible to top-up the account, for which the user is allowed to benefit for a limited amount of time. This time is usually dependant on the home service provider policy. TO: When the user's account runs out of money the user must be denied to ****** Change above 'must' to 'may' - operator policy decision compile additional chargeable events. However, the home service provider may offer some services, for instance access to a service portal where it is possible to top-up the account, for which the user is allowed to benefit for a limited amount of time. This time is usually dependant on the home service provider policy. - Section 5.5, third paragraph: FROM: In some service environments (e.g. NAS) the graceful service termination may be used to redirect the subscriber to a service portal for online balance top-up or other zero-rated services offered by the home service provider. In this case the graceful termination process installs a set of packet filters to restrict the user's access capability only to/from the specified destinations, all the IP packets not matching the filters will be dropped or possibly re-directed to the service portal. The user may also be displayed an appropriate notification why the access has been limited. TO: In some service environments (e.g. NAS) the graceful service termination may be used to redirect the subscriber to a service portal for online balance top-up or other services offered by the home service provider. In this case the graceful termination process installs a set of packet filters to restrict the user's access capability only to/from the specified destinations, all the IP packets not matching the filters will be dropped or possibly re-directed to the service portal. The user may also be displayed an appropriate notification why the access has been limited. ****** add: "These actions may be communicated explicitly from the server to client or may be configured per-service at the client. Explicitly signalled redirect or restrict instructions always take precedence over configured ones." - Section 5.5.2, third paragraph: FROM: In addition to the Redirect-Server AVP, the credit control server MAY include one or more Restriction-Filter-Rule AVP or one or more Filter- Id AVP in the Credit-Control-Answer message in order to enable the user to access other zero-rated services. In such a case the access device MUST drop all the packets not matching the IP filters specified in the Credit-Control-Answer message and redirect the user to the destination specified in the Redirect-Server AVP, if possible. TO: In addition to the Redirect-Server AVP, the credit control server MAY include one or more Restriction-Filter-Rule AVP or one or more Filter- Id AVP in the Credit-Control-Answer message in order to enable the user to access other services (for example zero-rated services). In such a case the access device MUST drop all the packets not matching the IP filters specified in the Credit-Control-Answer message and redirect the user to the destination specified in the Redirect-Server AVP, if possible. - Section 5.5.2, sixth paragraph: FROM: At the expiry of Validity-Time the credit control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP since there is no allotted quota to report. The credit control server processes the request and MUST perform the credit reservation. If during this time the subscriber did not replenish his/her account whether he/she will be disconnected or will be granted access to zero-rated services for unlimited time is dependent on the home service provider policy (note: the latter option implies that the service element should not remove the restriction filters upon termination of the credit control session). The server will return the appropriate Result-Code (see section 9.1) in the Credit-Control-Answer message in order to close the credit control session and implement the policy-defined action. Otherwise new quota will be returned, the service element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit control session and the service session as usual. TO: At the expiry of Validity-Time the credit control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP since there is no allotted quota to report. The credit control server processes the request and MUST perform the credit reservation. If during this time the subscriber did not replenish his/her account whether he/she will be disconnected or will be granted access to services not controlled by the credit control server for unlimited time is dependent on the home service provider policy (note: the latter option implies that the service element should not remove the restriction filters upon termination of the credit control session). The server will return the appropriate Result-Code (see section 9.1) in the Credit-Control-Answer message in order to close the credit control session and implement the policy-defined action. Otherwise new quota will be returned, the service element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit control session and the service session as usual. - section 5.5.3, second paragraph: FROM: Another entity than the credit control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter credit control application. Such an entity, for instance, may configure the access device with "zero-rated" IP flows that are to be passed when the Diameter credit control application indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP packets according to the filter rules possibly received in the Credit- Control-Answer message in addition to the filter rules possibly configured by the other entity. However, the action to be taken when the user's account cannot cover the cost of the requested service is the responsibility of the credit control server that controls the prepaid subscriber. TO: Another entity than the credit control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter credit control application. Such an entity, for example, may configure the access device with IP flows that are to be passed when the Diameter credit control application indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP packets according to the filter rules possibly received in the Credit- Control-Answer message in addition to the filter rules possibly configured by the other entity. However, the action to be taken when the user's account cannot cover the cost of the requested service is the responsibility of the credit control server that controls the prepaid subscriber. - Section 8.15, sixth paragraph: FROM: If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect- Server AVP MUST be present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is allowed to access also other zero-rated services not accessible through the address given in the Redirect-Server AVP. TO: If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect- Server AVP MUST be present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is allowed to access also other services not accessible through the address given in the Redirect-Server AVP. - Section 8.16, fifth paragraph: FROM: In contrast, a value of max type granted service unit (e.g. max Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or Rating-Group indicates that the corresponding traffic is free-of- charge. With unit type money, the value of the Exponent AVP is set to 0 (zero) when free-of-charge is indicated. With unit type service specific, the value of the CC-Service-Specific-Units AVP is set to FFFFFFFF to indicate free-of-charge. TO: In contrast, a value of max type granted service unit (e.g. max Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or Rating-Group indicates that usage of the corresponding traffic is unlimited. With unit type money, the value of the Exponent AVP is set to 0 (zero) when unlimited usage is indicated. With unit type service specific, the value of the CC-Service-Specific-Units AVP is set to FFFFFFFF to indicate unlimited usage. - Section 8.22, first paragraph: FROM: The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule and provides filter rules corresponding to zero-rated services offered by the home service provider. The access device need to configure the specified filter rules for the subscriber and MUST drop all the packets not matching these filters. Zero, one or more such AVPs MAY be present in a Credit-Control-Answer message or in an AA answer message. TO: The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule and provides filter rules corresponding to services which are to remain accessible despite there being no more service units granted. The access device need to configure the specified filter rules for the subscriber and MUST drop all the packets not matching these filters. Zero, one or more such AVPs MAY be present in a Credit-Control-Answer message or in an AA answer message. - end of changes ------_=_NextPart_001_01C3ECA5.E79AFBDE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: Unnecessary service assumptions

All,

Apologies for making comments on my own issue! Three = improvements below (marked ******) I can provide complete updated issue = text if you prefer.

Regards...Mark


-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH]
Sent: 28 January 2004 17:04
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: Issue: Unnecessary service = assumptions


...not the one you are waiting for - this in = uncontraversial, I hope.
...Mark

Issue number: 15
Description of issue: Unnecessary service = assumptions
Submitter name: Mark Watson/Chris Richards
Date first submitted: 28.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May = fix ]
Section: Various
Rationale/Explanation of issues:

The draft refers in various places to services which = are 'zero-rated' or 'free-of-charge'. However, in general this is used = to refer to services which will not be under control of the credit = control server. It is not necessarily the case that such services are = free-of-charge - for example, they may be charged offline, on a = subscription basis or the user may be allowed limited access 'on = credit'.

****** there is an unstated assumption that TERMINATE = action implies all packets for the service are dropped (or at least = this could be mis-understood if not intended). We should clarify that = service-specific actions may be configured at the client for terminated = flows.

Requested change:
- Section 5.5, first paragraph:
FROM:
   When the user's account runs out of = money the user must be denied to
   compile additional chargeable events. = However, the home service
   provider may offer free access = services, for instance access to a
   service portal where it is possible to = top-up the account, for which
   the user is allowed to benefit for a = limited amount of time. This time
   is usually dependant on the home = service provider policy.
TO:
   When the user's account runs out of = money the user must be denied to

****** Change above 'must' to 'may' - operator policy = decision
 
   compile additional chargeable events. = However, the home service
   provider may offer some services, for = instance access to a
   service portal where it is possible to = top-up the account, for which
   the user is allowed to benefit for a = limited amount of time. This time
   is usually dependant on the home = service provider policy.


- Section 5.5, third paragraph:
FROM:
   
   In some service environments (e.g. NAS) = the graceful service
   termination may be used to redirect the = subscriber to a service portal
   for online balance top-up or other = zero-rated services offered by the
   home service provider. In this case the = graceful termination process
   installs a set of packet filters to = restrict the user's access
   capability only to/from the specified = destinations, all the IP packets
   not matching the filters will be = dropped or possibly re-directed to
   the service portal. The user may also = be displayed an appropriate
   notification why the access has been = limited.
TO:
   In some service environments (e.g. NAS) = the graceful service
   termination may be used to redirect the = subscriber to a service portal
   for online balance top-up or other = services offered by the
   home service provider. In this case the = graceful termination process
   installs a set of packet filters to = restrict the user's access
   capability only to/from the specified = destinations, all the IP packets
   not matching the filters will be = dropped or possibly re-directed to
   the service portal. The user may also = be displayed an appropriate
   notification why the access has been = limited.

****** add: "These actions may be communicated = explicitly from the server to client or may be configured per-service = at the client. Explicitly signalled redirect or restrict instructions = always take precedence over configured ones."

- Section 5.5.2, third paragraph:
FROM:
   In addition to the Redirect-Server AVP, = the credit control server MAY
   include one or more = Restriction-Filter-Rule AVP or one or more Filter-
   Id AVP in the Credit-Control-Answer = message in order to enable the
   user to access other zero-rated = services. In such a case the access
   device MUST drop all the packets not = matching the IP filters specified
   in the Credit-Control-Answer message = and redirect the user to the
   destination specified in the = Redirect-Server AVP, if possible.
TO:
   In addition to the Redirect-Server AVP, = the credit control server MAY
   include one or more = Restriction-Filter-Rule AVP or one or more Filter-
   Id AVP in the Credit-Control-Answer = message in order to enable the
   user to access other services (for = example zero-rated services). In such a
   case the access device MUST drop all = the packets not matching the IP
   filters specified in the = Credit-Control-Answer message and redirect the
   user to the destination specified in = the Redirect-Server AVP, if possible.
- Section 5.5.2, sixth paragraph:
FROM:
   At the expiry of Validity-Time the = credit control client sends a
   Credit-Control-Request (UPDATE_REQUEST) = as usual. This message does
   not include the Used-Service-Unit AVP = since there is no allotted quota
   to report. The credit control server = processes the request and MUST
   perform the credit reservation. If = during this time the subscriber did
   not replenish his/her account whether = he/she will be disconnected or
   will be granted access to zero-rated = services for unlimited time is
   dependent on the home service provider = policy (note: the latter option
   implies that the service element should = not remove the restriction
   filters upon termination of the credit = control session). The server
   will return the appropriate Result-Code = (see section 9.1) in the
   Credit-Control-Answer message in order = to close the credit control
   session and implement the = policy-defined action. Otherwise new quota
   will be returned, the service element = MUST remove all the possible
   restrictions activated by the graceful = service termination process and
   continue the credit control session and = the service session as usual.
TO:
   At the expiry of Validity-Time the = credit control client sends a
   Credit-Control-Request (UPDATE_REQUEST) = as usual. This message does
   not include the Used-Service-Unit AVP = since there is no allotted quota
   to report. The credit control server = processes the request and MUST
   perform the credit reservation. If = during this time the subscriber did
   not replenish his/her account whether = he/she will be disconnected or
   will be granted access to services not = controlled by the credit control
   server for unlimited time is dependent = on the home service provider policy
   (note: the latter option implies that = the service element should not remove
   the restriction filters upon = termination of the credit control session).
   The server will return the appropriate = Result-Code (see section 9.1) in the
   Credit-Control-Answer message in order = to close the credit control
   session and implement the = policy-defined action. Otherwise new quota
   will be returned, the service element = MUST remove all the possible
   restrictions activated by the graceful = service termination process and
   continue the credit control session and = the service session as usual.
- section 5.5.3, second paragraph:
FROM:
   Another entity than the credit control = server may provision the access
   device with appropriate IP packet = filters to be used in conjunction
   with the Diameter credit control = application. Such an entity, for
   instance, may configure the access = device with "zero-rated" IP flows
   that are to be passed when the Diameter = credit control application
   indicates RESTRICT_ACCESS or REDIRECT. = The access device passes IP
   packets according to the filter rules = possibly received in the Credit-
   Control-Answer message in addition to = the filter rules possibly
   configured by the other entity. = However, the action to be taken when
   the user's account cannot cover the = cost of the requested service is
   the responsibility of the credit = control server that controls the
   prepaid subscriber.
TO:
   Another entity than the credit control = server may provision the access
   device with appropriate IP packet = filters to be used in conjunction
   with the Diameter credit control = application. Such an entity, for
   example, may configure the access = device with IP flows
   that are to be passed when the Diameter = credit control application
   indicates RESTRICT_ACCESS or REDIRECT. = The access device passes IP
   packets according to the filter rules = possibly received in the Credit-
   Control-Answer message in addition to = the filter rules possibly
   configured by the other entity. = However, the action to be taken when
   the user's account cannot cover the = cost of the requested service is
   the responsibility of the credit = control server that controls the
   prepaid subscriber.
- Section 8.15, sixth paragraph:
FROM:
   If the Final-Unit-Action AVP is set to = REDIRECT at least the Redirect-
   Server AVP MUST be present. The = Restriction-Filter-Rule AVP or the
   Filter-Id AVP MAY be present in the = Credit-Control-Answer message if
   the user is allowed to access also = other zero-rated services not
   accessible through the address given in = the Redirect-Server AVP.
TO:
   If the Final-Unit-Action AVP is set to = REDIRECT at least the Redirect-
   Server AVP MUST be present. The = Restriction-Filter-Rule AVP or the
   Filter-Id AVP MAY be present in the = Credit-Control-Answer message if
   the user is allowed to access also = other services not
   accessible through the address given in = the Redirect-Server AVP.
- Section 8.16, fifth paragraph:
FROM:
   In contrast, a value of max type = granted service unit (e.g. max
   Unsigned 32 is FFFFFFFF) associated to = a Service-Identifier(s) or
   Rating-Group indicates that the = corresponding traffic is free-of-
   charge. With unit type money, the value = of the Exponent AVP is set to
   0 (zero) when free-of-charge is = indicated. With unit type service
   specific, the value of the = CC-Service-Specific-Units AVP is set to
   FFFFFFFF to indicate free-of-charge. =
TO:
   In contrast, a value of max type = granted service unit (e.g. max
   Unsigned 32 is FFFFFFFF) associated to = a Service-Identifier(s) or
   Rating-Group indicates that usage of = the corresponding traffic is unlimited.
   With unit type money, the value of the = Exponent AVP is set to
   0 (zero) when unlimited usage is = indicated. With unit type service
   specific, the value of the = CC-Service-Specific-Units AVP is set to
   FFFFFFFF to indicate unlimited usage. =


- Section 8.22, first paragraph:
FROM:
   The Restriction-Filter-Rule AVP (AVP = Code 438) is of type IPFilterRule
   and provides filter rules corresponding = to zero-rated services offered
   by the home service provider. The = access device need to configure the
   specified filter rules for the = subscriber and MUST drop all the
   packets not matching these filters. = Zero, one or more such AVPs MAY be
   present in a Credit-Control-Answer = message or in an AA answer message.
TO:
   The Restriction-Filter-Rule AVP (AVP = Code 438) is of type IPFilterRule
   and provides filter rules corresponding = to services which are to remain
   accessible despite there being no more = service units granted. The access
   device need to configure the specified = filter rules for the subscriber and
   MUST drop all the packets not matching = these filters. Zero, one or more
   such AVPs MAY be present in a = Credit-Control-Answer message or in an AA
   answer message.


- end of changes

------_=_NextPart_001_01C3ECA5.E79AFBDE-- From owner-aaa-wg@merit.edu Fri Feb 6 10:02:36 2004 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 KAA28182 for ; Fri, 6 Feb 2004 10:02:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F00DE91302; Fri, 6 Feb 2004 10:00:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4EE891301; Fri, 6 Feb 2004 10:00:47 -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 D207C91302 for ; Fri, 6 Feb 2004 10:00:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FA6C5DE56; Fri, 6 Feb 2004 10:00:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id A638B5DDB6 for ; Fri, 6 Feb 2004 10:00:33 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i16F0Q425782; Fri, 6 Feb 2004 15:00:26 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1FPW0LR7>; Fri, 6 Feb 2004 15:00:25 -0000 Message-ID: From: "Mark Watson" To: "'John.Prudhoe@vodafone.com'" , "Christopher Richards" Cc: "'aaa-wg@merit.edu'" , "'john.loughney@nokia.com'" , "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Fri, 6 Feb 2004 15:00:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ECC1.F02501CA" 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_01C3ECC1.F02501CA Content-Type: text/plain John, all, I guess the issue we see with the single-quota mechanism for tariff change is that it requires "over-reservation" - there is credit reserved that the user cannot access before the tariff change. The amount of this credit is related to the size of the quota granted. If the authorisation is being given some time before the tariff change, then this could be quite significant and result in unnecessary early re-authorisation/credit fragmentation. A five-fold increase in rate is not so likely, I agree, but more likely is an increase from zero-rated to per-MB, which is worse! For example as a user moves from a period where MB/hours bundled with the subscription are valid into a period where they are not. You are forcing credit reservation and re-auths based on the per-MB price throughout the 'bundled' period - exactly when the user might be using the service most! Dual-quotas (before & after) also have the property that some credit is always reserved for after the tariff change, but there are two important differences: - this quantity can be chosen by the operator independent of the quota given for before the time change - credit pooling will allow this reserved credit to be accessed before the time change I also don't see much difference in the workload at the OCS - it has to calculate the rates before and after the tariff change in all cases (to see which is higher in the single quota case) and that is most of the work - actually calculating the size of the quota is just a multiplication operation. In practice the 'after' quota might be fairly small - it's purpose being largely to spread re-auths over some period (e.g. 30 mins) after the actual tariff change. This also would avoid some of the problems raised below. Regards, Mark -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 03 February 2004 09:51 To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'John.Prudhoe@vodafone.com'; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, Thanks for the reply. It's a good example, but I'd argue it is a rare case. My thinking at the moment is that as the subscribers balance gets very low we would have to reduce the validity time of any quota anyway so there is at least adequate co-ordination between the expiry of, say, parallel voice & data sessions. The unfortunate subscriber who is running out of balance just as the rate is about to increase five-fold shouldn't cause as much of a problem as you envisage. Because the validity time is being reduced anyway there is a much smaller time window that could include the tariff change. Regards, John. "Christopher Richards" 02/02/2004 19:58 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:- Old mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small. New mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate. In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests. In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate. Cheers, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 1:08 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism. I'm making up these examples entirely at random to compare the cases. Example 1: old mechanism. A client wants a quota to send data over GPRS. It is 15 minutes before the tariff change. The tariff is higher before the change. The server allocates 50K with a validity time of 30 minutes, say. The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards). This is rated at that time and some of the monetary reservation is returned to the subscribers balance. This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported. Example 2: new mechanism. The client still wants a quota to send data over GPRS. The server allocates 25K at the expensive rate and 25K at the cheap rate. (That's already two rating events in the billing system). Validity time again 30 minutes. I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS). Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted. Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K. When the client next returns it will reports the usage in these categories, which will again have to be rated. So in example one, there are three rating events and the exchange of two Diameter command pairs. In example two there are between six and eight rating events and the exchange of three Diameter command pairs. Even in the best case with your method I believe there will be four rating events. I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it. Regards, John "Christopher Richards" 02/02/2004 18:32 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 11:24 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [ mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. **************************************************************************** ** 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 **************************************************************************** ** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3ECC1.F02501CA Content-Type: text/html Message
John, all,
 
I guess the issue we see with the single-quota mechanism for tariff change is that it requires "over-reservation" - there is credit reserved that the user cannot access before the tariff change. The amount of this credit is related to the size of the quota granted. If the authorisation is being given some time before the tariff change, then this could be quite significant and result in unnecessary early re-authorisation/credit fragmentation.
 
A five-fold increase in rate is not so likely, I agree, but more likely is an increase from zero-rated to per-MB, which is worse! For example as a user moves from a period where MB/hours bundled with the subscription are valid into a period where they are not. You are forcing credit reservation and re-auths based on the per-MB price throughout the 'bundled' period - exactly when the user might be using the service most!
 
Dual-quotas (before & after) also have the property that some credit is always reserved for after the tariff change, but there are two important differences:
- this quantity can be chosen by the operator independent of the quota given for before the time change
- credit pooling will allow this reserved credit to be accessed before the time change
 
I also don't see much difference in the workload at the OCS - it has to calculate the rates before and after the tariff change in all cases (to see which is higher in the single quota case) and that is most of the work - actually calculating the size of the quota is just a multiplication operation.
 
In practice the 'after' quota might be fairly small - it's purpose being largely to spread re-auths over some period (e.g. 30 mins) after the actual tariff change. This also would avoid some of the problems raised below.
 
Regards,
 
Mark
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: 03 February 2004 09:51
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'John.Prudhoe@vodafone.com'; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

Thanks for the reply.  It's a good example, but I'd argue it is a rare case.

My thinking at the moment is that as the subscribers balance gets very low we would have to reduce the validity time of any quota anyway so there is at least adequate co-ordination between the expiry of, say, parallel voice & data sessions.

The unfortunate subscriber who is running out of balance just as the rate is about to increase five-fold shouldn't cause as much of a problem as you envisage.  Because the validity time is being reduced anyway there is a much smaller time window that could include the tariff change.

Regards,

John.





"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 19:58

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism



Hi John,
 
Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:-
 
Old mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small.
New mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate.
 
In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests.
 
In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate.

Cheers,
Chris.

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism.  I'm making up these examples entirely at random to compare the cases.

Example 1: old mechanism.

A client wants a quota to send data over GPRS.  It is 15 minutes before the tariff change.  The tariff is higher before the change.  The server allocates 50K with a validity time of 30 minutes, say.

The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards).  This is rated at that time and some of the monetary reservation is returned to the subscribers balance.  This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported.

Example 2: new mechanism.

The client still wants a quota to send data over GPRS.  The server allocates 25K at the expensive rate and 25K at the cheap rate.  (That's already two rating events in the billing system).  Validity time again 30 minutes.

I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS).

Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted.  Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K.  When the client next returns it will reports the usage in these categories, which will again have to be rated.


So in example one, there are three rating events and the exchange of two Diameter command pairs.  In example two there are between six and eight rating events and the exchange of three Diameter command pairs.  Even in the best case with your method I believe there will be four rating events.

I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it.

Regards,

John



"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 18:32

       
       To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
       cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
       Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism




Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification.

With that in mind, here is the updated proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 5.0, 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

Requested changes:

- Section 5, last paragraph:

FROM:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include a Tariff-Time-Change AVP in the answer message. Note that the
 granted units should be allocated based on the worst-case scenario in
 case of forthcoming tariff change, so that the overall reported used
 units would never exceed the credit reservation.  
 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. In case some units straddled the tariff
 change, the credit-control client SHOULD itemize those units as well.

TO:
 The Diameter credit-control server and client may optionally support a
 tariff change mechanism. The Diameter credit-control server may
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
 two quota allocations in the answer message. One of the granted units is
 allocated to be used before the potential tariff change while the
 second granted units are used after a tariff change. Both granted unit
 quotas MUST contain the same Service-Identifier and Rating-Group values.
 This dual quota mechanism ensures that the overall reported used
 units would never exceed the credit reservation.  
 The Diameter credit-control client reports both the used units before
 and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
 present. It instructs the client when the resources in the Granted-Service-
 Unit AVP should be used.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
 the server MUST include two separate Granted-Service-Unit AVPs (for the
 same Service-Identifier and/or Rating-Group when either the Service-
 Identifier or Rating-Group AVP is included). One of the Granted-Service-
 Units resources are used before a tariff change occurs, while the other
 is to be used after the tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
           
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]
TO:
 The Granted-Service-Unit AVP has the following ABNF grammar:  
           
       Granted-Service-Unit ::= < AVP Header: 431 >
                                [ Tariff-Time-Change ]  
                                [Tariff-Change-Usage ]
                                [ CC-Time ]
                                [ CC-Money ]  
                                [ CC-Total-Octets ]
                                [ CC-Input-Octets ]
                                [ CC-Output-Octets ]
                                [ CC-Service-Specific-Units ]
                               *[ Service-Identifier ]
                                [ Rating-Group ]

- end of changes

Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards.

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change.

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.



"Christopher Richards" <crich@nortelnetworks.com>
02/02/2004 17:11
     
      To:        "'marco.stura@nokia.com'" <marco.stura@nokia.com>
      cc:        aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com
      Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco, All,

Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.

I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?
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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I guess we need the
input from some of some data OCS vendors. Interestingly,
3GPP went with the new proposal for IMS in Release 5 -
this was a Diameter protocol.

3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.

However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.

Thank you
Marco


-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,
Thanks for the reply. I have added some comments below.
Best Regards,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
input from some of some data OCS vendors. Interestingly,
3GPP went with the new proposal for IMS in Release 5 -
this was a Diameter protocol.
Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
existing mechanism. Except that in the existing mechanism,
since only one allocation can actually be given, the OCS
must make the allocation based upon the worst case scenario
and provide quota in small enough amounts so that the usage
at a potentially higher cost can be covered by the users
account. In other words the OCS has to make decisions up
front that it can then only really reconcile after the usage.
If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
quota to allocate because it knows how much is available in the
users account because it has already allocated the "before"
quota. It now has the power to allocate as much or as little
"after" quota as it sees fit - smaller chunks to avoid credit
fragmentation - but this is also a function of how long before
a tariff change that the quota is requested. I.e. 30 seconds
before a TC, it can allocate more to the "after" quota. However,
if the request is being made 30 minutes before a TC, then it
would allocate less to the "after" quota.
If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
it was to replace the existing scheme. I think we all agree
that 2 parallel mechanisms would be best to avoid. It will
make it more difficult for OCS vendors to implement.
John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,
John.


"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
     
     To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
     cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
     Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Thanks for the reply John,

Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.
Hi Chris,
The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,
John.

"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
    To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
    cc:        
    Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.

All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.
TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
       
    Granted-Service-Unit ::= < AVP Header: 431 >
                             [ Tariff-Time-Change ]  
                             [ CC-Time ]
                             [ CC-Money ]  
                             [ CC-Total-Octets ]
                             [ CC-Input-Octets ]
                             [ CC-Output-Octets ]
                             [ CC-Service-Specific-Units ]
                            *[ Service-Identifier ]
                             [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
       
    Granted-Service-Unit ::= < AVP Header: 431 >
                             [ Tariff-Time-Change ]  
                             [Tariff-Change-Usage ]
                             [ CC-Time ]
                             [ CC-Money ]  
                              [ CC-Total-Octets ]
                             [ CC-Input-Octets ]
                             [ CC-Output-Octets ]
                             [ CC-Service-Specific-Units ]
                            *[ Service-Identifier ]
                             [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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.  

TO:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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 optionally enabled by the server for a
Diameter credit control session or sub-session.
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
defines whether units are used before, after or straddled tariff
change when a tariff change has occurred during the reporting period.
Omission of this AVP means that no tariff change has been occurred.

Tariff-Change-Usage can be one of the following.

UNIT_BEFORE_TARIFF_CHANGE                                  0

The used units contains the amount of the units before 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.

UNIT_INDETERMINATE                                         2

The used units contains the amount of units that straddle the
tariff change (e.g. the metering process reports to the credit-
control client in blocks of n octets and one block straddled the
tariff change).
TO:    
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
When present in the Granted-Service-Units AVP, this AVP defines whether
units are allocated to be used before or after a tariff change event.
When present in the Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during the reporting
period.
Omission of this AVP means that no tariff change is to be reported and/or
none has occurred.

Tariff-Change-Usage can be one of the following.

UNIT_BEFORE_TARIFF_CHANGE                                  0

When present in the Granted-Service-Units AVP, this value indicates
the amount of the units allocated for use before a tariff change
occurs.
  When present in the Reported-Service-Units AVP, this value indicates
 the amount of resource units used before a tariff change had occurred.

UNIT_AFTER_TARIFF_CHANGE                                   1

When present in the Granted-Service-Units AVP, this value indicates
the amount of the units allocated for use after a tariff change
occurs.
  When present in the Reported-Service-Units AVP, this value indicates
the amount of resource units used after tariff change had occurred.
 
- end of changes
Best Regards,
Chris Richards.
******************************************************************************
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
******************************************************************************
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

------_=_NextPart_001_01C3ECC1.F02501CA-- From owner-aaa-wg@merit.edu Fri Feb 6 10:39:50 2004 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 KAA01643 for ; Fri, 6 Feb 2004 10:39:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B93691300; Fri, 6 Feb 2004 10:39:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A8BE91301; Fri, 6 Feb 2004 10:39: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 CAF0E91300 for ; Fri, 6 Feb 2004 10:39:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id A23BE5DEF7; Fri, 6 Feb 2004 10:39:29 -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 856745DE97; Fri, 6 Feb 2004 10:39:19 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 6 Feb 2004 15:43:26 +0000 To: "Mark Watson" Cc: "'aaa-wg@merit.edu'" , "Christopher Richards" , "'john.loughney@nokia.com'" , "'marco.stura@nokia.com'" , owner-aaa-wg@merit.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Fri, 6 Feb 2004 15:39:02 +0000 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 02/06/2004 03:39:04 PM, Serialize complete at 02/06/2004 03:39:04 PM Content-Type: multipart/alternative; boundary="=_alternative 0055F66A80256E32_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0055F66A80256E32_= Content-Type: text/plain; charset="us-ascii" Hi Mark, I think it's understood by all that the single-quota will cause some 'over reservation'. That is simply a consequence of combining a tariff change with irregular consumption of units. However, I think all those who have responded have agreed that the proposed change would exacerbate the problem. The change from zero-rated to charged is something that has not been mentioned before (that I've noticed) but it is an interesting case. It is certainly the first realistic example where the proposed mechanism would be better than the existing mechanism. At an early stage of the discussion on this subject it was concluded that there shouldn't be two options, so I was concerned about the adverse impact on the existing mechanism. My opinion is that it is unacceptable that a solution for this zero-rated-to-charged transition makes things worse for the general case, but I feel that it is reasonable that we identify a mechanism to support your requirements that does not adversely impact everybody else. And because I still believe the proposed changes will make the general case worse, I still think that the proposed changes should be rejected. What we need are new ideas on the subject. Regards, John. PS So far I've only had one idea, and I'll be the first to admit it is not perfect. Perhaps if we pass two extra optional AVPs (haven't considered in detail where yet)... One is the amount of any free quota and the second identifies when it expires. Usage of this quota is not to be reported - alternatively a new value of FREE could be added to Tariff-Change-Usage. I'd appreciate comments from all interested parties to help improve this idea or to come up with a better idea. "Mark Watson" Sent by: owner-aaa-wg@merit.edu 06/02/2004 15:00 To: "'John.Prudhoe@vodafone.com'" , "Christopher Richards" cc: "'aaa-wg@merit.edu'" , "'john.loughney@nokia.com'" , "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism John, all, I guess the issue we see with the single-quota mechanism for tariff change is that it requires "over-reservation" - there is credit reserved that the user cannot access before the tariff change. The amount of this credit is related to the size of the quota granted. If the authorisation is being given some time before the tariff change, then this could be quite significant and result in unnecessary early re-authorisation/credit fragmentation. A five-fold increase in rate is not so likely, I agree, but more likely is an increase from zero-rated to per-MB, which is worse! For example as a user moves from a period where MB/hours bundled with the subscription are valid into a period where they are not. You are forcing credit reservation and re-auths based on the per-MB price throughout the 'bundled' period - exactly when the user might be using the service most! Dual-quotas (before & after) also have the property that some credit is always reserved for after the tariff change, but there are two important differences: - this quantity can be chosen by the operator independent of the quota given for before the time change - credit pooling will allow this reserved credit to be accessed before the time change I also don't see much difference in the workload at the OCS - it has to calculate the rates before and after the tariff change in all cases (to see which is higher in the single quota case) and that is most of the work - actually calculating the size of the quota is just a multiplication operation. In practice the 'after' quota might be fairly small - it's purpose being largely to spread re-auths over some period (e.g. 30 mins) after the actual tariff change. This also would avoid some of the problems raised below. Regards, Mark -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: 03 February 2004 09:51 To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'John.Prudhoe@vodafone.com'; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, Thanks for the reply. It's a good example, but I'd argue it is a rare case. My thinking at the moment is that as the subscribers balance gets very low we would have to reduce the validity time of any quota anyway so there is at least adequate co-ordination between the expiry of, say, parallel voice & data sessions. The unfortunate subscriber who is running out of balance just as the rate is about to increase five-fold shouldn't cause as much of a problem as you envisage. Because the validity time is being reduced anyway there is a much smaller time window that could include the tariff change. Regards, John. "Christopher Richards" 02/02/2004 19:58 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:- Old mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small. New mechanism: A client wants a quota to send data over GPRS. It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher. The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate. In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests. In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate. Cheers, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 1:08 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism. I'm making up these examples entirely at random to compare the cases. Example 1: old mechanism. A client wants a quota to send data over GPRS. It is 15 minutes before the tariff change. The tariff is higher before the change. The server allocates 50K with a validity time of 30 minutes, say. The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards). This is rated at that time and some of the monetary reservation is returned to the subscribers balance. This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported. Example 2: new mechanism. The client still wants a quota to send data over GPRS. The server allocates 25K at the expensive rate and 25K at the cheap rate. (That's already two rating events in the billing system). Validity time again 30 minutes. I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS). Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted. Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K. When the client next returns it will reports the usage in these categories, which will again have to be rated. So in example one, there are three rating events and the exchange of two Diameter command pairs. In example two there are between six and eight rating events and the exchange of three Diameter command pairs. Even in the best case with your method I believe there will be four rating events. I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it. Regards, John "Christopher Richards" 02/02/2004 18:32 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi John, Thanks for the explanation. Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always). It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification. With that in mind, here is the updated proposal:- Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 5.0, 8.16 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - end of changes Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Monday, February 02, 2004 11:24 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact). So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change. At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change. If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate. If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate. In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. I hope this explains it. Regards, John. "Christopher Richards" 02/02/2004 17:11 To: "'marco.stura@nokia.com'" cc: aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, All, Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. I'm interested in your statement that time based quotas have no interaction between the client/server: But for time based services there is no need for any interaction between server and client as also stated by John P . Could you explain your reasoning? 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: Monday, February 02, 2004 10:50 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. 3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism of allocating quotas before and after was proposed there for time based services sometime ago. But for time based services there is no need for any interaction between server and client as also stated by John P. Interestingly, there are couple of pending Change Requests against the concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community are of the same opinion. So the statement that "3GPP went with the new proposal etc." is rather inaccurate. However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific issues. Thank you Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 02 February, 2004 18:07 To: 'Leena Mattila (TU/LMF)' Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Leena, Thanks for the reply. I have added some comments below. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Monday, February 02, 2004 6:10 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. [CR] That's OK for voice traffic. I guess we need the input from some of some data OCS vendors. Interestingly, 3GPP went with the new proposal for IMS in Release 5 - this was a Diameter protocol. Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change. [CR] Yes. But this is effectively the same for the existing mechanism. Except that in the existing mechanism, since only one allocation can actually be given, the OCS must make the allocation based upon the worst case scenario and provide quota in small enough amounts so that the usage at a potentially higher cost can be covered by the users account. In other words the OCS has to make decisions up front that it can then only really reconcile after the usage. If the server wants to minimize the likelihood of higher re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. [CR] Not at all. It can make a decision about how much "after" quota to allocate because it knows how much is available in the users account because it has already allocated the "before" quota. It now has the power to allocate as much or as little "after" quota as it sees fit - smaller chunks to avoid credit fragmentation - but this is also a function of how long before a tariff change that the quota is requested. I.e. 30 seconds before a TC, it can allocate more to the "after" quota. However, if the request is being made 30 minutes before a TC, then it would allocate less to the "after" quota. If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load. [CR] The intention of my proposal was not to make it optional: it was to replace the existing scheme. I think we all agree that 2 parallel mechanisms would be best to avoid. It will make it more difficult for OCS vendors to implement. John Loughney wrote: >I am quite worried about additional optional mechanisms. Already the >specification is quite complicated and I worry that additional optional >mechansisms will create extremely complicated mechanisms. > >I favor simplication at this point, so I'd hope we could discuss the >options and focus on a single mechansim. > I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable). BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com Sent: 30. tammikuuta 2004 19:08 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Chris, I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change. As long as it is all optional. The question is: how likely is the client to run out of the before units before the time of the tariff change. This would trigger an re-authorisation even though the units after are unused. To avoid this, the server would have to allocated a higher quota in that category. Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. Regards, John. "Christopher Richards" 30/01/2004 16:27 To: "'John.Prudhoe@vodafone.com'" cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thanks for the reply John, Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? Best Regards, Chris. -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: Friday, January 30, 2004 10:18 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Hi Chris, The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). For time-based services there is no need to report the Tariff-Time-Change AVP to the client. It doesn't even need to know that the tariff has changed. When the server knows that there is tariff change due it can take this into account when rating the granted units. There is no need for any additional Diameter traffic for time-based services when there is a tariff change. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 30/01/2004 16:09 To: "'aaa-wg@merit.edu'" cc: Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. All, Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. Best Regards, Chris Richards. Description of issue: Tariff Change Submitter name: Chris Richards, Tim Roberts Date first submitted: 29.01.2004 Reference: Document: draft-ietf-aaa-diameter-cc-02.txt Comment type: T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Sections: 8.16, 8.41 and 8.42 Rationale/Explanation of issues: The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. Requested changes: - Section 5, last paragraph: FROM: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation. 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. In case some units straddled the tariff change, the credit-control client SHOULD itemize those units as well. TO: The Diameter credit-control server and client may optionally support a tariff change mechanism. The Diameter credit-control server may include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message. One of the granted units is allocated to be used before the potential tariff change while the second granted units are used after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and Rating-Group values. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change. - Section 8.16, new paragraphs: NEW: The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is present. It instructs the client when the resources in the Granted-Service- Unit AVP should be used. When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate Granted-Service-Unit AVPs (for the same Service-Identifier and/or Rating-Group when either the Service- Identifier or Rating-Group AVP is included). One of the Granted-Service- Units resources are used before a tariff change occurs, while the other is to be used after the tariff change has occurred. - Section 8.16, last paragraph: FROM: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] TO: The Granted-Service-Unit AVP has the following ABNF grammar: Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Service-Identifier ] [ Rating-Group ] - Section 8.41, first and second paragraphs: FROM: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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. TO: The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 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 optionally enabled by the server for a Diameter credit control session or sub-session. - Section 8.42: FROM: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit- control client in blocks of n octets and one block straddled the tariff change). TO: The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. When present in the Granted-Service-Units AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When present in the Used-Service-Units AVP, this AVP identified what resources where used before or after a tariff change during the reporting period. Omission of this AVP means that no tariff change is to be reported and/or none has occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Granted-Service-Units AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Reported-Service-Units AVP, this value indicates the amount of resource units used after tariff change had occurred. - end of changes Best Regards, Chris Richards. ****************************************************************************** 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 ****************************************************************************** This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --=_alternative 0055F66A80256E32_= Content-Type: text/html; charset="us-ascii"
Hi Mark,

I think it's understood by all that the single-quota will cause some 'over reservation'.  That is simply a consequence of combining a tariff change with irregular consumption of units.  However, I think all those who have responded have agreed that the proposed change would exacerbate the problem.

The change from zero-rated to charged is something that has not been mentioned before (that I've noticed) but it is an interesting case.  It is certainly the first realistic example where the proposed mechanism would be better than the existing mechanism.

At an early stage of the discussion on this subject it was concluded that there shouldn't be two options, so I was concerned about the adverse impact on the existing mechanism. My opinion is that it is unacceptable that a solution for this zero-rated-to-charged transition makes things worse for the general case, but I feel that it is reasonable that we identify a mechanism to support your requirements that does not adversely impact everybody else.

And because I still believe the proposed changes will make the general case worse, I still think that the proposed changes should be rejected.  What we need are new ideas on the subject.

Regards,

John.

PS So far I've only had one idea, and I'll be the first to admit it is not perfect.  Perhaps if we pass two extra optional AVPs (haven't considered in detail where yet)...  One is the amount of any free quota and the second identifies when it expires.  Usage of this quota is not to be reported - alternatively a new value of FREE could be added to Tariff-Change-Usage.

I'd appreciate comments from all interested parties to help improve this idea or to come up with a better idea.

 







"Mark Watson" <mwatson@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu

06/02/2004 15:00

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>, "Christopher Richards" <crich@nortelnetworks.com>
        cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, "'john.loughney@nokia.com'" <john.loughney@nokia.com>, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism



John, all,
 
I guess the issue we see with the single-quota mechanism for tariff change is that it requires "over-reservation" - there is credit reserved that the user cannot access before the tariff change. The amount of this credit is related to the size of the quota granted. If the authorisation is being given some time before the tariff change, then this could be quite significant and result in unnecessary early re-authorisation/credit fragmentation.
 
A five-fold increase in rate is not so likely, I agree, but more likely is an increase from zero-rated to per-MB, which is worse! For example as a user moves from a period where MB/hours bundled with the subscription are valid into a period where they are not. You are forcing credit reservation and re-auths based on the per-MB price throughout the 'bundled' period - exactly when the user might be using the service most!
 
Dual-quotas (before & after) also have the property that some credit is always reserved for after the tariff change, but there are two important differences:
- this quantity can be chosen by the operator independent of the quota given for before the time change
- credit pooling will allow this reserved credit to be accessed before the time change
 
I also don't see much difference in the workload at the OCS - it has to calculate the rates before and after the tariff change in all cases (to see which is higher in the single quota case) and that is most of the work - actually calculating the size of the quota is just a multiplication operation.
 
In practice the 'after' quota might be fairly small - it's purpose being largely to spread re-auths over some period (e.g. 30 mins) after the actual tariff change. This also would avoid some of the problems raised below.
 
Regards,
 
Mark
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: 03 February 2004 09:51
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'John.Prudhoe@vodafone.com'; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

Thanks for the reply.  It's a good example, but I'd argue it is a rare case.

My thinking at the moment is that as the subscribers balance gets very low we would have to reduce the validity time of any quota anyway so there is at least adequate co-ordination between the expiry of, say, parallel voice & data sessions.

The unfortunate subscriber who is running out of balance just as the rate is about to increase five-fold shouldn't cause as much of a problem as you envisage.  Because the validity time is being reduced anyway there is a much smaller time window that could include the tariff change.

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 19:58

       
       To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
       cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
       Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism




Hi John,
 
Thanks again, that's very constructive. But it highlights the problems of using examples though. There's never one definitive answer as highlighted by this example:-
 
Old mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates for the worst case scenario: 5K usage (Rated at $5) is provided! After a few seconds the 5K is used, the client makes another request for quota. Server takes the 5K @ 20c/K from the user account making it $4 and allocates another worst case scenario - this time for 4K. And so it continues - at some point the user is denied usage even though there is some funds in his account that could be used at the lower rate of 20 cents/K but cannot be allocated using the higher rate because the allocation would be too small.
New mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the tariff change. The tariff is lower before the change: 20 cents per K before the TC, $1 per K at the higher.  The user only has $5 in his account. So the server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use 20K before having to request new quota - even if it is used before the TC. If it is not used before the TC, user has 1K of use at the expensive rate.
 
In the old mechanism user funds cannot be used for the lower rate even though funds are available because allocation must use the worst case rating scenario. Also, since initial allocations used the worst case rating scenario, the quotas provided are relatively small - requiring more re-authorisation requests.
 
In the new mechanism the full balance in the account can be provided for use. And since the cheaper rated quotas are larger, less re-authorisations are needed. Essentially, the server does not have to make usage reservations based upon what cost the usage might be. It provides allocations based upon what is being used at the current rate.

Cheers,
Chris.

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Chris,

I'd like to work through a couple of examples to illustrate the respective merits of your proposal and the existing mechanism.  I'm making up these examples entirely at random to compare the cases.

Example 1: old mechanism.

A client wants a quota to send data over GPRS.  It is 15 minutes before the tariff change.  The tariff is higher before the change.  The server allocates 50K with a validity time of 30 minutes, say.

The user uses 40K (which at the end of the validity time is reported as 30K before the change and 10K afterwards).  This is rated at that time and some of the monetary reservation is returned to the subscribers balance.  This means there are three rating events in the billing system - one for the original quota at the worst case rate and one at each of the two rates when the used quota is reported.

Example 2: new mechanism.

The client still wants a quota to send data over GPRS.  The server allocates 25K at the expensive rate and 25K at the cheap rate.  (That's already two rating events in the billing system).  Validity time again 30 minutes.

I disagree with your earlier point that the cheap rate can be a large quota because the goal is to minimise the amount reserved for any one service so that funds are available for other activity (such as voice or SMS).

Anyway, as before, the user tries to use 30K before the tariff time change, but only has a quota of 25K so has to return after that has been exhausted.  Whether the billing engine re-rates the used quota isn this case is implementation dependent, but it will definitely have to rate twice for the new quota, which will be again of 25K + 25K.  When the client next returns it will reports the usage in these categories, which will again have to be rated.


So in example one, there are three rating events and the exchange of two Diameter command pairs.  In example two there are between six and eight rating events and the exchange of three Diameter command pairs.  Even in the best case with your method I believe there will be four rating events.

I'm afraid I'm still of the opinion that the proposed change is less than efficient than the mechanism that you want to replace, so unless anyone can point out clear advantages with it that I haven't spotted my vote remains against it.

Regards,

John


"Christopher Richards" <crich@nortelnetworks.com>

02/02/2004 18:32

       
      To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
      cc:        aaa-wg@merit.edu, john.loughney@nokia.com, "'marco.stura@nokia.com'" <marco.stura@nokia.com>
      Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism





Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification.

With that in mind, here is the updated proposal:-

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 5.0, 8.16

Rationale/Explanation of issues:

The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

Requested changes:

- Section 5, last paragraph:

FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.

TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
      Granted-Service-Unit ::= < AVP Header: 431 >
                               [ Tariff-Time-Change ]  
                               [ CC-Time ]
                               [ CC-Money ]  
                               [ CC-Total-Octets ]
                               [ CC-Input-Octets ]
                               [ CC-Output-Octets ]
                               [ CC-Service-Specific-Units ]
                              *[ Service-Identifier ]
                               [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
         
      Granted-Service-Unit ::= < AVP Header: 431 >
                               [ Tariff-Time-Change ]  
                               [Tariff-Change-Usage ]
                               [ CC-Time ]
                               [ CC-Money ]  
                               [ CC-Total-Octets ]
                               [ CC-Input-Octets ]
                               [ CC-Output-Octets ]
                               [ CC-Service-Specific-Units ]
                              *[ Service-Identifier ]
                               [ Rating-Group ]

- end of changes

Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; john.loughney@nokia.com; John.Prudhoe@vodafone.com; 'marco.stura@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards.

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change.

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change.

I hope this explains it.

Regards,

John.


"Christopher Richards" <crich@nortelnetworks.com>
02/02/2004 17:11
     
     To:        "'marco.stura@nokia.com'" <marco.stura@nokia.com>
     cc:        aaa-wg@merit.edu, John.Prudhoe@vodafone.com, john.loughney@nokia.com
     Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco, All,

Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here.

I'm interested in your statement that time based quotas have no interaction between the client/server:
But for time based services there is no need for any interaction between server and client as
also stated by John P .
Could you explain your reasoning?
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: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; John.Prudhoe@vodafone.com; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

   [CR] That's OK for voice traffic. I guess we need the
input from some of some data OCS vendors. Interestingly,
3GPP went with the new proposal for IMS in Release 5 -
this was a Diameter protocol.

3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago.
But for time based services there is no need for any interaction between server and client as
also stated by John P.  Interestingly, there are couple of pending Change Requests against the
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.

However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.

Thank you
Marco


-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena,
Thanks for the reply. I have added some comments below.
Best Regards,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com]
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; 'John.Prudhoe@vodafone.com'; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely.

   [CR] That's OK for voice traffic. I guess we need the
input from some of some data OCS vendors. Interestingly,
3GPP went with the new proposal for IMS in Release 5 -
this was a Diameter protocol.
Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
existing mechanism. Except that in the existing mechanism,
since only one allocation can actually be given, the OCS
must make the allocation based upon the worst case scenario
and provide quota in small enough amounts so that the usage
at a potentially higher cost can be covered by the users
account. In other words the OCS has to make decisions up
front that it can then only really reconcile after the usage.
If the server wants to minimize the likelihood of higher
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after.

   [CR] Not at all. It can make a decision about how much "after"
quota to allocate because it knows how much is available in the
users account because it has already allocated the "before"
quota. It now has the power to allocate as much or as little
"after" quota as it sees fit - smaller chunks to avoid credit
fragmentation - but this is also a function of how long before
a tariff change that the quota is requested. I.e. 30 seconds
before a TC, it can allocate more to the "after" quota. However,
if the request is being made 30 minutes before a TC, then it
would allocate less to the "after" quota.
If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional:
it was to replace the existing scheme. I think we all agree
that 2 parallel mechanisms would be best to avoid. It will
make it more difficult for OCS vendors to implement.
John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the
>specification is quite complicated and I worry that additional optional
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR,
Leena
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of John.Prudhoe@vodafone.com
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Chris,
I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional.

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly.

 
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation.

Regards,
John.

"Christopher Richards" <crich@nortelnetworks.com>
30/01/2004 16:27
   
    To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
    cc:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, owner-aaa-wg@merit.edu
    Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Thanks for the reply John,

Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.

However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?

 
Best Regards,
Chris.
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.
Hi Chris,
The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change.

Regards,
John.

"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
30/01/2004 16:09        
   To:        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
   cc:        
   Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.

All,
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft.
Best Regards,
Chris Richards.
Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference:
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42
Rationale/Explanation of issues:
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values.

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit.

Requested changes:
- Section 5, last paragraph:
FROM:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that the
granted units should be allocated based on the worst-case scenario in
case of forthcoming tariff change, so that the overall reported used
units would never exceed the credit reservation.  
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. In case some units straddled the tariff
change, the credit-control client SHOULD itemize those units as well.
TO:
The Diameter credit-control server and client may optionally support a
tariff change mechanism. The Diameter credit-control server may
include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
two quota allocations in the answer message. One of the granted units is
allocated to be used before the potential tariff change while the
second granted units are used after a tariff change. Both granted unit
quotas MUST contain the same Service-Identifier and Rating-Group values.
This dual quota mechanism ensures that the overall reported used
units would never exceed the credit reservation.  
The Diameter credit-control client reports both the used units before
and after the tariff change.
- Section 8.16, new paragraphs:
NEW:
The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is
present. It instructs the client when the resources in the Granted-Service-
Unit AVP should be used.
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present,
the server MUST include two separate Granted-Service-Unit AVPs (for the
same Service-Identifier and/or Rating-Group when either the Service-
Identifier or Rating-Group AVP is included). One of the Granted-Service-
Units resources are used before a tariff change occurs, while the other
is to be used after the tariff change has occurred.
- Section 8.16, last paragraph:
FROM:
The Granted-Service-Unit AVP has the following ABNF grammar:  
       
   Granted-Service-Unit ::= < AVP Header: 431 >
                            [ Tariff-Time-Change ]  
                            [ CC-Time ]
                            [ CC-Money ]  
                            [ CC-Total-Octets ]
                            [ CC-Input-Octets ]
                            [ CC-Output-Octets ]
                            [ CC-Service-Specific-Units ]
                           *[ Service-Identifier ]
                            [ Rating-Group ]
TO:
The Granted-Service-Unit AVP has the following ABNF grammar:  
       
   Granted-Service-Unit ::= < AVP Header: 431 >
                            [ Tariff-Time-Change ]  
                            [Tariff-Change-Usage ]
                            [ CC-Time ]
                            [ CC-Money ]  
                             [ CC-Total-Octets ]
                            [ CC-Input-Octets ]
                            [ CC-Output-Octets ]
                            [ CC-Service-Specific-Units ]
                           *[ Service-Identifier ]
                            [ Rating-Group ]
- Section 8.41, first and second paragraphs:
FROM:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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.  

TO:
The Tariff-Time-Change AVP (AVP code 451) is of type Time, and
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 optionally enabled by the server for a
Diameter credit control session or sub-session.
- Section 8.42:
FROM:
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and
defines whether units are used before, after or straddled tariff
change when a tariff change has occurred during the reporting period.
Omission of this AVP means that no tariff change has been occurred.

Tariff-Change-Usage can be one of the following.

UNIT_BEFORE_TARIFF_CHANGE                                  0

The used units contains the amount of the units before 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.

UNIT_INDETERMINATE                                         2

The used units contains the amount of units that straddle the
tariff change (e.g. the metering process reports to the credit-
control client in blocks of n octets and one block straddled the
tariff change).
TO:    
The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.
When present in the Granted-Service-Units AVP, this AVP defines whether
units are allocated to be used before or after a tariff change event.
When present in the Used-Service-Units AVP, this AVP identified what
resources where used before or after a tariff change during the reporting
period.
Omission of this AVP means that no tariff change is to be reported and/or
none has occurred.

Tariff-Change-Usage can be one of the following.

UNIT_BEFORE_TARIFF_CHANGE                                  0

When present in the Granted-Service-Units AVP, this value indicates
the amount of the units allocated for use before a tariff change
occurs.
 When present in the Reported-Service-Units AVP, this value indicates
the amount of resource units used before a tariff change had occurred.

UNIT_AFTER_TARIFF_CHANGE                                   1

When present in the Granted-Service-Units AVP, this value indicates
the amount of the units allocated for use after a tariff change
occurs.
 When present in the Reported-Service-Units AVP, this value indicates
the amount of resource units used after tariff change had occurred.

- end of changes
Best Regards,
Chris Richards.
******************************************************************************
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
******************************************************************************
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--=_alternative 0055F66A80256E32_=-- From owner-aaa-wg@merit.edu Mon Feb 9 06:48:11 2004 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 GAA13704 for ; Mon, 9 Feb 2004 06:48:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 045FB91237; Mon, 9 Feb 2004 06:48:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C05B09126D; Mon, 9 Feb 2004 06:47: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 66ECC91237 for ; Mon, 9 Feb 2004 06:47:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 416EA5E020; Mon, 9 Feb 2004 06:47: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 859955DEFC for ; Mon, 9 Feb 2004 06:47:57 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19Bluv05574 for ; Mon, 9 Feb 2004 13:47:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 13:47:55 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 13:47:55 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 13:47: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="Windows-1251" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 13:47:55 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C83B9@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPs0VzB8v/HE7q4QP6rt7KrT/Oh/gCHfTMg From: To: , Cc: , , X-OriginalArrivalTime: 09 Feb 2004 11:47:55.0643 (UTC) FILETIME=[8E8304B0:01C3EF02] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mark, John Mark Watson wrote: >Also, we have not thought before about the interaction of tariff time = changes with credit pooling - dual quotas interact well with=20 >credit sharing because the multipliers allow the 'after tariff change' = quota to be shared with the 'before tariff change one' - this=20 >is the only mechanism which eliminates the over-reservation effect and = so is the best possible from the point of view of=20 >reducing early re-authorisations. Yes Mark, I guess credit pooling may eliminate the over-reservation = effect but I think we cannot force a simple client to support credit = pooling because it supports the tariff time changes, I think the two = mechanisms should not be coupled by any means. However, the tariff time = change mechanism should work same way also in the event that credit = pooling (or in other words independent credit control of multiple = services in a DCC (sub-)session) is supported. >Having said that, I appreciate the need to keep things simple for = clients which don't support pooling etc. This is exactly the point. Building on the John's inputs one possible = solution that I guess meet your requirements and doesn't adversely = impact everybody else could be to make the tariff change AVP a grouped = AVP as follow: Tariff-Change-Info :: < AVP Header: TBD > { Tariff-Time-Change } [ Unlimited-Use-Indication ] The presence of the Unlimited-Use-Indication AVP would mean that the = granted-units MUST be consumed only after the tariff change, before = tariff change the end-user have rights to unlimited use of resources = (i.e. zero-rated). However, the DCC client=20 MUST meter the units used before the tariff change and report those = units to the server associated to the Tariff-Change-Usage with value = UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used after = tariff change are reported). This way there is only a single small = credit reservation to cover the "per MB" case, the main purpose being to = spread the credit re-authorization messages across some time period. There is always the drawback that a small amount of credit need to be = allocated even though the is no certainty that the end-user will consume = after tariff change, but I guess this cannot be avoided whatever = mechanism we select. Do you think would be useful to indicate also the other case, moving = from per MB to zero rate? In this case the Unlimited-Use-Indication would have two values to = indicate whether the unlimited use applies before or after tariff = change. When after tariff change applies, the client MUST stop using the = granted units but MUST continue to meter the traffic. Credit re-authorization will occur upon Validity-Time expires and the = DCC client MUST report the units used after the tariff change associated = to the Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual = (of course also the units used before tariff change are reported). This way there would be one single mechanism and we could optimally = support the extreme case of moves from zero-rate to per MB cost with the = single quota. What do you think? Regards Marco From owner-aaa-wg@merit.edu Mon Feb 9 07:24:38 2004 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 HAA15117 for ; Mon, 9 Feb 2004 07:24:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 315CA9126E; Mon, 9 Feb 2004 07:24:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF30791271; Mon, 9 Feb 2004 07:24: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 3482F9126E for ; Mon, 9 Feb 2004 07:24:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3B675E058; Mon, 9 Feb 2004 07:24:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 666245DFE6 for ; Mon, 9 Feb 2004 07:24:21 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19COAc17226; Mon, 9 Feb 2004 12:24:10 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1FPW07LT>; Mon, 9 Feb 2004 12:24:11 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "Christopher Richards" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 12:24:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF07.9B55B200" 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_01C3EF07.9B55B200 Content-Type: text/plain Hi Marco. Completely unlimited usage is a rather rare tariff. I was thinking more of the case where a certain volume is bundled with the users subscription - so there is still a quota of X MB, but this does not require any reservation to be made from the users account (they've already paid as part of their monthly fee). I wasn't suggesting that we should link the tariff change and credit pooling mechansism, but just pointing out that with a dual quota approach then it is at least *possible* (but not mandatory) to develop a system which is optimal in terms of avoiding over-reservations and consequent additional re-authorisations. With a single quota approach this is not possible. I'm afraid I can't think of an easy way of adding a dual quota approach as an optional extension above the existing single quota approach. I think we need to choose one or the other based on which is technically better. I am not sure that handling separate 'before' and 'after' quotas is any more complex for a 'simple client' than the single quota mechanism - both keep separate before/after counts, single quota compares before+after with quota value, dual quota compares before with before-quota and after with after-auota - do you really think it is more complex ? Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 09 February 2004 11:48 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Mark, John Mark Watson wrote: >Also, we have not thought before about the interaction of tariff time >changes with credit pooling - dual quotas interact well with >credit sharing because the multipliers allow the 'after tariff change' quota to be shared with the 'before tariff change one' - this >is the only mechanism which eliminates the over-reservation effect and so is the best possible from the point of view of >reducing early re-authorisations. Yes Mark, I guess credit pooling may eliminate the over-reservation effect but I think we cannot force a simple client to support credit pooling because it supports the tariff time changes, I think the two mechanisms should not be coupled by any means. However, the tariff time change mechanism should work same way also in the event that credit pooling (or in other words independent credit control of multiple services in a DCC (sub-)session) is supported. >Having said that, I appreciate the need to keep things simple for >clients which don't support pooling etc. This is exactly the point. Building on the John's inputs one possible solution that I guess meet your requirements and doesn't adversely impact everybody else could be to make the tariff change AVP a grouped AVP as follow: Tariff-Change-Info :: < AVP Header: TBD > { Tariff-Time-Change } [ Unlimited-Use-Indication ] The presence of the Unlimited-Use-Indication AVP would mean that the granted-units MUST be consumed only after the tariff change, before tariff change the end-user have rights to unlimited use of resources (i.e. zero-rated). However, the DCC client MUST meter the units used before the tariff change and report those units to the server associated to the Tariff-Change-Usage with value UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used after tariff change are reported). This way there is only a single small credit reservation to cover the "per MB" case, the main purpose being to spread the credit re-authorization messages across some time period. There is always the drawback that a small amount of credit need to be allocated even though the is no certainty that the end-user will consume after tariff change, but I guess this cannot be avoided whatever mechanism we select. Do you think would be useful to indicate also the other case, moving from per MB to zero rate? In this case the Unlimited-Use-Indication would have two values to indicate whether the unlimited use applies before or after tariff change. When after tariff change applies, the client MUST stop using the granted units but MUST continue to meter the traffic. Credit re-authorization will occur upon Validity-Time expires and the DCC client MUST report the units used after the tariff change associated to the Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual (of course also the units used before tariff change are reported). This way there would be one single mechanism and we could optimally support the extreme case of moves from zero-rate to per MB cost with the single quota. What do you think? Regards Marco ------_=_NextPart_001_01C3EF07.9B55B200 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco.

Completely unlimited usage is a rather rare tariff. I = was thinking more of the case where a certain volume is bundled with = the users subscription - so there is still a quota of X MB, but this = does not require any reservation to be made from the users account = (they've already paid as part of their monthly fee).

I wasn't suggesting that we should link the tariff = change and credit pooling mechansism, but just pointing out that with a = dual quota approach then it is at least *possible* (but not mandatory) = to develop a system which is optimal in terms of avoiding = over-reservations and consequent additional re-authorisations. With a = single quota approach this is not possible.

I'm afraid I can't think of an easy way of adding a = dual quota approach as an optional extension above the existing single = quota approach. I think we need to choose one or the other based on = which is technically better.

I am not sure that handling separate 'before' and = 'after' quotas is any more complex for a 'simple client' than the = single quota mechanism - both keep separate before/after counts, single = quota compares before+after with quota value, dual quota compares = before with before-quota and after with after-auota - do you really = think it is more complex ?

Regards...Mark

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 09 February 2004 11:48
To: Watson, Mark [MOP:EP10:EXCH]; = John.Prudhoe@vodafone.com
Cc: aaa-wg@merit.edu; Richards, Christopher = [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism


Hi Mark, John

Mark Watson wrote:

>Also, we have not thought before about the = interaction of tariff time
>changes with credit pooling - dual quotas = interact well with
>credit sharing because the multipliers allow the = 'after tariff change' quota to be shared with the 'before tariff change = one' - this

>is the only mechanism which eliminates the = over-reservation effect and so is the best possible from the point of = view of

>reducing early re-authorisations.

Yes Mark, I guess credit pooling may eliminate the = over-reservation effect but I think we cannot force a simple client to = support credit pooling because it supports the tariff time changes, I = think the two mechanisms should not be coupled by any means. However, = the tariff time change mechanism should work same way also in the event = that credit pooling (or in other words independent credit control of = multiple services in a DCC (sub-)session)  is = supported.

>Having said that, I appreciate the need to keep = things simple for
>clients which don't support pooling etc.

This is exactly the point. Building on the John's = inputs one possible solution that I guess meet your requirements and = doesn't adversely impact everybody else could be to make the tariff = change AVP a grouped  AVP as follow:

        = Tariff-Change-Info :: < AVP Header: TBD >
          &nb= sp;           &nb= sp;           &nb= sp; { Tariff-Time-Change }
          &nb= sp;           &nb= sp;           &nb= sp; [ Unlimited-Use-Indication ]

The presence of the Unlimited-Use-Indication AVP = would mean that the granted-units MUST be consumed only after the = tariff change, before tariff change the end-user have rights to = unlimited use of resources (i.e. zero-rated). However, the DCC client =

MUST meter the units used before the tariff change = and report those units to the server associated to the = Tariff-Change-Usage with value UNIT_BEFORE_TARIFF_CHANGE as usual (of = course also the units used after tariff change are reported). This way = there is only a single small credit reservation to cover the "per = MB" case, the main purpose being to spread the credit = re-authorization messages across some time period.

There is always the drawback that a small amount of = credit need to be allocated even though the is no certainty that the = end-user will consume after tariff change, but I guess this cannot be = avoided whatever mechanism we select.

Do you think would be useful to indicate also the = other case, moving from per MB to zero rate? In this case the = Unlimited-Use-Indication would have two values to indicate whether the = unlimited use applies before or after tariff change. When after tariff = change applies, the client MUST stop using the granted units but MUST = continue to meter the traffic. Credit re-authorization will occur upon = Validity-Time expires and the DCC client MUST report the units used = after the tariff change associated to the Tariff-Change-Usage with = value UNIT_AFTER_TARIFF_CHANGE as usual  (of course also the units = used before tariff change are reported).

This way there would be one single mechanism and we = could optimally support the extreme case of moves from zero-rate to per = MB cost with the single quota. What do you think?

Regards
Marco

------_=_NextPart_001_01C3EF07.9B55B200-- From owner-aaa-wg@merit.edu Mon Feb 9 07:38:07 2004 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 HAA15569 for ; Mon, 9 Feb 2004 07:38:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F65791271; Mon, 9 Feb 2004 07:37:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F341491272; Mon, 9 Feb 2004 07:37:51 -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 91F1D91271 for ; Mon, 9 Feb 2004 07:37:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 269ED5E024; Mon, 9 Feb 2004 07:37:50 -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 7A2C45E026 for ; Mon, 9 Feb 2004 07:37:48 -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 i19Cblq03047 for ; Mon, 9 Feb 2004 14:37:47 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 9 Feb 2004 14:37:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 14:37:47 +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]: Another shot at Issue 414: Key AVPs Date: Mon, 9 Feb 2004 14:37:46 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3974@esebe023.ntc.nokia.com> Thread-Topic: Another shot at Issue 414: Key AVPs Thread-Index: AcPvCYWRTce/925SQ66zm5gRIv8fVw== From: To: X-OriginalArrivalTime: 09 Feb 2004 12:37:47.0595 (UTC) FILETIME=[85DAA9B0:01C3EF09] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, The one major still open in Diameter EAP application is the AVP(s) to be used for keys. There are several complications: while some link layers (such as 802.11i) are happy with a single key, some (e.g. MPPE) need two. Also, we would like to be compatible with the de facto RADIUS practise (MS-MPPE-* attributes), so translation should work "well enough" in=20 both directions. The current sketch in -03 draft does not really support having more than one separate key. I listed some possible alternatives=20 while working on -02 version: http://www.drizzle.com/~aboba/AAA/issues5.html#Issue%20414 =CDMHO, alternative #3 seems the best of those, but it requires=20 that translation agents translating from RADIUS Access-Accept=20 to Diameter-EAP-Answer can figure out the correct key type... I had a chat with Jari a while ago, and we came up with a simple (if not very elegant) alternative... so, I'd like to ask your comments about the following: 4.1.3 NAS-Session-Key AVP The NAS-Session-Key AVP (AVP Code TBD) is of type OctetString. =20 It is used by the Diameter server to deliver keying material=20 to be used between the client and the NAS. More than one NAS-Session-Key AVP MAY be sent, and their order is significant. The interpretation depends on what security mechanisms are going to be used between the client and the NAS: o For IEEE 802.11i, only a single NAS-Session-Key AVP is used: it contains the Pairwise Master Key (PMK). o For MPPE, two NAS-Session-Key AVPs are used: the first contains the uplink (Recv) key, and the second contains the downlink=20 (Send) key. 6.1 RADIUS Request forwarded as Diameter Request ... o Diameter NAS-Session-Key AVPs can be translated to the vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes [RFC2548]. If more than one NAS-Session-Key AVP is present, the first is translated to MS-MPPE-Recv-Key and the second to MS-MPPE-Send-Key. The encryption of this attribute is described in [RFC2548]. 6.2 Diameter Request forwarded as RADIUS Request ... o If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or MS-MPPE-Send-Key attributes [RFC2548], they can be translated to Diameter NAS-Session-Key AVPs. If both attributes are present, MS-MPPE-Recv-Key corresponds to the first NAS-Session-Key AVP and MS-MPPE-Send-Key to the second. The attribute has to be decrypted before conversion, and only the Key sub-field is stored to the NAS-Session-Key AVP (i.e., Salt, Key-Length and Padding are discarded after translation). Another possibility would be to use alternative #3, but add=20 an "UNDEFINED" EAP-Key-Type value; this could be used by=20 translation agents when they can't figure out the key type (this would be somewhat similar to what is proposed above, except that the individual AVPs would be inside one grouped=20 AVP instead of being at the "top level"). Comments welcome... Best regards, Pasi From owner-aaa-wg@merit.edu Mon Feb 9 08:05:04 2004 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 IAA16795 for ; Mon, 9 Feb 2004 08:05:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C38AA91273; Mon, 9 Feb 2004 08:04:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 892B891274; Mon, 9 Feb 2004 08:04:43 -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 91EEB91273 for ; Mon, 9 Feb 2004 08:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 674235DF8A; Mon, 9 Feb 2004 08:04:41 -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 845665DDEC for ; Mon, 9 Feb 2004 08:04:40 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19D4dv05383 for ; Mon, 9 Feb 2004 15:04:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 15:04:33 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:04:33 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:04:33 +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_01C3EF0D.42623D06" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 15:04:32 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0427@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPvB6RK9ndfM5Z6QYOFxC+Pw7RdCgAAH8bQ From: To: , Cc: , , X-OriginalArrivalTime: 09 Feb 2004 13:04:33.0067 (UTC) FILETIME=[42CA3FB0:01C3EF0D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EF0D.42623D06 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 Mark Watson wrote: =20 >Completely unlimited usage is a rather rare tariff. I was thinking more = of the case where a certain volume is bundled with the users=20 >subscription - so there is still a quota of X MB, but this does not = require any reservation to be made from the users account (they've=20 >already paid as part of their monthly fee). =20 If you are thinking of a case where a user paid X MB as part of the = monthly fee I would expect that these are always X MB regardless the = applicable tariff at a given time of the day, no?=20 Because these X MB are paid as part of the monthly fee the server would = grant a quota of X MB, when these units have been consumed by the = end-user the client report back, those are not affected by tariff = changes. Or do I have totally missunderstood your case? =20 >I'm afraid I can't think of an easy way of adding a dual quota approach = as an optional extension above the existing single quota=20 >approach. I think we need to choose one or the other based on which is = technically better. =20 I have the same feeling, but I think also backword compatibility with = existing system need to be considered when making the choice see next = point.=20 =20 > I am not sure that handling separate 'before' and 'after' quotas is = any more complex for a 'simple client' than the single quota=20 >mechanism - both keep separate before/after counts, single quota = compares before+after with quota value, dual quota compares=20 >before with before-quota and after with after-auota - do you really = think it is more complex ? =20 Well, I'm not thinking it is far more complex. However, I'm somewhat in = agreement with John's arguments. With the dual quota there is also another small problem that is backword = compatibility with existing systems (not sure we already consider this = aspect and I apologize if already did). Unfortunately we have existing = deployments in which the DCC may have to fit e.g. existing 2.5G and 3G networks. The DCC server may need to connect = to existing IN systems where the tariff change is implemented according = the current draft 02. The unfortunate DCC server that receive one quota = associated to the Tariff switch cannot convert this into two quotas, or = if it does it will not get the wanted result. I'm not sure we can design = the solution as if such systems wouldn't exist. =20 Regards Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 09 February, 2004 14:24 To: Stura Marco (Nokia-NET/Helsinki); 'John.Prudhoe@vodafone.com' Cc: 'aaa-wg@merit.edu'; Christopher Richards; Loughney John = (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco.=20 Completely unlimited usage is a rather rare tariff. I was thinking more = of the case where a certain volume is bundled with the users = subscription - so there is still a quota of X MB, but this does not = require any reservation to be made from the users account (they've = already paid as part of their monthly fee). I wasn't suggesting that we should link the tariff change and credit = pooling mechansism, but just pointing out that with a dual quota = approach then it is at least *possible* (but not mandatory) to develop a = system which is optimal in terms of avoiding over-reservations and = consequent additional re-authorisations. With a single quota approach = this is not possible. I'm afraid I can't think of an easy way of adding a dual quota approach = as an optional extension above the existing single quota approach. I = think we need to choose one or the other based on which is technically = better. I am not sure that handling separate 'before' and 'after' quotas is any = more complex for a 'simple client' than the single quota mechanism - = both keep separate before/after counts, single quota compares = before+after with quota value, dual quota compares before with = before-quota and after with after-auota - do you really think it is more = complex ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: 09 February 2004 11:48=20 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com=20 Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; = john.loughney@nokia.com=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Mark, John=20 Mark Watson wrote:=20 >Also, we have not thought before about the interaction of tariff time=20 >changes with credit pooling - dual quotas interact well with=20 >credit sharing because the multipliers allow the 'after tariff change' = quota to be shared with the 'before tariff change one' - this=20 >is the only mechanism which eliminates the over-reservation effect and = so is the best possible from the point of view of=20 >reducing early re-authorisations.=20 Yes Mark, I guess credit pooling may eliminate the over-reservation = effect but I think we cannot force a simple client to support credit = pooling because it supports the tariff time changes, I think the two = mechanisms should not be coupled by any means. However, the tariff time = change mechanism should work same way also in the event that credit = pooling (or in other words independent credit control of multiple = services in a DCC (sub-)session) is supported. >Having said that, I appreciate the need to keep things simple for=20 >clients which don't support pooling etc.=20 This is exactly the point. Building on the John's inputs one possible = solution that I guess meet your requirements and doesn't adversely = impact everybody else could be to make the tariff change AVP a grouped = AVP as follow: Tariff-Change-Info :: < AVP Header: TBD >=20 { Tariff-Time-Change }=20 [ Unlimited-Use-Indication ]=20 The presence of the Unlimited-Use-Indication AVP would mean that the = granted-units MUST be consumed only after the tariff change, before = tariff change the end-user have rights to unlimited use of resources = (i.e. zero-rated). However, the DCC client=20 MUST meter the units used before the tariff change and report those = units to the server associated to the Tariff-Change-Usage with value = UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used after = tariff change are reported). This way there is only a single small = credit reservation to cover the "per MB" case, the main purpose being to = spread the credit re-authorization messages across some time period. There is always the drawback that a small amount of credit need to be = allocated even though the is no certainty that the end-user will consume = after tariff change, but I guess this cannot be avoided whatever = mechanism we select. Do you think would be useful to indicate also the other case, moving = from per MB to zero rate? In this case the Unlimited-Use-Indication = would have two values to indicate whether the unlimited use applies = before or after tariff change. When after tariff change applies, the = client MUST stop using the granted units but MUST continue to meter the = traffic. Credit re-authorization will occur upon Validity-Time expires = and the DCC client MUST report the units used after the tariff change = associated to the Tariff-Change-Usage with value = UNIT_AFTER_TARIFF_CHANGE as usual (of course also the units used before = tariff change are reported). This way there would be one single mechanism and we could optimally = support the extreme case of moves from zero-rate to per MB cost with the = single quota. What do you think? Regards=20 Marco=20 ------_=_NextPart_001_01C3EF0D.42623D06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi = Mark,
 
Mark Watson=20 wrote:
 
>Completely unlimited=20 usage is a rather rare tariff. I was thinking more of the case where a = certain=20 volume is bundled with the users 
>subscription - so=20 there is still a quota of X MB, but this does not require any = reservation to be=20 made from the users account (they've
>already = paid as part=20 of their monthly fee).
 
If  you are = thinking of a=20 case where a user paid X MB as part of the monthly fee I would expect = that these=20 are always X MB regardless the applicable tariff at a given time of the = day, no?=20
Because these X MB = are paid as=20 part of the monthly fee the server would grant a quota of X MB, when = these units=20 have been consumed by the end-user the client report back, those are not = affected by tariff changes. Or do I have totally missunderstood  = your=20 case?
 
>I'm afraid I = can't think of=20 an easy way of adding a dual quota approach as an optional extension = above the=20 existing single quota
>approach. I = think we need=20 to choose one or the other based on which is technically=20 better.
 
I have the same = feeling, but I=20 think also backword compatibility with existing system need to be = considered=20 when making the choice see next point. 
 
> I=20 am not sure that handling separate 'before' and 'after' quotas is any = more=20 complex for a 'simple client' than the single quota
>mechanism - = both keep=20 separate before/after counts, single quota compares before+after with = quota=20 value, dual quota compares
>before with = before-quota=20 and after with after-auota - do you really think it is more complex=20 ?
 
Well, I'm not = thinking it is=20 far more complex. However, I'm somewhat in agreement with John's=20 arguments.
With the dual quota = there is=20 also another small problem that is backword compatibility with existing = systems=20 (not sure we already consider this aspect and I apologize if already = did).=20 Unfortunately we have existing deployments in which the DCC may have to=20 fit
e.g. existing 2.5G = and 3G=20 networks. The DCC server may need to connect to existing IN systems = where the=20 tariff change is implemented according the current draft 02. The = unfortunate DCC=20 server that receive one quota associated to the Tariff switch cannot = convert=20 this into two quotas, or if it does it will not get the wanted result. = I'm not=20 sure we can design the solution as if such systems wouldn't=20 exist.
 
Regards
Marco
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 09 February, 2004=20 14:24
To: Stura Marco (Nokia-NET/Helsinki);=20 'John.Prudhoe@vodafone.com'
Cc: 'aaa-wg@merit.edu'; = Christopher=20 Richards; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: = [AAA-WG]:=20 DCC: Issue: Tariff Change mechanism

Hi Marco.

Completely unlimited usage is a rather rare tariff. = I was=20 thinking more of the case where a certain volume is bundled with the = users=20 subscription - so there is still a quota of X MB, but this does not = require=20 any reservation to be made from the users account (they've already = paid as=20 part of their monthly fee).

I wasn't suggesting that we should link the tariff = change and=20 credit pooling mechansism, but just pointing out that with a dual = quota=20 approach then it is at least *possible* (but not mandatory) to develop = a=20 system which is optimal in terms of avoiding over-reservations and = consequent=20 additional re-authorisations. With a single quota approach this is not = possible.

I'm afraid I can't think of an easy way of adding a = dual quota=20 approach as an optional extension above the existing single quota = approach. I=20 think we need to choose one or the other based on which is technically = better.

I am not sure that handling separate 'before' and = 'after'=20 quotas is any more complex for a 'simple client' than the single quota = mechanism - both keep separate before/after counts, single quota = compares=20 before+after with quota value, dual quota compares before with = before-quota=20 and after with after-auota - do you really think it is more complex=20 ?

Regards...Mark

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: 09 February 2004 11:48 =
To: Watson, Mark [MOP:EP10:EXCH]; = John.Prudhoe@vodafone.com=20
Cc: aaa-wg@merit.edu; Richards, Christopher=20 [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject:=20 RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Mark, John

Mark Watson wrote:

>Also, we have not thought before about the = interaction of=20 tariff time
>changes with credit pooling = - dual=20 quotas interact well with
>credit sharing = because=20 the multipliers allow the 'after tariff change' quota to be shared = with the=20 'before tariff change one' - this

>is the only mechanism which eliminates the=20 over-reservation effect and so is the best possible from the point of = view of=20

>reducing early re-authorisations.

Yes Mark, I guess credit pooling may eliminate the=20 over-reservation effect but I think we cannot force a simple client to = support=20 credit pooling because it supports the tariff time changes, I think = the two=20 mechanisms should not be coupled by any means. However, the tariff = time change=20 mechanism should work same way also in the event that credit pooling = (or in=20 other words independent credit control of multiple services in a DCC=20 (sub-)session)  is supported.

>Having said that, I appreciate the need to keep = things=20 simple for
>clients which don't support = pooling=20 etc.

This is exactly the point. Building on the John's = inputs one=20 possible solution that I guess meet your requirements and doesn't = adversely=20 impact everybody else could be to make the tariff change AVP a = grouped =20 AVP as follow:

        = Tariff-Change-Info=20 :: < AVP Header: TBD >
          &nbs= p;            = ;            = =20 { Tariff-Time-Change }
          &nbs= p;            = ;            = =20 [ Unlimited-Use-Indication ]

The presence of the Unlimited-Use-Indication AVP = would mean=20 that the granted-units MUST be consumed only after the tariff change, = before=20 tariff change the end-user have rights to unlimited use of resources = (i.e.=20 zero-rated). However, the DCC client

MUST meter the units used before the tariff change = and report=20 those units to the server associated to the Tariff-Change-Usage with = value=20 UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used = after tariff=20 change are reported). This way there is only a single small credit = reservation=20 to cover the "per MB" case, the main purpose being to spread the = credit=20 re-authorization messages across some time period.

There is always the drawback that a small amount of = credit=20 need to be allocated even though the is no certainty that the end-user = will=20 consume after tariff change, but I guess this cannot be avoided = whatever=20 mechanism we select.

Do you think would be useful to indicate also the = other case,=20 moving from per MB to zero rate? In this case the = Unlimited-Use-Indication=20 would have two values to indicate whether the unlimited use applies = before or=20 after tariff change. When after tariff change applies, the client MUST = stop=20 using the granted units but MUST continue to meter the traffic. Credit = re-authorization will occur upon Validity-Time expires and the DCC = client MUST=20 report the units used after the tariff change associated to the=20 Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual  = (of=20 course also the units used before tariff change are = reported).

This way there would be one single mechanism and we = could=20 optimally support the extreme case of moves from zero-rate to per MB = cost with=20 the single quota. What do you think?

Regards
Marco=20

------_=_NextPart_001_01C3EF0D.42623D06-- From owner-aaa-wg@merit.edu Mon Feb 9 08:48:38 2004 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 IAA18440 for ; Mon, 9 Feb 2004 08:48:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C7EE91277; Mon, 9 Feb 2004 08:48:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 141F49127A; Mon, 9 Feb 2004 08:48: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 5FE1791277 for ; Mon, 9 Feb 2004 08:48:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EB275DE38; Mon, 9 Feb 2004 08:48: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 6555F5DDB0 for ; Mon, 9 Feb 2004 08:48:18 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i19E0lB32593; Mon, 9 Feb 2004 06:00:47 -0800 Date: Mon, 9 Feb 2004 06:00:47 -0800 (PST) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Another shot at Issue 414: Key AVPs In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3974@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3974@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I think this proposal requires that the NAS send the NAS-Port-Type AVP. Otherwise, how will the AAA server know what which type of key to send? Also, how does the AAA server know what ciphersuite is going to be negotiated? Some ciphersuites might need both keys, some only one. But ciphersuite negotiation can occur *after* the keys are sent. So I'm not clear how the AAA server can figure out which key(s) to send. And if it guesses wrong, the session cannot go forward. From owner-aaa-wg@merit.edu Mon Feb 9 08:55:39 2004 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 IAA19053 for ; Mon, 9 Feb 2004 08:55:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 195F991292; Mon, 9 Feb 2004 08:55:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6B4C91298; Mon, 9 Feb 2004 08:55:07 -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 045DE91292 for ; Mon, 9 Feb 2004 08:55:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9DAA5DF46; Mon, 9 Feb 2004 08:55:01 -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 60AFC5DDCE for ; Mon, 9 Feb 2004 08:55:01 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i19DsvqY021341 for ; Mon, 9 Feb 2004 14:54:57 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 14:54:57 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJFX4XJ>; Mon, 9 Feb 2004 14:55:45 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: DCC typing issues Date: Mon, 9 Feb 2004 14:54:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Feb 2004 13:54:57.0247 (UTC) FILETIME=[4D577EF0:01C3EF14] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pasi, We realized that we haven't answered all your comments, it seems that there are still two of them left. > - 4.1: RFC3588 says that unrecognized AVPs with 'M' bit cause > DIAMETER_AVP_UNSUPPORTED error, not DIAMETER_RATING_FAILED. > If the intent is to override RFC3588, please say so explicitly. The intention of this fault code is to indicate that there is rating specific problem in the CC server side (rating function), for instance some misconfiguration in rating tree, requested service is not supported, or some input is incorrect to rating, etc. We thought that it would be good to have own FC for this purpose. It is not only specific for 'M' bit even though one gets that impression from the draft-02. I propose following changes to the section 4.1: CHANGE FROM: In case a rating input required for the rating process is missing from the Credit control request, or the credit control server does not support the requested service (i.e. does not support one or more Mandatory rating AVPs included in the request command), the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. TO: In case a rating input required for the rating process is incorrect in the Credit control request, or the credit control server does not support the requested service, the Credit control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit control client receiving error code DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar requests in the future. > - 8.8: Cost-Unit is specified as UTF8String without any guidance > to its contents. Will this lead to interoperability (or other) > problems if e.g. one implementation uses "kilobyte" and > another "kB"? (hmm, is this 1000 or 1024 bytes... :-) The Cost-information is intended to provide cost estimation of the requested service to the end user, i.e. it is transparent information for CC clients. The Cost-Unit AVP contains human readable string to display the cost per unit to the end user. But it seems that this information is missing from the draft-02, i.e. the current descriptions under the sections 8.7 Cost-Information AVP and 8.8 Cost-Unit AVP are incomplete and needs updates. I propose following changes to sections 8.7 and 8.8. Section 8.7 Cost-information AVP CHANGES FROM: The Cost-Information AVP (AVP Code 423) is of type Grouped and is used to return the cost information of a service in the Credit-Control- Answer command. The included Unit-Value AVP contains the cost estimate (always type of money) of the service in case of price enquiry or the accumulated cost estimation in the case of credit- control session. TO: The Cost-Information AVP (AVP Code 423) is of type Grouped and is used to return the cost information of the service, which the credit control client can transfer transparently to the end user. The included Unit-Value AVP contains the cost estimate (always type of money) of the service in case of price enquiry or the accumulated cost estimation in the case of credit- control session. Section 8.8 Cost-Unit AVP CHANGES FROM: The Cost-Unit AVP (AVP Code 424) is of type UTF8String and specifies the applicable unit to the Cost-Information when the service cost is a cost per unit (e.g. cost of the service is $1 pe rminute). The Cost- Unit can be for instance minute, hour, day, kilobytes, megabytes etc. TO: The Cost-Unit AVP (AVP Code 424) is of type UTF8String and it is used to display human readable string to the end user. It specifies the applicable unit to the Cost-Information when the service cost is a cost per unit (e.g. cost of the service is $1 per minute). The Cost-Unit can be for instance minute, hour, day, kilobytes, megabytes etc. Regards.........Harri This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Mon Feb 9 09:49:32 2004 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 JAA21800 for ; Mon, 9 Feb 2004 09:49:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 187AE9127C; Mon, 9 Feb 2004 09:48:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC3EA9127D; Mon, 9 Feb 2004 09:48:53 -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 389A49127C for ; Mon, 9 Feb 2004 09:48:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 108FD5DE3C; Mon, 9 Feb 2004 09:48:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 183E55DDF0 for ; Mon, 9 Feb 2004 09:48:50 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19Emi323132; Mon, 9 Feb 2004 14:48:44 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1FPXAA1J>; Mon, 9 Feb 2004 14:48:44 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "Christopher Richards" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 14:48:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF1B.CCF64D38" 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_01C3EF1B.CCF64D38 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Marco, =20 You can imagine a tarrif where X MB of *off-peak* traffic is bundled = into the monthly subscription. It's very common with voice tariffs to have X minutes of off-peak calls. When peak hours start, then you switch to = =88/mb. =20 As for backwards compatibility, I think it's fine to consider backwards compatibility with existing *standards*, but where there are existing proprietary deployments then unless you can accomodate all of them I am = not sure it is a valid consideration for what to standardise. Is it a = particular standard you are looking for backwards compatibility with ? =20 If I receive a single quota from a legacy system I can easily split it = into two with some simple rules which will work reasonably well most of the = time. =20 Conversely, if I receive a dual quota from a legacy system it is not possible for me to combine it into a single one - just adding them = doesn't work. So, it would seem that if you want to accomodate both kinds of legacy = system you should adopt the dual quota approach ;-) =20 Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 09 February 2004 13:05 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Mark, =20 Mark Watson wrote: =20 >Completely unlimited usage is a rather rare tariff. I was thinking = more of the case where a certain volume is bundled with the users=20 >subscription - so there is still a quota of X MB, but this does not = require any reservation to be made from the users account (they've=20 >already paid as part of their monthly fee). =20 If you are thinking of a case where a user paid X MB as part of the = monthly fee I would expect that these are always X MB regardless the applicable tariff at a given time of the day, no?=20 Because these X MB are paid as part of the monthly fee the server would grant a quota of X MB, when these units have been consumed by the = end-user the client report back, those are not affected by tariff changes. Or do = I have totally missunderstood your case? =20 >I'm afraid I can't think of an easy way of adding a dual quota = approach as an optional extension above the existing single quota=20 >approach. I think we need to choose one or the other based on which is technically better. =20 I have the same feeling, but I think also backword compatibility with existing system need to be considered when making the choice see next = point. =20 > I am not sure that handling separate 'before' and 'after' quotas is = any more complex for a 'simple client' than the single quota=20 >mechanism - both keep separate before/after counts, single quota = compares before+after with quota value, dual quota compares=20 >before with before-quota and after with after-auota - do you really = think it is more complex ? =20 Well, I'm not thinking it is far more complex. However, I'm somewhat in agreement with John's arguments. With the dual quota there is also another small problem that is = backword compatibility with existing systems (not sure we already consider this aspect and I apologize if already did). Unfortunately we have existing deployments in which the DCC may have to fit e.g. existing 2.5G and 3G networks. The DCC server may need to connect = to existing IN systems where the tariff change is implemented according = the current draft 02. The unfortunate DCC server that receive one quota associated to the Tariff switch cannot convert this into two quotas, or = if it does it will not get the wanted result. I'm not sure we can design = the solution as if such systems wouldn't exist. =20 Regards Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 09 February, 2004 14:24 To: Stura Marco (Nokia-NET/Helsinki); 'John.Prudhoe@vodafone.com' Cc: 'aaa-wg@merit.edu'; Christopher Richards; Loughney John (Nokia-NRC/Helsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco.=20 Completely unlimited usage is a rather rare tariff. I was thinking more = of the case where a certain volume is bundled with the users subscription = - so there is still a quota of X MB, but this does not require any = reservation to be made from the users account (they've already paid as part of their monthly fee). I wasn't suggesting that we should link the tariff change and credit = pooling mechansism, but just pointing out that with a dual quota approach then = it is at least *possible* (but not mandatory) to develop a system which is = optimal in terms of avoiding over-reservations and consequent additional re-authorisations. With a single quota approach this is not possible. I'm afraid I can't think of an easy way of adding a dual quota approach = as an optional extension above the existing single quota approach. I think = we need to choose one or the other based on which is technically better. I am not sure that handling separate 'before' and 'after' quotas is any = more complex for a 'simple client' than the single quota mechanism - both = keep separate before/after counts, single quota compares before+after with = quota value, dual quota compares before with before-quota and after with after-auota - do you really think it is more complex ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ]=20 Sent: 09 February 2004 11:48=20 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com=20 Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Mark, John=20 Mark Watson wrote:=20 >Also, we have not thought before about the interaction of tariff time=20 >changes with credit pooling - dual quotas interact well with=20 >credit sharing because the multipliers allow the 'after tariff change' quota to be shared with the 'before tariff change one' - this=20 >is the only mechanism which eliminates the over-reservation effect and = so is the best possible from the point of view of=20 >reducing early re-authorisations.=20 Yes Mark, I guess credit pooling may eliminate the over-reservation = effect but I think we cannot force a simple client to support credit pooling because it supports the tariff time changes, I think the two mechanisms should not be coupled by any means. However, the tariff time change mechanism should work same way also in the event that credit pooling = (or in other words independent credit control of multiple services in a DCC (sub-)session) is supported. >Having said that, I appreciate the need to keep things simple for=20 >clients which don't support pooling etc.=20 This is exactly the point. Building on the John's inputs one possible solution that I guess meet your requirements and doesn't adversely = impact everybody else could be to make the tariff change AVP a grouped AVP as follow: Tariff-Change-Info :: < AVP Header: TBD >=20 { Tariff-Time-Change }=20 [ Unlimited-Use-Indication ]=20 The presence of the Unlimited-Use-Indication AVP would mean that the granted-units MUST be consumed only after the tariff change, before = tariff change the end-user have rights to unlimited use of resources (i.e. zero-rated). However, the DCC client=20 MUST meter the units used before the tariff change and report those = units to the server associated to the Tariff-Change-Usage with value UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used after tariff change are reported). This way there is only a single small = credit reservation to cover the "per MB" case, the main purpose being to = spread the credit re-authorization messages across some time period. There is always the drawback that a small amount of credit need to be allocated even though the is no certainty that the end-user will = consume after tariff change, but I guess this cannot be avoided whatever = mechanism we select. Do you think would be useful to indicate also the other case, moving = from per MB to zero rate? In this case the Unlimited-Use-Indication would = have two values to indicate whether the unlimited use applies before or = after tariff change. When after tariff change applies, the client MUST stop = using the granted units but MUST continue to meter the traffic. Credit re-authorization will occur upon Validity-Time expires and the DCC = client MUST report the units used after the tariff change associated to the Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual (of = course also the units used before tariff change are reported). This way there would be one single mechanism and we could optimally = support the extreme case of moves from zero-rate to per MB cost with the single quota. What do you think? Regards=20 Marco=20 ------_=_NextPart_001_01C3EF1B.CCF64D38 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Marco,
 
You=20 can imagine a tarrif where X MB of *off-peak* traffic is bundled into = the=20 monthly subscription. It's very common with voice tariffs to have X = minutes of=20 off-peak calls. When peak hours start, then you switch to=20 =88/mb.
 
As=20 for backwards compatibility, I think it's fine to consider backwards=20 compatibility with existing *standards*, but where there are existing=20 proprietary deployments then unless you can accomodate all of them I am = not sure=20 it is a valid consideration for what to standardise. Is it a particular = standard=20 you are looking for backwards compatibility with ?
 
If I=20 receive a single quota from a legacy system I can easily split it into = two with=20 some simple rules which will work reasonably well most of the=20 time.
 
Conversely, if I receive a dual quota from a legacy system it = is not=20 possible for me to combine it into a single one - just adding them = doesn't=20 work.

So, it would = seem that if you=20 want to accomodate both kinds of legacy system you should adopt the = dual quota=20 approach ;-)
 
Regards...Mark
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: = 09=20 February 2004 13:05
To: Watson, Mark [MOP:EP10:EXCH];=20 John.Prudhoe@vodafone.com
Cc: aaa-wg@merit.edu; Richards,=20 Christopher [RICH2:2Q40:EXCH]; = john.loughney@nokia.com
Subject: RE:=20 [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi = Mark,
 
Mark Watson=20 wrote:
 
>Completely=20 unlimited usage is a rather rare tariff. I was thinking more of the = case where=20 a certain volume is bundled with the users 
>subscription - so=20 there is still a quota of X MB, but this does not require any = reservation to=20 be made from the users account (they've
>already paid as=20 part of their monthly fee).
 
If  you are = thinking of=20 a case where a user paid X MB as part of the monthly fee I would = expect that=20 these are always X MB regardless the applicable tariff at a given = time of the=20 day, no?
Because these X = MB are paid=20 as part of the monthly fee the server would grant a quota of X MB, = when these=20 units have been consumed by the end-user the client report back, = those are not=20 affected by tariff changes. Or do I have totally missunderstood  = your=20 case?
 
>I'm afraid I = can't think=20 of an easy way of adding a dual quota approach as an optional = extension above=20 the existing single quota
>approach. I = think we need=20 to choose one or the other based on which is technically=20 better.
 
I have the same = feeling, but=20 I think also backword compatibility with existing system need to be = considered=20 when making the choice see next point. 
 
> I am not sure that handling separate 'before' and 'after' = quotas is any=20 more complex for a 'simple client' than the single quota =
>mechanism - = both keep=20 separate before/after counts, single quota compares before+after with = quota=20 value, dual quota compares
>before with = before-quota=20 and after with after-auota - do you really think it is more complex=20 ?
 
Well, I'm not = thinking it is=20 far more complex. However, I'm somewhat in agreement with John's=20 arguments.
With the dual = quota there is=20 also another small problem that is backword compatibility with = existing=20 systems (not sure we already consider this aspect and I apologize if = already=20 did). Unfortunately we have existing deployments in which the DCC may = have to=20 fit
e.g. existing = 2.5G and 3G=20 networks. The DCC server may need to connect to existing IN systems = where the=20 tariff change is implemented according the current draft 02. The = unfortunate=20 DCC server that receive one quota associated to the Tariff switch = cannot=20 convert this into two quotas, or if it does it will not get the = wanted result.=20 I'm not sure we can design the solution as if such systems wouldn't=20 exist.
 
Regards
Marco
-----Original Message-----
From: ext Mark Watson = [mailto:mwatson@nortelnetworks.com]
Sent: 09 February, = 2004=20 14:24
To: Stura Marco (Nokia-NET/Helsinki);=20 'John.Prudhoe@vodafone.com'
Cc: 'aaa-wg@merit.edu'; = Christopher=20 Richards; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: = [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco.

Completely unlimited usage is a rather rare = tariff. I was=20 thinking more of the case where a certain volume is bundled with = the users=20 subscription - so there is still a quota of X MB, but this does not = require=20 any reservation to be made from the users account (they've already = paid as=20 part of their monthly fee).

I wasn't suggesting that we should link the = tariff change=20 and credit pooling mechansism, but just pointing out that with a = dual quota=20 approach then it is at least *possible* (but not mandatory) to = develop a=20 system which is optimal in terms of avoiding over-reservations and=20 consequent additional re-authorisations. With a single quota = approach this=20 is not possible.

I'm afraid I can't think of an easy way of adding = a dual=20 quota approach as an optional extension above the existing single = quota=20 approach. I think we need to choose one or the other based on which = is=20 technically better.

I am not sure that handling separate 'before' and = 'after'=20 quotas is any more complex for a 'simple client' than the single = quota=20 mechanism - both keep separate before/after counts, single quota = compares=20 before+after with quota value, dual quota compares before with = before-quota=20 and after with after-auota - do you really think it is more complex = ?

Regards...Mark

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 09 February 2004 11:48 =
To: Watson, Mark [MOP:EP10:EXCH]; = John.Prudhoe@vodafone.com=20
Cc: aaa-wg@merit.edu; Richards, Christopher=20 [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject:=20 RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism


Hi Mark, John

Mark Watson wrote:

>Also, we have not thought before about the = interaction=20 of tariff time
>changes with credit = pooling -=20 dual quotas interact well with
>credit = sharing=20 because the multipliers allow the 'after tariff change' quota to be = shared=20 with the 'before tariff change one' - this

>is the only mechanism which eliminates the=20 over-reservation effect and so is the best possible from the point = of view=20 of

>reducing early re-authorisations.

Yes Mark, I guess credit pooling may eliminate = the=20 over-reservation effect but I think we cannot force a simple client = to=20 support credit pooling because it supports the tariff time changes, = I think=20 the two mechanisms should not be coupled by any means. However, the = tariff=20 time change mechanism should work same way also in the event that = credit=20 pooling (or in other words independent credit control of multiple = services=20 in a DCC (sub-)session)  is supported.

>Having said that, I appreciate the need to = keep things=20 simple for
>clients which don't = support pooling=20 etc.

This is exactly the point. Building on the John's = inputs one=20 possible solution that I guess meet your requirements and doesn't = adversely=20 impact everybody else could be to make the tariff change AVP a = grouped =20 AVP as follow:

       =20 Tariff-Change-Info :: < AVP Header: TBD >
          &nb= sp;           &nb= sp;           &nb= sp;=20 { Tariff-Time-Change }
          &nb= sp;           &nb= sp;           &nb= sp;=20 [ Unlimited-Use-Indication ]

The presence of the Unlimited-Use-Indication AVP = would mean=20 that the granted-units MUST be consumed only after the tariff = change, before=20 tariff change the end-user have rights to unlimited use of = resources (i.e.=20 zero-rated). However, the DCC client

MUST meter the units used before the tariff = change and=20 report those units to the server associated to the = Tariff-Change-Usage with=20 value UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units = used=20 after tariff change are reported). This way there is only a single = small=20 credit reservation to cover the "per MB" case, the main purpose = being to=20 spread the credit re-authorization messages across some time=20 period.

There is always the drawback that a small amount = of credit=20 need to be allocated even though the is no certainty that the = end-user will=20 consume after tariff change, but I guess this cannot be avoided = whatever=20 mechanism we select.

Do you think would be useful to indicate also the = other=20 case, moving from per MB to zero rate? In this case the=20 Unlimited-Use-Indication would have two values to indicate whether = the=20 unlimited use applies before or after tariff change. When after = tariff=20 change applies, the client MUST stop using the granted units but = MUST=20 continue to meter the traffic. Credit re-authorization will occur = upon=20 Validity-Time expires and the DCC client MUST report the units used = after=20 the tariff change associated to the Tariff-Change-Usage with value=20 UNIT_AFTER_TARIFF_CHANGE as usual  (of course also the units = used=20 before tariff change are reported).

This way there would be one single mechanism and = we could=20 optimally support the extreme case of moves from zero-rate to per = MB cost=20 with the single quota. What do you think?

Regards
Marco=20

------_=_NextPart_001_01C3EF1B.CCF64D38-- From owner-aaa-wg@merit.edu Mon Feb 9 09:51:03 2004 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 JAA21831 for ; Mon, 9 Feb 2004 09:51:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBFF19127D; Mon, 9 Feb 2004 09:50:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5AEB9127E; Mon, 9 Feb 2004 09:50: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 44DE29127D for ; Mon, 9 Feb 2004 09:50:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1A1C5DEDF; Mon, 9 Feb 2004 09:50:39 -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 3224D5DEB5 for ; Mon, 9 Feb 2004 09:50:39 -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 i19Eocq19425 for ; Mon, 9 Feb 2004 16:50:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 16:50:37 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 16:50:37 +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]: Another shot at Issue 414: Key AVPs Date: Mon, 9 Feb 2004 16:50:36 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122380@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Another shot at Issue 414: Key AVPs Thread-Index: AcPvE1+YY5ca+X2FRDK+iePBpXhQvwAAjeWw From: To: Cc: X-OriginalArrivalTime: 09 Feb 2004 14:50:37.0511 (UTC) FILETIME=[144B5570:01C3EF1C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > I think this proposal requires that the NAS send the > NAS-Port-Type AVP. Otherwise, how will the AAA server know > what which type of key to send? > > Also, how does the AAA server know what ciphersuite is going > to be negotiated? Some ciphersuites might need both keys, > some only one. But ciphersuite negotiation can occur *after* > the keys are sent. >=20 > So I'm not clear how the AAA server can figure out which > key(s) to send. And if it guesses wrong, the session cannot > go forward. Hmm, yes... if derivation of AAA-Key from MSK depends on=20 the ciphersuite (or at least on link-layer type if not exact ciphersuite), then the AAA server has to know it. This is=20 the case if e.g. AAA-Key has some internal structure=20 with variable-length parts, like MPPE Send/Recv keys. So actually we have this problem already in RADIUS: the AAA server could send different key attributes depending=20 on whether e.g. EAP-TLS is used for MPPE or 802.11i. It seems that current AAA servers don't care about this, and always send 64 bytes of keying material (?). 802.11i will use=20 only half of that (first 32 bytes or Recv key), and if I=20 understood RFC3079 right (?), MPPE will also use half, but=20 it's bytes 0..15 and 32..47 (first 16 bytes of Recv/Send keys=20 each). If we can assume that all AAA servers do this, then we could live with the single 64-byte AVP that draft -03 has. (When translating from RADIUS to Diameter, just concatenate the 32-byte Recv/Send keys, and split the key when translating back.) However, it seems that when using MPPE the AAA server could actually send only the first 16 bytes of MS-MPPE-Recv/Send keys; and then translation gets difficult... is this a concern, or could we assume that AAA-Key is always exactly 64 octets? (or does not have variable-length internal structure) BR, Pasi From owner-aaa-wg@merit.edu Mon Feb 9 10:02:48 2004 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 KAA22098 for ; Mon, 9 Feb 2004 10:02:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A82549127E; Mon, 9 Feb 2004 10:01:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FB1291281; Mon, 9 Feb 2004 10:01:31 -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 5CADB9127E for ; Mon, 9 Feb 2004 10:01:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26F1B5DEBA; Mon, 9 Feb 2004 10:01:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id D6B465DE10 for ; Mon, 9 Feb 2004 10:01:26 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i19F1QAh023087 for ; Mon, 9 Feb 2004 16:01:26 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 16:01:25 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJFYMTD>; Mon, 9 Feb 2004 16:02:14 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , Christopher Richards , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 16:01:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF1D.878D9BC5" X-OriginalArrivalTime: 09 Feb 2004 15:01:25.0963 (UTC) FILETIME=[96CD41B0:01C3EF1D] 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_01C3EF1D.878D9BC5 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 Is it a particular standard you are looking for backwards compatibility w= ith ? For instance in case of 3GPP, the OCS (i.e. CC server) supports CAP v.3 t= owards SGSN and I think that it is not good to force one server to support two different TSw mech= anisms, one mechanism for access node and another mechanism for gateway node.=20 =20 regards...........Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Mark Watson Sent: 9. helmikuuta 2004 16:49 To: 'marco.stura@nokia.com'; 'John.Prudhoe@vodafone.com' Cc: 'aaa-wg@merit.edu'; Christopher Richards; 'john.loughney@nokia.com' Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco, =20 You can imagine a tarrif where X MB of *off-peak* traffic is bundled into= the monthly subscription. It's very common with voice tariffs to have X = minutes of off-peak calls. When peak hours start, then you switch to =88/= mb. =20 As for backwards compatibility, I think it's fine to consider backwards c= ompatibility with existing *standards*, but where there are existing prop= rietary deployments then unless you can accomodate all of them I am not s= ure it is a valid consideration for what to standardise. Is it a particul= ar standard you are looking for backwards compatibility with ? =20 If I receive a single quota from a legacy system I can easily split it in= to two with some simple rules which will work reasonably well most of the= time. =20 Conversely, if I receive a dual quota from a legacy system it is not poss= ible for me to combine it into a single one - just adding them doesn't wo= rk. So, it would seem that if you want to accomodate both kinds of legacy sys= tem you should adopt the dual quota approach ;-) =20 Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 09 February 2004 13:05 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.lough= ney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Mark, =20 Mark Watson wrote: =20 >Completely unlimited usage is a rather rare tariff. I was thinking more = of the case where a certain volume is bundled with the users=20 >subscription - so there is still a quota of X MB, but this does not requ= ire any reservation to be made from the users account (they've=20 >already paid as part of their monthly fee). =20 If you are thinking of a case where a user paid X MB as part of the mont= hly fee I would expect that these are always X MB regardless the applicab= le tariff at a given time of the day, no?=20 Because these X MB are paid as part of the monthly fee the server would g= rant a quota of X MB, when these units have been consumed by the end-user= the client report back, those are not affected by tariff changes. Or do = I have totally missunderstood your case? =20 >I'm afraid I can't think of an easy way of adding a dual quota approach = as an optional extension above the existing single quota=20 >approach. I think we need to choose one or the other based on which is t= echnically better. =20 I have the same feeling, but I think also backword compatibility with exi= sting system need to be considered when making the choice see next point.= =20 =20 > I am not sure that handling separate 'before' and 'after' quotas is any= more complex for a 'simple client' than the single quota=20 >mechanism - both keep separate before/after counts, single quota compare= s before+after with quota value, dual quota compares=20 >before with before-quota and after with after-auota - do you really thin= k it is more complex ? =20 Well, I'm not thinking it is far more complex. However, I'm somewhat in a= greement with John's arguments. With the dual quota there is also another small problem that is backword = compatibility with existing systems (not sure we already consider this as= pect and I apologize if already did). Unfortunately we have existing depl= oyments in which the DCC may have to fit e.g. existing 2.5G and 3G networks. The DCC server may need to connect to= existing IN systems where the tariff change is implemented according the= current draft 02. The unfortunate DCC server that receive one quota asso= ciated to the Tariff switch cannot convert this into two quotas, or if it= does it will not get the wanted result. I'm not sure we can design the s= olution as if such systems wouldn't exist. =20 Regards Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 09 February, 2004 14:24 To: Stura Marco (Nokia-NET/Helsinki); 'John.Prudhoe@vodafone.com' Cc: 'aaa-wg@merit.edu'; Christopher Richards; Loughney John (Nokia-NRC/He= lsinki) Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Marco.=20 Completely unlimited usage is a rather rare tariff. I was thinking more o= f the case where a certain volume is bundled with the users subscription = - so there is still a quota of X MB, but this does not require any reserv= ation to be made from the users account (they've already paid as part of = their monthly fee). I wasn't suggesting that we should link the tariff change and credit pool= ing mechansism, but just pointing out that with a dual quota approach the= n it is at least *possible* (but not mandatory) to develop a system which= is optimal in terms of avoiding over-reservations and consequent additio= nal re-authorisations. With a single quota approach this is not possible.= I'm afraid I can't think of an easy way of adding a dual quota approach a= s an optional extension above the existing single quota approach. I think= we need to choose one or the other based on which is technically better.= I am not sure that handling separate 'before' and 'after' quotas is any m= ore complex for a 'simple client' than the single quota mechanism - both = keep separate before/after counts, single quota compares before+after wit= h quota value, dual quota compares before with before-quota and after wit= h after-auota - do you really think it is more complex ? Regards...Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com ]=20 Sent: 09 February 2004 11:48=20 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com=20 Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.lough= ney@nokia.com=20 Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism=20 Hi Mark, John=20 Mark Watson wrote:=20 >Also, we have not thought before about the interaction of tariff time=20= >changes with credit pooling - dual quotas interact well with=20 >credit sharing because the multipliers allow the 'after tariff change' q= uota to be shared with the 'before tariff change one' - this=20 >is the only mechanism which eliminates the over-reservation effect and s= o is the best possible from the point of view of=20 >reducing early re-authorisations.=20 Yes Mark, I guess credit pooling may eliminate the over-reservation effec= t but I think we cannot force a simple client to support credit pooling b= ecause it supports the tariff time changes, I think the two mechanisms sh= ould not be coupled by any means. However, the tariff time change mechani= sm should work same way also in the event that credit pooling (or in othe= r words independent credit control of multiple services in a DCC (sub-)se= ssion) is supported. >Having said that, I appreciate the need to keep things simple for=20 >clients which don't support pooling etc.=20 This is exactly the point. Building on the John's inputs one possible sol= ution that I guess meet your requirements and doesn't adversely impact ev= erybody else could be to make the tariff change AVP a grouped AVP as fol= low: Tariff-Change-Info :: < AVP Header: TBD >=20 { Tariff-Time-Change }=20 [ Unlimited-Use-Indication ]=20 The presence of the Unlimited-Use-Indication AVP would mean that the gran= ted-units MUST be consumed only after the tariff change, before tariff ch= ange the end-user have rights to unlimited use of resources (i.e. zero-ra= ted). However, the DCC client=20 MUST meter the units used before the tariff change and report those units= to the server associated to the Tariff-Change-Usage with value UNIT_BEFO= RE_TARIFF_CHANGE as usual (of course also the units used after tariff cha= nge are reported). This way there is only a single small credit reservati= on to cover the "per MB" case, the main purpose being to spread the credi= t re-authorization messages across some time period. There is always the drawback that a small amount of credit need to be all= ocated even though the is no certainty that the end-user will consume aft= er tariff change, but I guess this cannot be avoided whatever mechanism w= e select. Do you think would be useful to indicate also the other case, moving from= per MB to zero rate? In this case the Unlimited-Use-Indication would hav= e two values to indicate whether the unlimited use applies before or afte= r tariff change. When after tariff change applies, the client MUST stop u= sing the granted units but MUST continue to meter the traffic. Credit re-= authorization will occur upon Validity-Time expires and the DCC client MU= ST report the units used after the tariff change associated to the Tariff= -Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual (of course al= so the units used before tariff change are reported). This way there would be one single mechanism and we could optimally suppo= rt the extreme case of moves from zero-rate to per MB cost with the singl= e quota. What do you think? Regards=20 Marco=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. ------_=_NextPart_001_01C3EF1D.878D9BC5 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Mark,
 
Is=20 it a particular standard you are looking for backwards compatibility with= =20 ?
For instance in case of 3GPP, the OCS (i.e. CC serve= r)=20 supports CAP v.3 towards SGSN and I=20 think
that=20 it is not good to force one server to support two different=20 TSw mechanisms,
one=20 mechanism for access node and another mechanism for gateway=20 node. 
 
regards...........Harri
-----Original Message-----
From: owner-aaa-wg@merit.= edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Mark Watson
Se= nt:=20 9. helmikuuta 2004 16:49
To: 'marco.stura@nokia.com';=20 'John.Prudhoe@vodafone.com'
Cc: 'aaa-wg@merit.edu'; Christoph= er=20 Richards; 'john.loughney@nokia.com'
Subject: RE: [AAA-WG]: DC= C:=20 Issue: Tariff Change mechanism

Hi=20 Marco,
 
You can imagine a tarrif where X MB of *off-peak* traffic is b= undled=20 into the monthly subscription. It's very common with voice tariffs to h= ave X=20 minutes of off-peak calls. When peak hours start, then you switch to=20= =88/mb.
 
As=20 for backwards compatibility, I think it's fine to consider backwards=20= compatibility with existing *standards*, but where there are existing=20= proprietary deployments then unless you can accomodate all of them I am= not=20 sure it is a valid consideration for what to standardise. Is it a parti= cular=20 standard you are looking for backwards compatibility with=20 ?
 
If=20 I receive a single quota from a legacy system I can easily split it int= o two=20 with some simple rules which will work reasonably well most of the=20 time.
 
Conversely, if I receive a dual quota from a legacy system it = is not=20 possible for me to combine it into a single one - just adding them does= n't=20 work.

So, it would see= m that if you=20 want to accomodate both kinds of legacy system you should adopt the dua= l quota=20 approach ;-)
 
Regards...Mark
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent:= 09=20 February 2004 13:05
To: Watson, Mark [MOP:EP10:EXCH];=20 John.Prudhoe@vodafone.com
Cc: aaa-wg@merit.edu; Richards,=20= Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject:= =20 RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi=20 Mark,
&n= bsp;
Mark Watson=20 wrote:
&n= bsp;
>Compl= etely=20 unlimited usage is a rather rare tariff. I was thinking more of the c= ase=20 where a certain volume is bundled with the users 
>subsc= ription -=20 so there is still a quota of X MB, but this does not require any rese= rvation=20 to be made from the users account (they've
>alrea= dy paid as=20 part of their monthly fee).
 
If  you are= thinking=20 of a case where a user paid X MB as part of the monthly fee I would e= xpect=20 that these are always X MB regardless the applicable tariff at a give= n time=20 of the day, no?
Because these X = MB are paid=20 as part of the monthly fee the server would grant a quota of X MB, wh= en=20 these units have been consumed by the end-user the client report back= , those=20 are not affected by tariff changes. Or do I have totally=20 missunderstood  your case?
 
>I'm afraid I= can't=20 think of an easy way of adding a dual quota approach as an optional=20= extension above the existing single quota
>approach. I = think we=20 need to choose one or the other based on which is technically=20 better.
&n= bsp;
I have the same = feeling,=20 but I think also backword compatibility with existing system need to = be=20 considered when making the choice see next point. =
&n= bsp;
> = ;I am not sure that handling separate 'before' and 'after' qu= otas is=20 any more complex for a 'simple client' than the single quota=20
>mechanism - = both keep=20 separate before/after counts, single quota compares before+after with= quota=20 value, dual quota compares
>before with=20= before-quota and after with after-auota - do you really think it is m= ore=20 complex ?
&n= bsp;
Well, I'm not th= inking it=20 is far more complex. However, I'm somewhat in agreement with John's=20= arguments.
With the dual qu= ota there=20 is also another small problem that is backword compatibility with exi= sting=20 systems (not sure we already consider this aspect and I apologize if = already=20 did). Unfortunately we have existing deployments in which the DCC may= have=20 to fit
e.g. existing 2.= 5G and 3G=20 networks. The DCC server may need to connect to existing IN systems w= here=20 the tariff change is implemented according the current draft 02. The=20= unfortunate DCC server that receive one quota associated to the Tarif= f=20 switch cannot convert this into two quotas, or if it does it will not= get=20 the wanted result. I'm not sure we can design the solution as if such= =20 systems wouldn't exist.
&n= bsp;
Regards
Marco
-----Original Message-----
From: ext Mark Watson= =20 [mailto:mwatson@nortelnetworks.com]
Sent: 09 February, 20= 04=20 14:24
To: Stura Marco (Nokia-NET/Helsinki);=20 'John.Prudhoe@vodafone.com'
Cc: 'aaa-wg@merit.edu'; Chris= topher=20 Richards; Loughney John (Nokia-NRC/Helsinki)
Subject: RE:= =20 [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco.

Completely unlimited usage is a rather rare tarif= f. I was=20 thinking more of the case where a certain volume is bundled with th= e users=20 subscription - so there is still a quota of X MB, but this does not= =20 require any reservation to be made from the users account (they've = already=20 paid as part of their monthly fee).

I wasn't suggesting that we should link the tarif= f change=20 and credit pooling mechansism, but just pointing out that with a du= al=20 quota approach then it is at least *possible* (but not mandatory) t= o=20 develop a system which is optimal in terms of avoiding over-reserva= tions=20 and consequent additional re-authorisations. With a single quota ap= proach=20 this is not possible.

I'm afraid I can't think of an easy way of adding= a dual=20 quota approach as an optional extension above the existing single q= uota=20 approach. I think we need to choose one or the other based on which= is=20 technically better.

I am not sure that handling separate 'before' and= 'after'=20 quotas is any more complex for a 'simple client' than the single qu= ota=20 mechanism - both keep separate before/after counts, single quota co= mpares=20 before+after with quota value, dual quota compares before with=20 before-quota and after with after-auota - do you really think it is= more=20 complex ?

Regards...Mark

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com<= /A>]=20
Sent: 09 February 2004 11:48
<= FONT=20 size=3D2>To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.co= m=20
Cc: aaa-wg@merit.edu; Richards, Christopher=20 [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism= =20


Hi Mark, John

Mark Watson wrote:

>Also, we have not thought before about the in= teraction=20 of tariff time
>changes with credit po= oling -=20 dual quotas interact well with
>credit= sharing=20 because the multipliers allow the 'after tariff change' quota to be= shared=20 with the 'before tariff change one' - this

>is the only mechanism which eliminates the=20= over-reservation effect and so is the best possible from the point = of view=20 of

>reducing early re-authorisations.

=

Yes Mark, I guess credit pooling may eliminate th= e=20 over-reservation effect but I think we cannot force a simple client= to=20 support credit pooling because it supports the tariff time changes,= I=20 think the two mechanisms should not be coupled by any means. Howeve= r, the=20 tariff time change mechanism should work same way also in the event= that=20 credit pooling (or in other words independent credit control of mul= tiple=20 services in a DCC (sub-)session)  is supported.

>Having said that, I appreciate the need to ke= ep things=20 simple for
>clients which don't suppor= t pooling=20 etc.

This is exactly the point. Building on the John's= inputs=20 one possible solution that I guess meet your requirements and doesn= 't=20 adversely impact everybody else could be to make the tariff change = AVP a=20 grouped  AVP as follow:

       =20 Tariff-Change-Info :: < AVP Header: TBD >
         &nbs= p;            = ;            =  =20 { Tariff-Time-Change }
         &nbs= p;            = ;            =  =20 [ Unlimited-Use-Indication ]

The presence of the Unlimited-Use-Indication AVP = would=20 mean that the granted-units MUST be consumed only after the tariff = change,=20 before tariff change the end-user have rights to unlimited use of=20= resources (i.e. zero-rated). However, the DCC client

MUST meter the units used before the tariff chang= e and=20 report those units to the server associated to the Tariff-Change-Us= age=20 with value UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the u= nits=20 used after tariff change are reported). This way there is only a si= ngle=20 small credit reservation to cover the "per MB" case, the main purpo= se=20 being to spread the credit re-authorization messages across some ti= me=20 period.

There is always the drawback that a small amount = of credit=20 need to be allocated even though the is no certainty that the end-u= ser=20 will consume after tariff change, but I guess this cannot be avoide= d=20 whatever mechanism we select.

Do you think would be useful to indicate also the= other=20 case, moving from per MB to zero rate? In this case the=20 Unlimited-Use-Indication would have two values to indicate whether = the=20 unlimited use applies before or after tariff change. When after tar= iff=20 change applies, the client MUST stop using the granted units but MU= ST=20 continue to meter the traffic. Credit re-authorization will occur u= pon=20 Validity-Time expires and the DCC client MUST report the units used= after=20 the tariff change associated to the Tariff-Change-Usage with value=20= UNIT_AFTER_TARIFF_CHANGE as usual  (of course also the units u= sed=20 before tariff change are reported).

This way there would be one single mechanism and = we could=20 optimally support the extreme case of moves from zero-rate to per M= B cost=20 with the single quota. What do you think?

Regards
Marco=20=


This communication is = confidential and intended solely for the addressee(s). Any unauthorized r= eview, use, disclosure or distribution is prohibited. If you believe this= message has been sent to you in error, please notify the sender by reply= ing to this transmission and delete the message without disclosing it. Th= ank you.

E-mail including attachments is susceptible to data corru= ption, interruption, unauthorized amendment, tampering and viruses, and w= e only send and receive e-mails on the basis that we are not liable for a= ny such corruption, interception, amendment, tampering or viruses or any = consequences thereof.
------_=_NextPart_001_01C3EF1D.878D9BC5-- From owner-aaa-wg@merit.edu Mon Feb 9 10:34:11 2004 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 KAA24070 for ; Mon, 9 Feb 2004 10:34:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19A84912A5; Mon, 9 Feb 2004 10:32:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E30BB912A4; Mon, 9 Feb 2004 10:32:57 -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 86737912A2 for ; Mon, 9 Feb 2004 10:32:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 607225DD91; Mon, 9 Feb 2004 10:32:52 -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 6B33F5DD8D for ; Mon, 9 Feb 2004 10:32:51 -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 i19FWoq22849 for ; Mon, 9 Feb 2004 17:32:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 17:32:49 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 17:32:48 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 17:32:48 +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="Windows-1251" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 17:32:49 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B042A@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPvG9P1USG43wEfQ7SljlJG1MoLwAAADzTA From: To: , Cc: , , X-OriginalArrivalTime: 09 Feb 2004 15:32:48.0448 (UTC) FILETIME=[F8D9AC00:01C3EF21] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mark, >You can imagine a tarrif where X MB of *off-peak* traffic is bundled = into the monthly subscription. It's very common with voice=20 >tariffs to have X minutes of off-peak calls. When peak hours start, = then you switch to =88/mb. OK, now your case is more clear and yes I misunderstood it. But I still = think that a good co-ordination with the validity time can solve this, = of course not the way you want and still with over-reservation effect. = However, it seems that all those involved in this discussion have agreed = that your proposal may optimize this extreme cases but will make the = general case worse. The only benefit I can see with the dual quota mechanism is when it is = used in conjunction with credit pooling. Is that what you want to = achieve? I mean you want to be able to use the dual quota mechanism when = credit pooling feature is supported? >As for backwards compatibility, I think it's fine to consider backwards = compatibility with existing *standards*, but where there=20 >are existing proprietary deployments then unless you can accomodate all = of them I am not sure it is a valid consideration for=20 >what to standardise. Is it a particular standard you are looking for = backwards compatibility with ? I thought it was clear from my answer, I was talking about IN systems = that are not proprietary deployments. I never mentioned about = proprietary deployments Mark. >If I receive a single quota from a legacy system I can easily split it = into two with some simple rules which will work reasonably=20 >well most of the time. Yes, but if you receive a single quota associated with the tariff switch = (i.e. according to the CAMEL mechanism) from an IN legacy system the = credit have been reserved according to the worst case. So, you can split = the quota according to whatever rule but you will defeat your objective = of avoiding over-reservation. Not only, but you will exacerbate the = problem of early credit re-authorization. >Conversely, if I receive a dual quota from a legacy system it is not = possible for me to combine it into a single one - just adding=20 >them doesn't work. What standard are you now looking for? Regards Marco From owner-aaa-wg@merit.edu Mon Feb 9 10:42:28 2004 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 KAA24434 for ; Mon, 9 Feb 2004 10:42:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5264F912A6; Mon, 9 Feb 2004 10:40:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCF9F912A8; Mon, 9 Feb 2004 10:40: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 73D57912A6 for ; Mon, 9 Feb 2004 10:40:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 609C85DDF1; Mon, 9 Feb 2004 10:40:48 -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 C1E9F5DDFC for ; Mon, 9 Feb 2004 10:40:41 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Mon, 9 Feb 2004 15:44:57 +0000 To: Cc: aaa-wg@merit.edu, crich@nortelnetworks.com, john.loughney@nokia.com, John.Prudhoe@vodafone.com, mwatson@nortelnetworks.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John.Prudhoe@vodafone.com Date: Mon, 9 Feb 2004 15:40:32 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 02/09/2004 03:40:34 PM, Serialize complete at 02/09/2004 03:40:34 PM Content-Type: multipart/alternative; boundary="=_alternative 00561B0180256E35_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00561B0180256E35_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marco, I've also come to the opinion that the best solution to this particular=20 case is to make clever use of validity time. Regards, John. 09/02/2004 15:32 =20 To: , cc: , , Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Mark, >You can imagine a tarrif where X MB of *off-peak* traffic is bundled into= the monthly subscription. It's very common with voice=20 >tariffs to have X minutes of off-peak calls. When peak hours start, then= you switch to =80/mb. OK, now your case is more clear and yes I misunderstood it. But I still=20 think that a good co-ordination with the validity time can solve this, of= course not the way you want and still with over-reservation effect.=20 However, it seems that all those involved in this discussion have agreed=20 that your proposal may optimize this extreme cases but will make the=20 general case worse. The only benefit I can see with the dual quota mechanism is when it is=20 used in conjunction with credit pooling. Is that what you want to achieve?= I mean you want to be able to use the dual quota mechanism when credit=20 pooling feature is supported? >As for backwards compatibility, I think it's fine to consider backwards=20 compatibility with existing *standards*, but where there=20 >are existing proprietary deployments then unless you can accomodate all=20 of them I am not sure it is a valid consideration for=20 >what to standardise. Is it a particular standard you are looking for=20 backwards compatibility with ? I thought it was clear from my answer, I was talking about IN systems that= are not proprietary deployments. I never mentioned about proprietary=20 deployments Mark. >If I receive a single quota from a legacy system I can easily split it=20 into two with some simple rules which will work reasonably=20 >well most of the time. Yes, but if you receive a single quota associated with the tariff switch=20 (i.e. according to the CAMEL mechanism) from an IN legacy system the=20 credit have been reserved according to the worst case. So, you can split=20 the quota according to whatever rule but you will defeat your objective of= avoiding over-reservation. Not only, but you will exacerbate the problem= of early credit re-authorization. >Conversely, if I receive a dual quota from a legacy system it is not=20 possible for me to combine it into a single one - just adding=20 >them doesn't work. What standard are you now looking for? Regards Marco ***************************************************************************= *** 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 ***************************************************************************= *** --=_alternative 00561B0180256E35_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Marco,

I've also come to the opinion that the be= st solution to this particular case is to make clever use of validity time.=

Regards,

John.




<marco.stura@nokia.com>=

09/02/2004 15:32

       
        To: &nbs= p;      <mwatson@nortelnetworks.com>, <John.Prudhoe= @vodafone.com>
        cc: &nbs= p;      <aaa-wg@merit.edu>, <crich@nortelnetworks.c= om>, <john.loughney@nokia.com>
        Subject:=        RE: [AAA-WG]: DCC: Issue: Tariff Change mechani= sm



Hi Mark,

>You can imagine a tarrif where X MB of *off-peak* traffic is bundled in= to the monthly subscription. It's very common with voice
>tariffs to have X minutes of off-peak calls. When peak hours start, the= n you switch to =80/mb.

OK, now your case is more clear and yes I misunderstood it. But I still thi= nk that a good co-ordination with the validity time can solve this, of cour= se not the way you want and still with over-reservation effect. However, it= seems that all those involved in this discussion have agreed that your pro= posal may optimize this extreme cases but will make the general case worse.=

The only benefit I can see with the dual quota mechanism is when it is used= in conjunction with credit pooling. Is that what you want to achieve? I me= an you want to be able to use the dual quota mechanism when credit pooling = feature is supported?

>As for backwards compatibility, I think it's fine to consider backwards= compatibility with existing *standards*, but where there
>are existing proprietary deployments then unless you can accomodate all= of them I am not sure it is a valid consideration for
>what to standardise. Is it a particular standard you are looking for ba= ckwards compatibility with ?

I thought it was clear from my answer, I was talking about IN systems that = are not proprietary deployments. I never mentioned about proprietary deploy= ments Mark.

>If I receive a single quota from a legacy system I can easily split it = into two with some simple rules which will work reasonably
>well most of the time.

Yes, but if you receive a single quota associated with the tariff switch (i= .e. according to the CAMEL mechanism) from an IN legacy system the credit h= ave been reserved according to the worst case. So, you can split the quota = according to whatever rule but you will defeat your objective of avoiding o= ver-reservation. Not only, but you will exacerbate the problem of early cre= dit re-authorization.

>Conversely, if I receive a dual quota from a legacy system it is not po= ssible for me to combine it into a single one - just adding
>them doesn't work.

What standard are you now looking for?

Regards
Marco



***************************************************************************= ***

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 00561B0180256E35_=-- From owner-aaa-wg@merit.edu Mon Feb 9 10:49:39 2004 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 KAA24733 for ; Mon, 9 Feb 2004 10:49:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EDB491281; Mon, 9 Feb 2004 10:49:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC37C91282; Mon, 9 Feb 2004 10:49: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 1497891281 for ; Mon, 9 Feb 2004 10:49:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC6A75DDF1; Mon, 9 Feb 2004 10:49:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 727075DE60 for ; Mon, 9 Feb 2004 10:49:13 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19Fn8n11440; Mon, 9 Feb 2004 15:49:08 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1FPXACAB>; Mon, 9 Feb 2004 15:49:08 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "Christopher Richards" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 15:49:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF24.3CCD366E" 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_01C3EF24.3CCD366E Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Marco, Ok, so we are talking about backwards compatibility with existing = standards - that's fine. >The only benefit I can see with the dual quota mechanism is when it is = used in conjunction with credit pooling. There is also a benefit without credit pooling which is that the server = has complete control over the size of the 'over-reservation' (and so on the extent of the early re-authorisation effect). By contrast, with a = single quota the size of the over-reservation is dependent on the rate = differential and the size of the reservation itself and the amount the client = actually uses before the tariff change. >I mean you want to be able to use the dual quota mechanism when credit pooling feature is supported? That seems to be the only way to avoid over-reservations, so I would = like this to be possible in the standard, but not mandatory. >>If I receive a single quota from a legacy system I can easily split = it=20 >>into two with some simple rules which will work reasonably >>well most of the time. >Yes, but if you receive a single quota associated with the tariff = switch (i.e. according to the CAMEL mechanism) from an > IN legacy system the credit have been reserved according to the worst case. So, you can split the quota according to=20 > whatever rule but you will defeat your objective of avoiding over-reservation. Not only, but you will exacerbate the problem=20 > of early credit re-authorization. The over-reservation exists anyway because of the single quota = mechanism. Its size depends on the three factors mentioned above. Splitting it = does indeed place a lower bound on the size of the over-reservation i.e. = things may be worse, but they will not be better. But I am comparing with the converse case where it is just *not possible* to combine a dual quota = into a single one. >What standard are you now looking for? 3GPP Release 5 IMS online charging, for example. Regards, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 09 February 2004 15:33 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Mark, >You can imagine a tarrif where X MB of *off-peak* traffic is bundled=20 >into the monthly subscription. It's very common with voice >tariffs to have X minutes of off-peak calls. When peak hours start, = then you switch to =88/mb. OK, now your case is more clear and yes I misunderstood it. But I still think that a good co-ordination with the validity time can solve this, = of course not the way you want and still with over-reservation effect. = However, it seems that all those involved in this discussion have agreed that = your proposal may optimize this extreme cases but will make the general case worse. The only benefit I can see with the dual quota mechanism is when it is = used in conjunction with credit pooling. Is that what you want to achieve? I = mean you want to be able to use the dual quota mechanism when credit pooling feature is supported? >As for backwards compatibility, I think it's fine to consider = backwards=20 >compatibility with existing *standards*, but where there >are existing proprietary deployments then unless you can accomodate = all of them I am not sure it is a valid consideration for=20 >what to standardise. Is it a particular standard you are looking for backwards compatibility with ? I thought it was clear from my answer, I was talking about IN systems = that are not proprietary deployments. I never mentioned about proprietary deployments Mark. >If I receive a single quota from a legacy system I can easily split it = >into two with some simple rules which will work reasonably >well most of the time. Yes, but if you receive a single quota associated with the tariff = switch (i.e. according to the CAMEL mechanism) from an IN legacy system the = credit have been reserved according to the worst case. So, you can split the = quota according to whatever rule but you will defeat your objective of = avoiding over-reservation. Not only, but you will exacerbate the problem of = early credit re-authorization. >Conversely, if I receive a dual quota from a legacy system it is not=20 >possible for me to combine it into a single one - just adding >them doesn't work. What standard are you now looking for? Regards Marco ------_=_NextPart_001_01C3EF24.3CCD366E Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco,

Ok, so we are talking about backwards compatibility = with existing standards - that's fine.

>The only benefit I can see with the dual quota = mechanism is when it is used in conjunction with credit pooling.

There is also a benefit without credit pooling which = is that the server has complete control over the size of the = 'over-reservation' (and so on the extent of the early re-authorisation = effect). By contrast, with a single quota the size of the = over-reservation is dependent on the rate differential and the size of = the reservation itself and the amount the client actually uses before = the tariff change.

>I mean you want to be able to use the dual quota = mechanism when credit pooling feature is supported?

That seems to be the only way to avoid = over-reservations, so I would like this to be possible in the standard, = but not mandatory.

>>If I receive a single quota from a legacy = system I can easily split it
>>into two with some simple rules which will = work reasonably
>>well most of the time.

>Yes, but if you receive a single quota associated = with the tariff switch (i.e. according to the CAMEL mechanism) from = an

> IN legacy system the credit have been reserved = according to the worst case. So, you can split the quota according to =
> whatever rule but you will defeat your = objective of avoiding over-reservation. Not only, but you will = exacerbate the problem

> of early credit re-authorization.

The over-reservation exists anyway because of the = single quota mechanism. Its size depends on the three factors mentioned = above. Splitting it does indeed place a lower bound on the size of the = over-reservation i.e. things may be worse, but they will not be better. = But I am comparing with the converse case where it is just *not = possible* to combine a dual quota into a single one.

>What standard are you now looking for?

3GPP Release 5 IMS online charging, for = example.

Regards,

Mark

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 09 February 2004 15:33
To: Watson, Mark [MOP:EP10:EXCH]; = John.Prudhoe@vodafone.com
Cc: aaa-wg@merit.edu; Richards, Christopher = [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change = mechanism


Hi Mark,

>You can imagine a tarrif where X MB of *off-peak* = traffic is bundled
>into the monthly subscription. It's very common = with voice
>tariffs to have X minutes of off-peak calls. = When peak hours start, then you switch to =88/mb.

OK, now your case is more clear and yes I = misunderstood it. But I still think that a good co-ordination with the = validity time can solve this, of course not the way you want and still = with over-reservation effect. However, it seems that all those involved = in this discussion have agreed that your proposal may optimize this = extreme cases but will make the general case worse.

The only benefit I can see with the dual quota = mechanism is when it is used in conjunction with credit pooling. Is = that what you want to achieve? I mean you want to be able to use the = dual quota mechanism when credit pooling feature is = supported?

>As for backwards compatibility, I think it's fine = to consider backwards
>compatibility with existing *standards*, but = where there
>are existing proprietary deployments then unless = you can accomodate all of them I am not sure it is a valid = consideration for

>what to standardise. Is it a particular standard = you are looking for backwards compatibility with ?

I thought it was clear from my answer, I was talking = about IN systems that are not proprietary deployments. I never = mentioned about proprietary deployments Mark.

>If I receive a single quota from a legacy system = I can easily split it
>into two with some simple rules which will work = reasonably
>well most of the time.

Yes, but if you receive a single quota associated = with the tariff switch (i.e. according to the CAMEL mechanism) from an = IN legacy system the credit have been reserved according to the worst = case. So, you can split the quota according to whatever rule but you = will defeat your objective of avoiding over-reservation. Not only, but = you will exacerbate the problem of early credit = re-authorization.

>Conversely, if I receive a dual quota from a = legacy system it is not
>possible for me to combine it into a single one = - just adding
>them doesn't work.

What standard are you now looking for?

Regards
Marco


------_=_NextPart_001_01C3EF24.3CCD366E-- From owner-aaa-wg@merit.edu Mon Feb 9 13:22:01 2004 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 NAA01753 for ; Mon, 9 Feb 2004 13:22:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95A77912A9; Mon, 9 Feb 2004 13:17:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFD7A912BC; Mon, 9 Feb 2004 13:17:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78A28912A4 for ; Mon, 9 Feb 2004 13:15:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 513FA5DD9E; Mon, 9 Feb 2004 13:15:23 -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 46B8E5DD98 for ; Mon, 9 Feb 2004 13:15:22 -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 i19IFKq25220 for ; Mon, 9 Feb 2004 20:15:21 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 20:15:20 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 20:15:20 +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_01C3EF38.ADE995E9" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 20:15:21 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C83C2@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism Thread-Index: AcPvJEeMVDBIQ9IHSumYw6T18KBg8QACuGng From: To: , Cc: , , X-OriginalArrivalTime: 09 Feb 2004 18:15:20.0071 (UTC) FILETIME=[AD454170:01C3EF38] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EF38.ADE995E9 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: quoted-printable Hi Mark, John, all =20 John P. wrote: =20 > I've also come to the opinion that the best solution to this = particular case is to make clever use of validity time.=20 =20 I agree, the mechanism for the basic DCC functionality of single service = (or single quota support) should then be kept as it is. =20 =20 Mark Watson wrote: >>I mean you want to be able to use the dual quota mechanism when credit = pooling feature is supported?=20 >That seems to be the only way to avoid over-reservations, so I would = like this to be possible in the standard, but not mandatory. Fine. So, why not to define the dual quota in the context of the = independent credit control for multiple services feature? I mean, = client/server that implement support for the independent credit control = for multiple services should support the dual quota mechanism. In other = words, the dual quota for tariff changes would be a functionality = within the independent credit control of multiple services feature, the = server may use it if so wanted.=20 So, the only mechanism to support with the basic functionality in case = of single service (or single quota) support is the one described in = draft 02 i.e. single quota. Where independent credit control of multiple = services feature is supported, then the dual quota should be supported = as well because it can leverage the credit pooling capabilities to avoid = over-reservation etc. (i.e. let use the mechanism where it makes more = sense to use it). The tariff switch mechanism is of course not used for = time based services in any case as already agreed. Basically, what I propose is to enhance the structure of the = Multiple-Services-Credit-Control AVP of the updated proposal to issue 16 = (the one we are working offline as announced, I apologize for those who = didn't see the update yet) with the Tariff-Change-Usage AVP that would = be used only in CCA messages and indicates whether the quota is for = consumption before tariff change or after tariff change. The presence of = the Tariff-Change-Usage implies the presence of the Tariff-Time-Change = AVP in the G-S-U AVP. The structure would looks=20 Multiple-Services-Credit-Control ::=3D < AVP Header: tbd >=20 [ Granted-Service-Unit ] =20 [ Requested-Service-Units ]=20 *[ Used-Service-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 [ Tariff-Change-Usage ] *[ G-S-U-Pool-Reference ]=20 [ Validity-Time ]=20 [ Result-Code ]=20 [ Final-Unit-Indication ]=20 This is my proposa, let see what other people think about the proposal. = If there is agreement, I guess we could include this in our update of = the issue 16 that I hope will be able to publish in the few coming = days. >3GPP Release 5 IMS online charging, for example. =20 That is defined for IMS that is actually doing, and can only do, time = based credit control and it only requires the basic DCC application = functionalities for the single service/quota. However, we already agreed = that there is no need for any tariff switch mechanism for the time based = services since the server is in full power to control the tariff = changes, in fact there are pending CRs for the removal of the mechanism. = So, I feel the alignment should happen this way, not the other way = round. =20 Regards Marco ------_=_NextPart_001_01C3EF38.ADE995E9 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism
Hi Mark, John,=20 all
 
John P.=20 wrote:
 
> I've also come = to the=20 opinion that the best solution to this particular case is to make clever = use of=20 validity time.
 
I agree, the mechanism for the = basic DCC=20 functionality of single service (or single quota support) = should then be=20 kept
as it is.  =
 
Mark Watson=20 wrote:

>>I mean = you want to=20 be able to use the dual quota mechanism when credit pooling feature is=20 supported?

>That seems = to be the=20 only way to avoid over-reservations, so I would like this to be possible = in the=20 standard, but not mandatory.

Fine. So, why not to = define the=20 dual quota in the context of the independent credit control for multiple = services feature? I mean, client/server that implement support for the=20 independent credit control for multiple services should support the = dual=20 quota mechanism. In other words, the dual quota for tariff changes would = be a  functionality within the independent credit control of = multiple=20 services feature, the server may use it if so = wanted. 

So, the only = mechanism to support=20 with the basic functionality in case of single service (or single quota) = support=20 is the one described in draft 02 i.e. single quota. Where independent = credit=20 control of multiple services feature is supported, then the dual quota = should be=20 supported as well because it can leverage the credit pooling = capabilities to=20 avoid over-reservation etc. (i.e. let use the mechanism where it makes = more=20 sense to use it). The tariff switch mechanism is of course not used for = time=20 based services in any case as already agreed.

Basically, what I = propose is to=20 enhance the structure of the Multiple-Services-Credit-Control AVP of the = updated=20 proposal to issue 16 (the one we are working offline as announced, I = apologize=20 for those who didn't see the update yet) with the = Tariff-Change-Usage AVP=20 that would be used only in CCA messages and indicates whether the = quota is=20 for consumption before tariff change or after tariff change. The = presence of the=20 Tariff-Change-Usage implies the presence of the Tariff-Time-Change AVP = in the=20 G-S-U AVP.  The structure would looks

 Multiple-Services-Credit-Control ::=3D < AVP = Header: tbd=20 >

           &n= bsp;           &nb= sp;           &nbs= p;    =20 [ Granted-Service-Unit ]  =20

           &n= bsp;           &nb= sp;           &nbs= p;    =20 [ Requested-Service-Units ]

           &n= bsp;           &nb= sp;           &nbs= p;   =20 *[ Used-Service-Units ]

           &n= bsp;           &nb= sp;           &nbs= p;   =20 *[ Service-Identifier ]

           &n= bsp;           &nb= sp;           &nbs= p;    =20 [ Rating-Group ]

       &nbs= p;            = ;            =          [=20 Tariff-Change-Usage ]

           &n= bsp;           &nb= sp;           &nbs= p;   =20 *[ G-S-U-Pool-Reference ]

           &n= bsp;           &nb= sp;           &nbs= p;    =20 [ Validity-Time ]

           &n= bsp;           &nb= sp;           &nbs= p;    =20 [ Result-Code ]

           &n= bsp;           &nb= sp;       [ Final-Unit-Indication ] =

This is my proposa, let see = what other=20 people think about the proposal.  If there is agreement,  I = guess we=20 could include this in our update of  the issue 16 that I = hope will be=20 able to publish  in the few coming=20 days.

>3GPP Release 5 IMS = online=20 charging, for example.

 
That is defined for = IMS that is=20 actually doing, and can only do, time based credit control and it = only=20 requires the basic DCC application functionalities for the single=20 service/quota. However, we already agreed that there is no need=20 for any = tariff switch=20 mechanism for the time based services since the server is in full power = to=20 control the tariff changes, in fact there are pending CRs for the = removal of the=20 mechanism. So, I feel the alignment should happen this way, not the = other way=20 round.
 
Regards
Marco
------_=_NextPart_001_01C3EF38.ADE995E9-- From owner-aaa-wg@merit.edu Mon Feb 9 15:07:44 2004 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 PAA08093 for ; Mon, 9 Feb 2004 15:07:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D7EC9129D; Mon, 9 Feb 2004 15:07:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5121E9129E; Mon, 9 Feb 2004 15:07: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 547FB9129D for ; Mon, 9 Feb 2004 15:07:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7C705DD98; Mon, 9 Feb 2004 15:07:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id F26FC5DD90 for ; Mon, 9 Feb 2004 15:07:25 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19K7E804467; Mon, 9 Feb 2004 20:07:14 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1FPXAFXD>; Mon, 9 Feb 2004 20:07:15 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , "Christopher Richards" , "'john.loughney@nokia.com'" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Date: Mon, 9 Feb 2004 20:07:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF48.4BA943B6" 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_01C3EF48.4BA943B6 Content-Type: text/plain Hi Marco, all, This seems to work - 2 quotas is still multiple quotas so it makes sense that this is only supported where multiple quotas are supported. Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 09 February 2004 18:15 To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism Hi Mark, John, all John P. wrote: > I've also come to the opinion that the best solution to this particular case is to make clever use of validity time. I agree, the mechanism for the basic DCC functionality of single service (or single quota support) should then be kept as it is. Mark Watson wrote: >>I mean you want to be able to use the dual quota mechanism when credit pooling feature is supported? >That seems to be the only way to avoid over-reservations, so I would like this to be possible in the standard, but not mandatory. Fine. So, why not to define the dual quota in the context of the independent credit control for multiple services feature? I mean, client/server that implement support for the independent credit control for multiple services should support the dual quota mechanism. In other words, the dual quota for tariff changes would be a functionality within the independent credit control of multiple services feature, the server may use it if so wanted. So, the only mechanism to support with the basic functionality in case of single service (or single quota) support is the one described in draft 02 i.e. single quota. Where independent credit control of multiple services feature is supported, then the dual quota should be supported as well because it can leverage the credit pooling capabilities to avoid over-reservation etc. (i.e. let use the mechanism where it makes more sense to use it). The tariff switch mechanism is of course not used for time based services in any case as already agreed. Basically, what I propose is to enhance the structure of the Multiple-Services-Credit-Control AVP of the updated proposal to issue 16 (the one we are working offline as announced, I apologize for those who didn't see the update yet) with the Tariff-Change-Usage AVP that would be used only in CCA messages and indicates whether the quota is for consumption before tariff change or after tariff change. The presence of the Tariff-Change-Usage implies the presence of the Tariff-Time-Change AVP in the G-S-U AVP. The structure would looks Multiple-Services-Credit-Control ::= < AVP Header: tbd > [ Granted-Service-Unit ] [ Requested-Service-Units ] *[ Used-Service-Units ] *[ Service-Identifier ] [ Rating-Group ] [ Tariff-Change-Usage ] *[ G-S-U-Pool-Reference ] [ Validity-Time ] [ Result-Code ] [ Final-Unit-Indication ] This is my proposa, let see what other people think about the proposal. If there is agreement, I guess we could include this in our update of the issue 16 that I hope will be able to publish in the few coming days. >3GPP Release 5 IMS online charging, for example. That is defined for IMS that is actually doing, and can only do, time based credit control and it only requires the basic DCC application functionalities for the single service/quota. However, we already agreed that there is no need for any tariff switch mechanism for the time based services since the server is in full power to control the tariff changes, in fact there are pending CRs for the removal of the mechanism. So, I feel the alignment should happen this way, not the other way round. Regards Marco ------_=_NextPart_001_01C3EF48.4BA943B6 Content-Type: text/html Message
Hi Marco, all,
 
This seems to work - 2 quotas is still multiple quotas so it makes sense that this is only supported where multiple quotas are supported.
 
Regards...Mark
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 09 February 2004 18:15
To: Watson, Mark [MOP:EP10:EXCH]; John.Prudhoe@vodafone.com
Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; john.loughney@nokia.com
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Mark, John, all
 
John P. wrote:
 
> I've also come to the opinion that the best solution to this particular case is to make clever use of validity time.
 
I agree, the mechanism for the basic DCC functionality of single service (or single quota support) should then be kept
as it is. 
 
Mark Watson wrote:

>>I mean you want to be able to use the dual quota mechanism when credit pooling feature is supported?

>That seems to be the only way to avoid over-reservations, so I would like this to be possible in the standard, but not mandatory.

Fine. So, why not to define the dual quota in the context of the independent credit control for multiple services feature? I mean, client/server that implement support for the independent credit control for multiple services should support the dual quota mechanism. In other words, the dual quota for tariff changes would be a  functionality within the independent credit control of multiple services feature, the server may use it if so wanted. 

So, the only mechanism to support with the basic functionality in case of single service (or single quota) support is the one described in draft 02 i.e. single quota. Where independent credit control of multiple services feature is supported, then the dual quota should be supported as well because it can leverage the credit pooling capabilities to avoid over-reservation etc. (i.e. let use the mechanism where it makes more sense to use it). The tariff switch mechanism is of course not used for time based services in any case as already agreed.

Basically, what I propose is to enhance the structure of the Multiple-Services-Credit-Control AVP of the updated proposal to issue 16 (the one we are working offline as announced, I apologize for those who didn't see the update yet) with the Tariff-Change-Usage AVP that would be used only in CCA messages and indicates whether the quota is for consumption before tariff change or after tariff change. The presence of the Tariff-Change-Usage implies the presence of the Tariff-Time-Change AVP in the G-S-U AVP.  The structure would looks

 Multiple-Services-Credit-Control ::= < AVP Header: tbd >

                                         [ Granted-Service-Unit ]  

                                         [ Requested-Service-Units ]

                                        *[ Used-Service-Units ]

                                        *[ Service-Identifier ]

                                         [ Rating-Group ]

                                         [ Tariff-Change-Usage ]

                                        *[ G-S-U-Pool-Reference ]

                                         [ Validity-Time ]

                                         [ Result-Code ]

                               [ Final-Unit-Indication ]

This is my proposa, let see what other people think about the proposal.  If there is agreement,  I guess we could include this in our update of  the issue 16 that I hope will be able to publish  in the few coming days.

>3GPP Release 5 IMS online charging, for example.

 
That is defined for IMS that is actually doing, and can only do, time based credit control and it only requires the basic DCC application functionalities for the single service/quota. However, we already agreed that there is no need for any tariff switch mechanism for the time based services since the server is in full power to control the tariff changes, in fact there are pending CRs for the removal of the mechanism. So, I feel the alignment should happen this way, not the other way round.
 
Regards
Marco
------_=_NextPart_001_01C3EF48.4BA943B6-- From owner-aaa-wg@merit.edu Tue Feb 10 12:49:42 2004 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 MAA00015 for ; Tue, 10 Feb 2004 12:49:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2C3791245; Tue, 10 Feb 2004 12:49:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC5F59124F; Tue, 10 Feb 2004 12:49:05 -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 7DD0A91245 for ; Tue, 10 Feb 2004 12:49:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A9195DDF9; Tue, 10 Feb 2004 12:49:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id E0C905DDE8 for ; Tue, 10 Feb 2004 12:48:59 -0500 (EST) 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_01C3EFFE.2975A1D4" Subject: [AAA-WG]: radius mip? Date: Tue, 10 Feb 2004 12:48:59 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystems.com> Thread-Topic: radius mip? Thread-Index: AcPv/jhMvuwvC2NaSfKbkc1pTWYz8w== From: "Jeremy A. Greene" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EFFE.2975A1D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any radius support for either SA information distributed to the HA, or dynamic key distribution to both the HA and MN. =20 It seems that at least cisco uses radius to distribute SAs to HAs. And they may even do dynamic keying using radius. But I can't find any drafts or rfcs - not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.=20 =20 Jeremy =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3EFFE.2975A1D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In looking at general aaa support = for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any = radius support for either SA information distributed to the HA, or dynamic key = distribution to both the HA and MN.

 

It seems that at least cisco uses = radius to distribute SAs to HAs. And they may even do dynamic keying using = radius. But I can’t find any drafts or rfcs – not that it would be = surprising that cisco did something proprietary. Or call= ing what is reall= y diameter, radius.

 

Jeremy

 

 

 

 

 

 

 

 

 

------_=_NextPart_001_01C3EFFE.2975A1D4-- From owner-aaa-wg@merit.edu Tue Feb 10 17:13:08 2004 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 RAA24005 for ; Tue, 10 Feb 2004 17:13:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42B2B91201; Tue, 10 Feb 2004 17:12:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18AFF91207; Tue, 10 Feb 2004 17:12:54 -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 B378B91201 for ; Tue, 10 Feb 2004 17:12:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 939175DE04; Tue, 10 Feb 2004 17:12:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id 5634B5DDFA for ; Tue, 10 Feb 2004 17:12:52 -0500 (EST) 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_01C3F023.05F94650" Subject: [AAA-WG]: dynamic keys Date: Tue, 10 Feb 2004 17:12:51 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> Thread-Topic: dynamic keys Thread-Index: AcPwIxTdhx83mZF7RMOrbssqEkfOXQ== From: "Jeremy A. Greene" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F023.05F94650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires the use of a single, widely used (by all MNs??), long term pre-shared key between the MN and AAAH. Since this key is directly used to calculate dynamic keys, this does not seem terrible secure. =20 Am I missing something? =20 Jeremy =20 =20 ------_=_NextPart_001_01C3F023.05F94650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the mip4-aaa-key-03 draft (and = aaa-diameter-mobileip-16) it requires the use of a single, widely used (by all MNs??), long = term pre-shared key between the MN and AAAH. Since this key is directly used = to calculate dynamic keys, this does not seem terrible secure.

 

Am I missing = something?

 

Jeremy

 

 

------_=_NextPart_001_01C3F023.05F94650-- From owner-aaa-wg@merit.edu Tue Feb 10 17:39:36 2004 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 RAA26767 for ; Tue, 10 Feb 2004 17:39:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B03E9121D; Tue, 10 Feb 2004 17:39:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 228649121F; Tue, 10 Feb 2004 17:39: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 00C659121D for ; Tue, 10 Feb 2004 17:39:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id E145B5DDDB; Tue, 10 Feb 2004 17:39:01 -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 49C525DDC2 for ; Tue, 10 Feb 2004 17:39:01 -0500 (EST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AMcQ307866; Tue, 10 Feb 2004 16:38:26 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.174.248]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1AMcOW20457; Tue, 10 Feb 2004 16:38:24 -0600 (CST) Message-ID: <40295D5B.6070905@lucent.com> Date: Tue, 10 Feb 2004 16:38:19 -0600 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: aaa-wg@merit.edu, mip4@ietf.org Subject: Re: [AAA-WG]: radius mip? References: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Jeremy, mip4-aaa-key-03 distributes nonces to the mobile. The mobile uses the nonces to derive session keys, such as MN-HA key. The draft does not deal with delivering session keys to the HA (or FA). draft-ietf-aaa-diameter-mobileip-16.txt deals with delivering keys to the HA (and FA), but it only applies to Diameter. ----- 3GPP2 has text in its packet data standard ("Wireless IP Network Standard") for the HA to obtain the MN-HA key from the home RADIUS server. The text defines a RADIUS VSA to carry the MN-HA key, and what's in the RADIUS Access-Request and Access-Accept, for example. -Tom Jeremy A. Greene wrote: > In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 > draft, I am still not clear if there is any radius support for either SA > information distributed to the HA, or dynamic key distribution to both > the HA and MN. > > > > It seems that at least cisco uses radius to distribute SAs to HAs. And > they may even do dynamic keying using radius. But I can’t find any > drafts or rfcs – not that it would be surprising that cisco did > something proprietary. Or calling what is really diameter, radius. > > > > Jeremy > > > > > > > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Feb 10 17:43:00 2004 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 RAA26959 for ; Tue, 10 Feb 2004 17:43:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 358319120A; Tue, 10 Feb 2004 17:42:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 076759120D; Tue, 10 Feb 2004 17:42:46 -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 4CF1E9120A for ; Tue, 10 Feb 2004 17:42:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37E025DDF0; Tue, 10 Feb 2004 17:42:45 -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 D5F1A5DDEF for ; Tue, 10 Feb 2004 17:42:44 -0500 (EST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AMge309568; Tue, 10 Feb 2004 16:42:40 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.174.248]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1AMgdW25173; Tue, 10 Feb 2004 16:42:39 -0600 (CST) Message-ID: <40295E5E.4090600@lucent.com> Date: Tue, 10 Feb 2004 16:42:38 -0600 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: dynamic keys References: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.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 Jeremy, The aaa-keys draft says that the long held secret should be periodically refreshed, but does not say how. - Tom Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires > the use of a single, widely used (by all MNs??), long term pre-shared > key between the MN and AAAH. Since this key is directly used to > calculate dynamic keys, this does not seem terrible secure. > > > > Am I missing something? > > > > Jeremy > > > > > From owner-aaa-wg@merit.edu Tue Feb 10 18:09:17 2004 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 SAA28558 for ; Tue, 10 Feb 2004 18:09:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7AE239120D; Tue, 10 Feb 2004 18:09:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46B119120F; Tue, 10 Feb 2004 18:09: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 05B5F9120D for ; Tue, 10 Feb 2004 18:09:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2C9B5DDE7; Tue, 10 Feb 2004 18:09:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id A51495DDEC for ; Tue, 10 Feb 2004 18:09:01 -0500 (EST) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: dynamic keys Date: Tue, 10 Feb 2004 18:09:00 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166FE@tatara.tatarasystems.com> Thread-Topic: [AAA-WG]: dynamic keys Thread-Index: AcPwJz5FhjyFzgnRQ7WMGF/VxzGqGwAAasRQ From: "Jeremy A. Greene" To: "Tom Hiller" Cc: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable So, a disgruntled, recently dismissed employee still having the aaah key could eavesdrop on a wireless connection to get the nonce and compute the session keys pretty easily, I would think (since the vpn has to come up after the mip session). In general, this seems like a very insecure solution -- why bother going to all the work to make dynamic keys if it's so easy to get them anyway? Jeremy -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Tom Hiller Sent: Tuesday, February 10, 2004 5:43 PM Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [AAA-WG]: dynamic keys Jeremy, The aaa-keys draft says that the long held secret should be periodically refreshed, but does not say how. - Tom Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires=20 > the use of a single, widely used (by all MNs??), long term pre-shared=20 > key between the MN and AAAH. Since this key is directly used to=20 > calculate dynamic keys, this does not seem terrible secure. >=20 > =20 >=20 > Am I missing something? >=20 > =20 >=20 > Jeremy >=20 > =20 >=20 > =20 >=20 From owner-aaa-wg@merit.edu Tue Feb 10 18:14:29 2004 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 SAA29065 for ; Tue, 10 Feb 2004 18:14:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB00A9120F; Tue, 10 Feb 2004 18:14:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6C6B91210; Tue, 10 Feb 2004 18:14: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 1AB969120F for ; Tue, 10 Feb 2004 18:14:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id E6A955DE2B; Tue, 10 Feb 2004 18:14:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id 8BCC15DE1F for ; Tue, 10 Feb 2004 18:14:08 -0500 (EST) 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_01C3F02B.958FE000" Subject: [AAA-WG]: RE: [Mip4] radius mip? Date: Tue, 10 Feb 2004 18:14:08 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166FF@tatara.tatarasystems.com> Thread-Topic: [Mip4] radius mip? Thread-Index: AcPwKDYweLmGfh6/TqaswD4iq7NlXAAAwTVQ From: "Jeremy A. Greene" To: "Kent Leung" Cc: , Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F02B.958FE000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks - as it turns out I managed to find this in cisco's docs. They embed their tacacs+ avps into the radius attribute 26. So that answers the downloading of SAs to HAs. Although I haven't been able to find how they do dynamic key distribution (not that it really matters, since I don't think it's done much anyway, and it seems quite insecure to boot). =20 Jeremy =20 -----Original Message----- From: Kent Leung [mailto:kleung@cisco.com]=20 Sent: Tuesday, February 10, 2004 5:50 PM To: Jeremy A. Greene Cc: aaa-wg@merit.edu; mip4@ietf.org Subject: Re: [Mip4] radius mip? =20 Cisco uses RADIUS Vendor-Specific Attribute (Type 26) to download the SA from AAA server to HA for MN authentication. CDMA2000's IS-835 also uses RADIUS Vendor-Specific Attribute as well. Kent At 12:48 PM 2/10/2004 -0500, Jeremy A. Greene wrote: In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any radius support for either SA information distributed to the HA, or dynamic key distribution to both the HA and MN. =20 It seems that at least cisco uses radius to distribute SAs to HAs. And they may even do dynamic keying using radius. But I can t find any drafts or rfcs not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.=20 =20 Jeremy =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3F02B.958FE000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks – as it turns out I = managed to find this in cisco’s docs. They embed their tacacs+ avps into = the radius attribute 26. So that answers the downloading of SAs to HAs. Although I = haven’t been able to find how they do dynamic key distribution (not that it = really matters, since = I don’t think it’s done much anyway, and it seems quite insecure to = boot).

 

Jeremy

 

-----Original = Message-----
From: Kent Leung [mailto:kleung@cisco.com]
Sent: Tuesday, February = 10, 2004 5:50 PM
To: Jeremy A. Greene
Cc: aaa-wg@merit.edu; mip4@ietf.org
Subject: Re: [Mip4] = radius mip?

 


Cisco uses RADIUS Vendor-Specific Attribute (Type 26) to download the = SA
from AAA server to HA for MN authentication.

CDMA2000's IS-835 also uses RADIUS Vendor-Specific Attribute as = well.

Kent


At 12:48 PM 2/10/2004 -0500, Jeremy A. Greene wrote:


In looking at = general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not = clear if there is any radius support for either SA information distributed to the = HA, or dynamic key distribution to both the HA and MN.

 

It seems that at least cisco uses radius to distribute = SAs to HAs. And they may even do dynamic keying using radius. But I can t find = any drafts or rfcs not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.

 

Jeremy

 

 

 

 

 

 

 

 

 

------_=_NextPart_001_01C3F02B.958FE000-- From owner-aaa-wg@merit.edu Tue Feb 10 19:19:33 2004 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 TAA02592 for ; Tue, 10 Feb 2004 19:19:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A80591212; Tue, 10 Feb 2004 19:19:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA63291213; Tue, 10 Feb 2004 19:19: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 AB80091212 for ; Tue, 10 Feb 2004 19:19:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94BFE5DDD4; Tue, 10 Feb 2004 19:19:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id 574285DDCE for ; Tue, 10 Feb 2004 19:19:13 -0500 (EST) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: RE: [Mip4] dynamic keys Date: Tue, 10 Feb 2004 19:19:11 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwMf6Bv31+Or2lS4m+mScmR6lahAAACzcg From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable So, it doesn't make the initial deployment any easier (if there's one HA), just ongoing use more secure. Each MN needs to be manually configured in some manually intensive secure manner and/or use a proprietary mechanism. I guess I was looking more for a standardized server-side-only (aaa) configuration solution. More like the web, using server-side cert and client-side username/pw (over ssl). Jeremy -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Tuesday, February 10, 2004 7:00 PM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Hi Jeremy, Tuesday 10 February 2004, Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires > the use of a single, widely used (by all MNs??), long term pre-shared > key between the MN and AAAH. Since this key is directly used to > calculate dynamic keys, this does not seem terrible secure. I see no reason why the preshared key between MN and AAAH should be the same for all MNs, rather than individual per-MN? Or is it I who have missed something? Henrik From owner-aaa-wg@merit.edu Tue Feb 10 21:44:25 2004 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 VAA13741 for ; Tue, 10 Feb 2004 21:44:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4244691220; Tue, 10 Feb 2004 21:44:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C22F91221; Tue, 10 Feb 2004 21:44: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 B50EE91220 for ; Tue, 10 Feb 2004 21:44:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1CF75DE30; Tue, 10 Feb 2004 21:44:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id 669865DE1C for ; Tue, 10 Feb 2004 21:44:10 -0500 (EST) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: RE: [Mip4] dynamic keys Date: Tue, 10 Feb 2004 21:44:05 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816701@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwNrUg1E8Mj+b/Tg20yMV8/CHqVgAEZLeQ From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Username/pw can be tied to their existing ones (like existing aaa pw or through MS domain etc.). And username/pws tend to be easier to remember and update. And a md5 key is not the easiest thing to remember or type in. Anyway, it seems that it's a more traditional approach that people have already dealt with in one way or another. This seems like another thing to deal with. Jeremy -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Tuesday, February 10, 2004 7:34 PM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Hi Jeremy, Tuesday 10 February 2004, Jeremy A. Greene wrote: > So, it doesn't make the initial deployment any easier (if there's one > HA), just ongoing use more secure. Each MN needs to be manually > configured in some manually intensive secure manner and/or use a > proprietary mechanism. >=20 > I guess I was looking more for a standardized server-side-only (aaa) > configuration solution. More like the web, using server-side cert and > client-side username/pw (over ssl). But this is the same difference. If you can distribute username/passwd individually to users, you have your initial deployment shared secret, no? Henrik From owner-aaa-wg@merit.edu Tue Feb 10 23:14:19 2004 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 XAA16298 for ; Tue, 10 Feb 2004 23:14:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A0B519122B; Tue, 10 Feb 2004 23:10:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 673D891226; Tue, 10 Feb 2004 23:10: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 81A0991227 for ; Tue, 10 Feb 2004 23:09:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E7675DDEA; Tue, 10 Feb 2004 23:09:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from flora.securenet.com.au (ns1.securenet.com.au [202.125.0.72]) by segue.merit.edu (Postfix) with ESMTP id 4ED525DE34 for ; Tue, 10 Feb 2004 23:09:53 -0500 (EST) Received: from leal.securenet.com.au (leal.isecure.com.au [202.125.0.94] (may be forged)) by flora.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1B490Cr012834; Wed, 11 Feb 2004 15:09:00 +1100 Received: (from root@localhost) by leal.securenet.com.au (8.12.6/8.12.6) id i1B48x1A015016; Wed, 11 Feb 2004 15:08:59 +1100 (EST) Received: from nodnsquery(10.11.3.10) by leal.securenet.com.au via csmap (V6.0) id srcAAA9QaGuD; Wed, 11 Feb 04 15:08:59 +1100 Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i1B48v7Q010143; Wed, 11 Feb 2004 15:08:58 +1100 Received: from AMALTHEA.securenet.com.au ([192.168.100.40]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Feb 2004 15:03:29 +1100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F053.CF17B768" Subject: [AAA-WG]: RE: [Mip4] dynamic keys X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 11 Feb 2004 15:02:04 +1100 Message-ID: <85DA9C6C3DD8C74F8A8611815C635F8D415291@AMALTHEA.securenet.com.au> Thread-Topic: RE: [Mip4] dynamic keys Thread-Index: AcPwNGQIu9gt6lt2QD6giq4WxBxAEAAHjwQg From: "James Jing" To: "Jeremy A. Greene" , "Henrik Levkowetz" Cc: X-OriginalArrivalTime: 11 Feb 2004 04:03:29.0687 (UTC) FILETIME=[01EF1270:01C3F054] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F053.CF17B768 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why can't the session key be dynamically negotiated (say using Diffie-Hellman) together with the Mobile-Node to AAAh (via HA etc) mutual authentication messages?=20 =20 James Jing=20 _____ =20 From: Jeremy A. Greene [mailto:Jeremy@TataraSystems.com]=20 Sent: Wednesday, February 11, 2004 11:19 AM To: Henrik Levkowetz Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: [AAA-WG]: RE: [Mip4] dynamic keys So, it doesn't make the initial deployment any easier (if there's one=20 HA), just ongoing use more secure. Each MN needs to be manually=20 configured in some manually intensive secure manner and/or use a=20 proprietary mechanism.=20 I guess I was looking more for a standardized server-side-only (aaa)=20 configuration solution. More like the web, using server-side cert and=20 client-side username/pw (over ssl).=20 Jeremy=20 -----Original Message-----=20 From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Tuesday, February 10, 2004 7:00 PM=20 To: Jeremy A. Greene=20 Cc: mip4@ietf.org; aaa-wg@merit.edu=20 Subject: Re: [Mip4] dynamic keys=20 Hi Jeremy,=20 Tuesday 10 February 2004, Jeremy A. Greene wrote:=20 > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it=20 requires=20 > the use of a single, widely used (by all MNs??), long term pre-shared=20 > key between the MN and AAAH. Since this key is directly used to=20 > calculate dynamic keys, this does not seem terrible secure.=20 I see no reason why the preshared key between MN and AAAH should be the=20 same for all MNs, rather than individual per-MN? Or is it I who have=20 missed something?=20 Henrik=20 This e-mail, and any attachments hereto, is intended only for use by the named addressee(s) and may contain legally privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments hereto, is strictly prohibited. If you have received this transmission in error, please notify me immediately and permanently delete the original and all copies and printouts of this e-mail. ------_=_NextPart_001_01C3F053.CF17B768 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [AAA-WG]: RE: [Mip4] dynamic keys
Why can't the session key be dynamically = negotiated=20 (say using Diffie-Hellman) together with the Mobile-Node to AAAh (via HA = etc)=20 mutual authentication messages?
 

James Jing

From: Jeremy A. Greene=20 [mailto:Jeremy@TataraSystems.com]
Sent: Wednesday, February = 11, 2004=20 11:19 AM
To: Henrik Levkowetz
Cc: mip4@ietf.org;=20 aaa-wg@merit.edu
Subject: [AAA-WG]: RE: [Mip4] dynamic=20 keys

So, it doesn't make the initial deployment any easier = (if=20 there's one
HA), just ongoing use more secure. = Each MN=20 needs to be manually
configured in some = manually=20 intensive secure manner and/or use a
proprietary=20 mechanism.

I guess I was looking more for a standardized = server-side-only=20 (aaa)
configuration solution. More like the = web, using=20 server-side cert and
client-side username/pw = (over=20 ssl).

Jeremy

-----Original Message-----
From: Henrik=20 Levkowetz [mailto:henrik@levkowetz.com]=20
Sent: Tuesday, February 10, 2004 7:00 = PM=20
To: Jeremy A. Greene
Cc: = mip4@ietf.org;=20 aaa-wg@merit.edu
Subject: Re: [Mip4] dynamic = keys=20

Hi Jeremy,

Tuesday 10 February 2004, Jeremy A. Greene = wrote:=20
> In the mip4-aaa-key-03 draft (and=20 aaa-diameter-mobileip-16) it
requires =
> the use of a single, widely used (by all MNs??), long term = pre-shared
> key between the MN and AAAH. = Since this=20 key is directly used to
> calculate dynamic = keys,=20 this does not seem terrible secure.

I see no reason why the preshared key between MN and = AAAH should=20 be the
same for all MNs, rather than = individual=20 per-MN?  Or is it I who have
missed=20 something?

        Henrik=20
This e-mail, and any attachments hereto, is intended = only for=20 use by the named addressee(s) and may contain legally privileged and/or=20 confidential information.  If you are not the intended recipient, = you are=20 hereby notified that any dissemination, distribution or copying of this = e-mail,=20 and any attachments hereto, is strictly prohibited.  If you have = received=20 this transmission in error, please notify me immediately and permanently = delete=20 the original and all copies and printouts of this=20 e-mail.

------_=_NextPart_001_01C3F053.CF17B768-- From owner-aaa-wg@merit.edu Wed Feb 11 08:34:49 2004 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 IAA00493 for ; Wed, 11 Feb 2004 08:34:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D37D591231; Wed, 11 Feb 2004 08:34:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B4B291232; Wed, 11 Feb 2004 08:34: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 9FD3691231 for ; Wed, 11 Feb 2004 08:34:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 837775DE1C; Wed, 11 Feb 2004 08:34:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id 2BC6A5DE34 for ; Wed, 11 Feb 2004 08:34:32 -0500 (EST) 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_01C3F0A3.C71740D2" Subject: [AAA-WG]: RE: RE: [Mip4] dynamic keys Date: Wed, 11 Feb 2004 08:34:30 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816706@tatara.tatarasystems.com> Thread-Topic: RE: [Mip4] dynamic keys Thread-Index: AcPwNGQIu9gt6lt2QD6giq4WxBxAEAAHjwQgABKHAyA= From: "Jeremy A. Greene" To: "James Jing" , "Henrik Levkowetz" Cc: Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F0A3.C71740D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are two parts to the process. One is to encrypt data and the other is to authenticate the data source. Using Diffe-Hellman does make more sense to me for creating session data encryption keys (I was going to get to that).=20 =20 In the mip spec the same key is used to authenticate and to create session keys (instead of DH). That may be ok, as long as the authentication key is strong and secure (like with PKI). But not sure why DH isn't used anyway. =20 However, to use a username/pw for this purpose seems very insecure (as Henrik suggests in a following email). But, I'm not an expert on this so I will certainly accept whatever has been blessed by the security folks (assuming that's been done?). =20 Jeremy =20 =20 -----Original Message----- From: James Jing [mailto:jjing@betrusted.com]=20 Sent: Tuesday, February 10, 2004 11:02 PM To: Jeremy A. Greene; Henrik Levkowetz Cc: aaa-wg@merit.edu Subject: RE: [Mip4] dynamic keys =20 Why can't the session key be dynamically negotiated (say using Diffie-Hellman) together with the Mobile-Node to AAAh (via HA etc) mutual authentication messages?=20 =20 James Jing=20 _____ =20 From: Jeremy A. Greene [mailto:Jeremy@TataraSystems.com]=20 Sent: Wednesday, February 11, 2004 11:19 AM To: Henrik Levkowetz Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: [AAA-WG]: RE: [Mip4] dynamic keys So, it doesn't make the initial deployment any easier (if there's one=20 HA), just ongoing use more secure. Each MN needs to be manually=20 configured in some manually intensive secure manner and/or use a=20 proprietary mechanism.=20 I guess I was looking more for a standardized server-side-only (aaa)=20 configuration solution. More like the web, using server-side cert and=20 client-side username/pw (over ssl).=20 Jeremy=20 -----Original Message-----=20 From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Tuesday, February 10, 2004 7:00 PM=20 To: Jeremy A. Greene=20 Cc: mip4@ietf.org; aaa-wg@merit.edu=20 Subject: Re: [Mip4] dynamic keys=20 Hi Jeremy,=20 Tuesday 10 February 2004, Jeremy A. Greene wrote:=20 > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it=20 requires=20 > the use of a single, widely used (by all MNs??), long term pre-shared=20 > key between the MN and AAAH. Since this key is directly used to=20 > calculate dynamic keys, this does not seem terrible secure.=20 I see no reason why the preshared key between MN and AAAH should be the=20 same for all MNs, rather than individual per-MN? Or is it I who have=20 missed something?=20 Henrik=20 This e-mail, and any attachments hereto, is intended only for use by the named addressee(s) and may contain legally privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments hereto, is strictly prohibited. If you have received this transmission in error, please notify me immediately and permanently delete the original and all copies and printouts of this e-mail. ------_=_NextPart_001_01C3F0A3.C71740D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [AAA-WG]: RE: [Mip4] dynamic keys

There are two parts to the process. = One is to encrypt data and the other is to authenticate the data source. Using = Diffe-Hellman does make more sense to me for creating session data encryption keys (I = was going to get to that).

 

In the mip spec the same key is = used to authenticate and to create session keys (instead of DH). That may be ok, = as long as the authentication key is strong and secure (like with PKI). But = not sure why DH isn’t used anyway.

 

However, to use a username/pw for = this purpose seems very insecure (as Henrik suggests in a following email). = But, I’m not an expert on this so I will certainly accept whatever has = been blessed by the security folks (assuming that’s been = done?).

 

Jeremy

 

 

-----Original = Message-----
From: James Jing [mailto:jjing@betrusted.com]
Sent: Tuesday, February = 10, 2004 11:02 PM
To: Jeremy A. = Greene; Henrik Levkowetz
Cc: aaa-wg@merit.edu
Subject: RE: [Mip4] = dynamic keys

 

Why can't the = session key be dynamicall= y negotiated (say using Diffie-Hellman) together with the Mobile-Node to AAAh (via HA etc) mutual authentication messages? =

 

James Jing

From: Jeremy A. = Greene [mailto:Jeremy@TataraSystems.com]
Sent: Wednesday, February = 11, 2004 11:19 AM
To: Henrik Levkowetz
Cc: mip4@ietf.org; aaa-wg@merit.edu
Subject: [AAA-WG]: RE: = [Mip4] dynamic keys

So, it doesn't make the initial deployment = any easier (if there's one
HA), just ongoing use = more secure. Each MN needs to be manually
configured in some = manually intensive secure manner and/or use = a
proprietary = mechanism.

I guess I was looking more for a standardized server-side-only (aaa)
configuration solution. = More like the web, using server-side cert and
client-side username/pw (over ssl). =

Jeremy

-----Original Message-----
From: Henrik Levkowetz = [mailto:henrik@levkowetz.com] =
Sent: Tuesday, February = 10, 2004 7:00 PM
To: Jeremy A. Greene
Cc: mip4@ietf.org; = aaa-wg@merit.edu
Subject: Re: [Mip4] = dynamic keys

Hi Jeremy,

Tuesday 10 February 2004, Jeremy A. Greene wrote:
> In the = mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it
requires =
> the use of a = single, widely used (by all MNs??), long term = pre-shared
> key between the MN = and AAAH. Since this key is directly used to
> calculate dynamic = keys, this does not seem terrible secure.

I see no reason why the preshared key between = MN and AAAH should be the
same for = all MNs, rather than individual per-MN?  Or = is it I who have
missed = something?

        = Henrik
This e-mail, and any = attachments hereto, is intended only for use by the named addressee(s) and may = contain legally privileged and/or confidential = information.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any = attachments hereto, is strictly prohibited.  If you have received this = transmission in error, please notify me immediately and permanently delete the original = and all copies and printouts of this = e-mail.

------_=_NextPart_001_01C3F0A3.C71740D2-- From owner-aaa-wg@merit.edu Wed Feb 11 09:52:14 2004 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 JAA03042 for ; Wed, 11 Feb 2004 09:52:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1425791236; Wed, 11 Feb 2004 09:51:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA2FE91237; Wed, 11 Feb 2004 09:51:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF8A791236 for ; Wed, 11 Feb 2004 09:51:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97EB45DE72; Wed, 11 Feb 2004 09:51:48 -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 417575DE0B for ; Wed, 11 Feb 2004 09:51:48 -0500 (EST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BEphr04385; Wed, 11 Feb 2004 08:51:44 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.174.61]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1BEpgd22408; Wed, 11 Feb 2004 08:51:42 -0600 (CST) Message-ID: <402A4179.6090304@lucent.com> Date: Wed, 11 Feb 2004 08:51:37 -0600 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: [Mip4] dynamic keys References: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.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 Jeremy, In 3GPP2 there is an over the air provisioning mechanisms that sets up a TLS connection between the mobile and a trusted provisioning server. The mobile runs http over TLS to get various parameters, including the MN-AAA shared secret. The trusted provisioning system provides this information to the home AAA server of the mobile, too. The trusted provisioning system can run without user intervention, so that mobile station information may be updated. http://www.3gpp2.org/Public_html/specs/C.S0040-0_v1.0_110403.pdf - Tom Jeremy A. Greene wrote: > So, it doesn't make the initial deployment any easier (if there's one > HA), just ongoing use more secure. Each MN needs to be manually > configured in some manually intensive secure manner and/or use a > proprietary mechanism. > > I guess I was looking more for a standardized server-side-only (aaa) > configuration solution. More like the web, using server-side cert and > client-side username/pw (over ssl). > > Jeremy > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, February 10, 2004 7:00 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys > > Hi Jeremy, > > Tuesday 10 February 2004, Jeremy A. Greene wrote: > >>In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it > > requires > >>the use of a single, widely used (by all MNs??), long term pre-shared >>key between the MN and AAAH. Since this key is directly used to >>calculate dynamic keys, this does not seem terrible secure. > > > I see no reason why the preshared key between MN and AAAH should be the > same for all MNs, rather than individual per-MN? Or is it I who have > missed something? > > Henrik From owner-aaa-wg@merit.edu Wed Feb 11 11:50:04 2004 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 LAA09020 for ; Wed, 11 Feb 2004 11:50:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D64DD91244; Wed, 11 Feb 2004 11:49:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3FC991245; Wed, 11 Feb 2004 11:49:39 -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 6531491244 for ; Wed, 11 Feb 2004 11:49:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 534C75DDC7; Wed, 11 Feb 2004 11:49:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id 179585DE96 for ; Wed, 11 Feb 2004 11:49:38 -0500 (EST) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: RE: [Mip4] dynamic keys Date: Wed, 11 Feb 2004 11:49:37 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816721@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwhq/7ub8IzJibRTSkuIumQTV/XgAImNRA From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Not clear on how this would practically work since the server side (aaah) almost definitely will not have access to anything but verifying a text username and password string (say to a MS domain server). But, more importantly, there's a concern in the 802.11, wpa area that touches on this: http://wifinetnews.com/archives/002452.html=20 Jeremy -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, February 11, 2004 5:06 AM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Tuesday 10 February 2004, Jeremy A. Greene wrote: > Username/pw can be tied to their existing ones (like existing aaa pw > or through MS domain etc.). And username/pws tend to be easier to > remember and update. And a md5 key is not the easiest thing to > remember or type in. Anyway, it seems that it's a more traditional > approach that people have already dealt with in one way or another. > This seems like another thing to deal with. I see no reason why a one-time username/password (or a pre-existing one, if it is deemed strong enough), cannot be run through a hash function to give you your initial AAAH-MN key. As long as the hash function is the same at both ends, the entropy of the username/password used as input is sufficient, and the method of distributing the username/password is deemed secure enough for the application in hand, you're home free. There's no reason to bother a user with entering a string of hex digits, for instance.=20 Henrik From owner-aaa-wg@merit.edu Wed Feb 11 16:09:15 2004 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 QAA24123 for ; Wed, 11 Feb 2004 16:09:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 291379128F; Wed, 11 Feb 2004 16:06:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA7D091278; Wed, 11 Feb 2004 16:06: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 420D19128A for ; Wed, 11 Feb 2004 16:06:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B3215DDBB; Wed, 11 Feb 2004 16:06:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from TATARA.TataraSystems.com (unknown [65.213.122.34]) by segue.merit.edu (Postfix) with ESMTP id CB9F65DDC1 for ; Wed, 11 Feb 2004 16:05:59 -0500 (EST) 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_01C3F0E2.D8D32FE0" Subject: [AAA-WG]: RE: [Mip4] dynamic keys Date: Wed, 11 Feb 2004 16:05:58 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPw2RSuPxQ0PVgJQcqJBQutF0JPtQACKI/g From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F0E2.D8D32FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was referring to the offline attacks. Where does it say in the mip-key or diameter-aaa drafts that username/pw would only be used once? =20 From section 5 of the mip-key draft: =20 1. Using the Key Generation Nonce from the extension, the mobile node calculates =20 key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || home address}) ... The secret key used within the HMAC-MD5 computation is indicated by the AAA Security Association indexed by the AAA SPI, which has been previously configured as the basis for the AAA Security Association between the mobile node and the AAA server creating the key material. =20 If I understand what you're suggesting, the aaa-key above would be generated from a username/password on the MN (and HA, somehow). But the text above seems to imply it will be used every time the aaah sends a new nonce to create new 'session' keys. =20 And I still think there's a practical issue of using passwords to create a hash on the MN since the HA won't be able to verify it without the password clear-text to run through the same hash. =20 Sorry if I'm being slow on this, but everything with security is way too confusing! =20 Jeremy =20 -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, February 11, 2004 2:56 PM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys =20 Jeremy, =20 Wednesday 11 February 2004, Jeremy A. Greene wrote: > But, more importantly, there's a concern in the 802.11, wpa area that > touches on this: > http://wifinetnews.com/archives/002452.html=20 =20 No, there's no real similarity here. The concern in this article is that it uses a broken procedure to generate a temporary session key, resulting in eavesdropping being possible, and goes on to discusses offline attacks on the passphrase. Offline attacks on an authenticating password/username combination is not that relevant in a bootstrap scenario where you only use a specific username/password combination once, and any repeated use will be blocked. =20 Henrik ------_=_NextPart_001_01C3F0E2.D8D32FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was referring to the offline attacks. Where does it say in the = mip-key or diameter-aaa drafts that username/pw would only be used = once?

 

From section 5 of the mip-key draft:

 

1. Using the Key Generation = Nonce from the extension, the mobile

    &nbs= p;  node calculates

 

=

    &nbs= p;     key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || = home

    &nbs= p;     address})

...

The secret key used within = the HMAC-MD5 computation is indicated by

   the AAA = Security Association indexed by the AAA SPI, which has been

   previously = configured as the basis for the AAA Security Association

   between the = mobile node and the AAA server creating the key material.

 

If I understand what you’re suggesting, the aaa-key above = would be generated from a username/password on the MN (and HA, somehow). But = the text above seems to imply it will be used every time the aaah sends a new = nonce to create new ‘session’ keys.

 

And I still think there’s a practical issue of using = passwords to create a hash on the MN since the HA won’t be able to verify it = without the password clear-text to run through the same hash.

 

Sorry if I’m being slow on this, but everything with = security is way too confusing!

 

Jeremy

 

-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
Sent: Wednesday, February 11, 2004 2:56 PM
To: Jeremy A. Greene
Cc: mip4@ietf.org; aaa-wg@merit.edu
Subject: Re: [Mip4] dynamic keys

 

Jeremy,

 

Wednesday 11 February 2004, Jeremy A. Greene = wrote:

> But, more importantly, there's a concern in the 802.11, wpa = area that

> touches on this:

> http://wifinetnews.com/archives/002452.html =

 

No, there's no real similarity here.  The concern in this = article is

that it uses a broken procedure to generate a temporary session = key,

resulting in eavesdropping being possible, and goes on to = discusses

offline attacks on the passphrase.  Offline attacks on an authenticating

password/username combination is not that relevant in a = bootstrap

scenario where you only use a specific username/password = combination

once, and any repeated use will be blocked.

 

      Henrik

------_=_NextPart_001_01C3F0E2.D8D32FE0-- From owner-aaa-wg@merit.edu Wed Feb 11 16:58:49 2004 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 QAA00879 for ; Wed, 11 Feb 2004 16:58:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5D3191254; Wed, 11 Feb 2004 16:58:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D6C491255; Wed, 11 Feb 2004 16:58: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 D7AA291254 for ; Wed, 11 Feb 2004 16:58:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF6415DE0B; Wed, 11 Feb 2004 16:58:20 -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 89CB25DE09 for ; Wed, 11 Feb 2004 16:58:20 -0500 (EST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BLwG325736; Wed, 11 Feb 2004 15:58:16 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.171.169]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1BLwEd28137; Wed, 11 Feb 2004 15:58:14 -0600 (CST) Message-ID: <402AA576.9060302@lucent.com> Date: Wed, 11 Feb 2004 15:58:14 -0600 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org, aaa-wg@merit.edu Subject: [AAA-WG]: Re: [Mip4] dynamic keys References: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Jeremy, I'd like to clarify a few things: 1) The MN-AAA shared secret is used more than once 2) It is periodically refreshed 3) It is configured per mobile and is not shared by other mobiles 4) aaa-keys does not say how the key is periodically refreshed. I've acted as the editor, addressing security review comments and other comments from IETF and 3GPP2 folks. Summary: (1) The MN-AAA secret had to be refreshed periodically. That was added to the text. (2) The term "security association" was overloaded; "mobility security association", etc., were added to the text. There was an IANA assignment that did not match earlier text in the draft, and other editorial nits. Those were fixed. - Tom PS In an earlier email, I provided a link to an MN-AAA shared secret provisioning 3GPP2 specification that uses https. A problem with provisioning in cdma2000 is that the mobile may not have an IP address at the time the provisioning server wishes to refresh the shared secret or other data, the phone may have just been purchased, etc., so there are radio network specific scenarios to be specified. Jeremy A. Greene wrote: > I was referring to the offline attacks. Where does it say in the mip-key > or diameter-aaa drafts that username/pw would only be used once? > > > > From section 5 of the mip-key draft: > > > > 1. Using the Key Generation Nonce from the extension, the mobile > > node calculates > > > > key = HMAC-MD5 (AAA-key, {Key Generation Nonce || home > > address}) > > ... > > The secret key used within the HMAC-MD5 computation is indicated by > > the AAA Security Association indexed by the AAA SPI, which has been > > previously configured as the basis for the AAA Security Association > > between the mobile node and the AAA server creating the key material. > > > > If I understand what you’re suggesting, the aaa-key above would be > generated from a username/password on the MN (and HA, somehow). But the > text above seems to imply it will be used every time the aaah sends a > new nonce to create new ‘session’ keys. > > > > And I still think there’s a practical issue of using passwords to create > a hash on the MN since the HA won’t be able to verify it without the > password clear-text to run through the same hash. > > > > Sorry if I’m being slow on this, but everything with security is way too > confusing! > > > > Jeremy > > > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, February 11, 2004 2:56 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys > > > > Jeremy, > > > > Wednesday 11 February 2004, Jeremy A. Greene wrote: > >> But, more importantly, there's a concern in the 802.11, wpa area that > >> touches on this: > >> http://wifinetnews.com/archives/002452.html > > > > No, there's no real similarity here. The concern in this article is > > that it uses a broken procedure to generate a temporary session key, > > resulting in eavesdropping being possible, and goes on to discusses > > offline attacks on the passphrase. Offline attacks on an authenticating > > password/username combination is not that relevant in a bootstrap > > scenario where you only use a specific username/password combination > > once, and any repeated use will be blocked. > > > > Henrik > From owner-aaa-wg@merit.edu Wed Feb 11 16:58:50 2004 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 QAA00880 for ; Wed, 11 Feb 2004 16:58:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D68491256; Wed, 11 Feb 2004 16:58:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF54C91255; Wed, 11 Feb 2004 16:58: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 2973491256 for ; Wed, 11 Feb 2004 16:58:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 122935DE0B; Wed, 11 Feb 2004 16:58:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by segue.merit.edu (Postfix) with ESMTP id C21825DDA1 for ; Wed, 11 Feb 2004 16:58:21 -0500 (EST) Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1BLvT4D028073; Thu, 12 Feb 2004 08:57:29 +1100 Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id i1BLvT5v027725; Thu, 12 Feb 2004 08:57:29 +1100 (EST) Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAAfvayj2; Thu, 12 Feb 04 08:57:29 +1100 Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i1BLvSUu022210; Thu, 12 Feb 2004 08:57:28 +1100 Received: from AMALTHEA.securenet.com.au ([192.168.100.40]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Thu, 12 Feb 2004 08:53:00 +1100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0E9.B63D3050" Subject: [AAA-WG]: RE: [Mip4] dynamic keys X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 12 Feb 2004 08:55:07 +1100 Message-ID: <85DA9C6C3DD8C74F8A8611815C635F8D415293@AMALTHEA.securenet.com.au> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwhPb14Lv730k+TpGRihumhCJ9tQAYFeUQ From: "James Jing" To: "Henrik Levkowetz" Cc: "Jeremy A. Greene" , X-OriginalArrivalTime: 11 Feb 2004 21:53:00.0843 (UTC) FILETIME=[6AEC67B0:01C3F0E9] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F0E9.B63D3050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Henrik, =20 You are right on DH in that on DH does not provide authentication at all. However, the tunnel setup using DH can be mutually authenticated in a separate exchange, like in IPSEC.=20 =20 Provided that HA posseses a certificate, then one can perform key-exchange and HA authentication first, and MN authentication later. For example, MN sends its DH data using the public key of the HA, but the server sends its DH data in the clear, one can at least authenticate the HA in the process and the MN can trust the tunnel to later send it its password (if PAP) or digest. =20 Alternatively, one can employ RSA public key encryption to exchange a MN-generated session key as the same time as authentication is taking place (one can exchange the session key first, then exchange MN authentication). TLS-EAP practically does that.=20 =20 I personally think it is a good idea to relieve the AAA server of problematic involvement in the session encryption key, if possible.=20 =20 James =20 _____ =20 From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, February 11, 2004 8:56 PM To: James Jing Cc: Jeremy A. Greene; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Hi James,=20 Wednesday 11 February 2004, James Jing wrote:=20 > Why can't the session key be dynamically negotiated (say using=20 > Diffie-Hellman) together with the Mobile-Node to AAAh (via HA etc)=20 > mutual authentication messages?=20 If you're talking of the initial bootstrapping MN-AAAH key, a dynamically=20 negotiated session key would make it possible to encrypt the session,=20 but would provide no assurance that either parties have any particular=20 identity - i.e., it gives no Authentication.=20 Henrik=20 This e-mail, and any attachments hereto, is intended only for use by the named addressee(s) and may contain legally privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments hereto, is strictly prohibited. If you have received this transmission in error, please notify me immediately and permanently delete the original and all copies and printouts of this e-mail. ------_=_NextPart_001_01C3F0E9.B63D3050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Mip4] dynamic keys
Hi Henrik,
 
You are right on DH in that on DH does not = provide=20 authentication at all. However, the tunnel setup using DH can be = mutually=20 authenticated in a separate exchange, like in = IPSEC. 
 
Provided that HA posseses a certificate, = then one=20 can perform key-exchange and HA authentication first, and MN = authentication=20 later. For example, MN sends its DH data using the = public key=20 of the HA, but the server sends its DH data in the clear, one can at = least=20 authenticate the HA in the process and the MN can trust the tunnel to = later send=20 it its password (if PAP) or digest.
 
Alternatively, one can employ = RSA public=20 key encryption to exchange a MN-generated session key as the same time = as=20 authentication is taking place (one can exchange the session key first, = then=20 exchange MN authentication). TLS-EAP practically does that. =
 
I personally think it is a good idea to = relieve the AAA=20 server of problematic involvement in the session encryption key, if = possible.
 
James
 

From: Henrik Levkowetz=20 [mailto:henrik@levkowetz.com]
Sent: Wednesday, February 11, = 2004 8:56=20 PM
To: James Jing
Cc: Jeremy A. Greene;=20 aaa-wg@merit.edu
Subject: Re: [Mip4] dynamic = keys

Hi James,

Wednesday 11 February 2004, James Jing wrote: =
> Why can't the session key be dynamically negotiated (say=20 using
> Diffie-Hellman) together with the = Mobile-Node=20 to AAAh (via HA etc)
> mutual = authentication=20 messages?

If you're talking of the initial bootstrapping MN-AAAH = key, a=20 dynamically
negotiated session key would make = it=20 possible to encrypt the session,
but would = provide no=20 assurance that either parties have any particular
identity - i.e., it gives no Authentication.

        Henrik

This e-mail, and any attachments hereto, is intended = only for=20 use by the named addressee(s) and may contain legally privileged and/or=20 confidential information.  If you are not the intended recipient, = you are=20 hereby notified that any dissemination, distribution or copying of this = e-mail,=20 and any attachments hereto, is strictly prohibited.  If you have = received=20 this transmission in error, please notify me immediately and permanently = delete=20 the original and all copies and printouts of this=20 e-mail.

------_=_NextPart_001_01C3F0E9.B63D3050-- From owner-aaa-wg@merit.edu Thu Feb 12 03:17:02 2004 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 DAA13784 for ; Thu, 12 Feb 2004 03:17:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3DE791266; Thu, 12 Feb 2004 03:16:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B342891267; Thu, 12 Feb 2004 03:16:46 -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 8CE7991266 for ; Thu, 12 Feb 2004 03:16:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id B61E05DDE0; Thu, 12 Feb 2004 03:16:42 -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 DD9685DEC0 for ; Thu, 12 Feb 2004 03:16:36 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C8EPv07575 for ; Thu, 12 Feb 2004 10:16:02 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Feb 2004 10:14:22 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 10:14:23 +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]: FW: 59th IETF - AAA Date: Thu, 12 Feb 2004 10:14:22 +0200 Message-ID: Thread-Topic: 59th IETF - AAA Thread-Index: AcPvNj41QHY1kUpGTdqEI5Hz24MEoQCCcz6w From: To: X-OriginalArrivalTime: 12 Feb 2004 08:14:23.0847 (UTC) FILETIME=[39535770:01C3F140] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Here are the currently planned time slot for IETF 59. Could anyone wishing a slot at the meeting please send a request to me, including presenter's name, document title and amount of time needed. thanks, John > This is to confirm that AAA is currently scheduled on=20 > Tuesday, March 2 at 1415-1515 >=20 > Other groups scheduled at that time are: > calsch, newtrk, dna, magma, midcom From owner-aaa-wg@merit.edu Thu Feb 12 04:10:09 2004 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 EAA15481 for ; Thu, 12 Feb 2004 04:10:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8E13D91267; Thu, 12 Feb 2004 04:09:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DCA291269; Thu, 12 Feb 2004 04:09:54 -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 2926991267 for ; Thu, 12 Feb 2004 04:09:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1252F5DEB5; Thu, 12 Feb 2004 04:09:53 -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 533235DEBA for ; Thu, 12 Feb 2004 04:09:52 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C99ov04159 for ; Thu, 12 Feb 2004 11:09:51 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Feb 2004 11:09:45 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 11:09:47 +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]: AAA URI draft Date: Thu, 12 Feb 2004 11:09:46 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF45CDE9@esebe006.ntc.nokia.com> Thread-Topic: AAA URI draft Thread-Index: AcPxR/VpTsvgXcekSsqBhxeI3pQWew== From: To: X-OriginalArrivalTime: 12 Feb 2004 09:09:47.0364 (UTC) FILETIME=[F64BCA40:01C3F147] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi: Just in case you haven't noticed, I submitted a draft whose purpose is = to register with IANA the AAA URI sheme. This came as a result of a = question I sent to the mailing list some time ago, and for which I only = go silence as an answer. http://www.ietf.org/internet-drafts/draft-garcia-aaa-uri-00.txt=20 As usually, comments are welcome. /Miguel --- Miguel A. Garcia tel:+358-50-4804586 =20 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Feb 12 07:59:37 2004 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 HAA21808 for ; Thu, 12 Feb 2004 07:59:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C3439126C; Thu, 12 Feb 2004 07:59:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3D6D9126D; Thu, 12 Feb 2004 07:59: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 8C7809126C for ; Thu, 12 Feb 2004 07:59:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67C675DF68; Thu, 12 Feb 2004 07:59:21 -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 736815DF6B for ; Thu, 12 Feb 2004 07:59:20 -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 i1CCxI316985 for ; Thu, 12 Feb 2004 14:59:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 14:59:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 14:59:13 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 14:59:13 +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]: [Diameter SIP Application] Digest auth-int protection issue Date: Thu, 12 Feb 2004 14:59:12 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF46751B@esebe006.ntc.nokia.com> Thread-Topic: [Diameter SIP Application] Digest auth-int protection issue Thread-Index: AcPxaAKVkPnSYA/bTeKonJAjcmUnNQ== From: To: Cc: , , , , , , , X-OriginalArrivalTime: 12 Feb 2004 12:59:13.0833 (UTC) FILETIME=[03C04190:01C3F168] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi: There has been some discussion in the RADIUS EXT mailing list about an = issue that may affect the Diameter SIP application, due to Radius = compatibility.=20 I would like to get your opinion on the way to move forward. The problem comes from the support of the HTTP Digest authentication in = SIP. If the Digest authentication includes a quality of protection set = to "auth-int", and the Diameter server is authenticating the SIP user, = then the Diameter server needs to receive the entity-body in order to = perform a hash and authenticate the request. We have defined the = SIP-Authentication-Context AVP in the draft to convey this information. As those of you familiar with SIP may know, SIP bodies may be large in = size. They are typically SDP bodies, but could be XML (read: even = larger) if used for, e.g., presence publication. Radius seems to have a maximum message size of 4k. Therefore, most = likely these bodies may not fit into a RADIUS message. The proposal in = draft-sterman-aaa-sip-01 is that instead of transferring the whole = entity-body, which is not actually needed, only the hash of the = entity-body is sent (if MD5 that is 128 bits). The SIP server is = calculating the hash of the entity-body and it sends it to the server. = This saves considerable amount of bandwidth and fis into the RADIUS = messages. It has been proposed that we change the semantics of the = SIP-Authentication-Context AVP in the Diameter SIP application, so that = if the authentication mechanism is Digest with qop=3Dauth-int, then it = conveys the hash of the entity-body rather than the whole body. I find this proposal attractive, since it would make easier the = interoperability with RADIUS systems. I don't think anyone should be = proposing different incompatible interoperable mechanisms. Therefore, if = I don't hear any voice against it, I would propose to adopt this = proposal in the next version of the Diameter SIP application draft (to = be submitted soon). Please, raise your voice if you have some comments. /Miguel --- Miguel A. Garcia tel:+358-50-4804586 =20 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Feb 12 08:24:24 2004 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 IAA22935 for ; Thu, 12 Feb 2004 08:24:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABECB9126D; Thu, 12 Feb 2004 08:24:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DABB9126E; Thu, 12 Feb 2004 08:24: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 1E6879126D for ; Thu, 12 Feb 2004 08:24:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 01D275DF2D; Thu, 12 Feb 2004 08:24:07 -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 476E45DF2A for ; Thu, 12 Feb 2004 08:24:06 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CDO1v09214 for ; Thu, 12 Feb 2004 15:24:01 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 15:23:59 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 15:24:00 +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: [Diameter SIP Application] Digest auth-int protection issue Date: Thu, 12 Feb 2004 15:23:47 +0200 Message-ID: Thread-Topic: [Diameter SIP Application] Digest auth-int protection issue Thread-Index: AcPxaAKVkPnSYA/bTeKonJAjcmUnNQAAXB7Q From: To: , Cc: , , , , , , X-OriginalArrivalTime: 12 Feb 2004 13:24:00.0478 (UTC) FILETIME=[79DC47E0:01C3F16B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Miguel, I think the proposal is reasonable. Would it be possible to keep it even more clear and define the = SIP-Authentication-Context AVP as grouped AVP, which has (at least) two = possible sub-AVPs; one for the entity-body and another for the hash of = the entity-body?=20 E.g. SIP-Authentication-Context :: =3D < AVP Header : TBD > [ Entity-Body] [ Entity-Body-Hash] =20 * [ AVP ] Regards, Kalle=20 > -----Original Message----- > From: Garcia Miguel.An (Nokia-NRC/Helsinki)=20 > Sent: 12 February, 2004 14:59 > To: AAA mailing list (E-mail) > Cc: Miguel-Angel Pallares (E-mail); Mari Carmen Belinchon (E-mail); > 'carolina.canales@ericsson.com'; 'mccap@lucent.com'; Rajaniemi Jaakko > (Nokia-NET/Espoo); Tammi Kalle (Nokia-NET/Tampere); > 'BeckW@t-systems.com'; 'jari.arkko@piuha.net' > Subject: [Diameter SIP Application] Digest auth-int protection issue >=20 >=20 > Hi: >=20 > There has been some discussion in the RADIUS EXT mailing list=20 > about an issue that may affect the Diameter SIP application,=20 > due to Radius compatibility.=20 >=20 > I would like to get your opinion on the way to move forward. >=20 > The problem comes from the support of the HTTP Digest=20 > authentication in SIP. If the Digest authentication includes=20 > a quality of protection set to "auth-int", and the Diameter=20 > server is authenticating the SIP user, then the Diameter=20 > server needs to receive the entity-body in order to perform a=20 > hash and authenticate the request. We have defined the=20 > SIP-Authentication-Context AVP in the draft to convey this=20 > information. >=20 > As those of you familiar with SIP may know, SIP bodies may be=20 > large in size. They are typically SDP bodies, but could be=20 > XML (read: even larger) if used for, e.g., presence publication. >=20 > Radius seems to have a maximum message size of 4k. Therefore,=20 > most likely these bodies may not fit into a RADIUS message.=20 > The proposal in draft-sterman-aaa-sip-01 is that instead of=20 > transferring the whole entity-body, which is not actually=20 > needed, only the hash of the entity-body is sent (if MD5 that=20 > is 128 bits). The SIP server is calculating the hash of the=20 > entity-body and it sends it to the server. This saves=20 > considerable amount of bandwidth and fis into the RADIUS messages. >=20 > It has been proposed that we change the semantics of the=20 > SIP-Authentication-Context AVP in the Diameter SIP=20 > application, so that if the authentication mechanism is=20 > Digest with qop=3Dauth-int, then it conveys the hash of the=20 > entity-body rather than the whole body. >=20 > I find this proposal attractive, since it would make easier=20 > the interoperability with RADIUS systems. I don't think=20 > anyone should be proposing different incompatible=20 > interoperable mechanisms. Therefore, if I don't hear any=20 > voice against it, I would propose to adopt this proposal in=20 > the next version of the Diameter SIP application draft (to be=20 > submitted soon). >=20 > Please, raise your voice if you have some comments. >=20 > /Miguel >=20 > --- > Miguel A. Garcia tel:+358-50-4804586 =20 > Nokia Research Center Helsinki, Finland >=20 From owner-aaa-wg@merit.edu Thu Feb 12 08:40:08 2004 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 IAA23652 for ; Thu, 12 Feb 2004 08:40:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 370F49126E; Thu, 12 Feb 2004 08:39:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00B039126F; Thu, 12 Feb 2004 08:39:53 -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 9795E9126E for ; Thu, 12 Feb 2004 08:39:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CA925DF2D; Thu, 12 Feb 2004 08:39:52 -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 B11745DF2A for ; Thu, 12 Feb 2004 08:39:51 -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 i1CDdov09179 for ; Thu, 12 Feb 2004 15:39:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 15:39:50 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 15:39:50 +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: [Diameter SIP Application] Digest auth-int protection issue Date: Thu, 12 Feb 2004 15:39:49 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF45CDF9@esebe006.ntc.nokia.com> Thread-Topic: [Diameter SIP Application] Digest auth-int protection issue Thread-Index: AcPxaAKVkPnSYA/bTeKonJAjcmUnNQAAXB7QAADy63A= From: To: , Cc: , , , , , , X-OriginalArrivalTime: 12 Feb 2004 13:39:50.0105 (UTC) FILETIME=[AFE1DC90:01C3F16D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable And this is more or less Wolfang Beck's suggestion as a non desired = option... Wolfgang was suggesting just to add a second AVP to carry the digest of = the body. He didn't suggest the grouped AVP though. Wolfgang, any = comment? /Miguel > -----Original Message----- > From: Tammi Kalle (Nokia-NET/Tampere)=20 > Sent: 12 February, 2004 15:24 > To: Garcia Miguel.An (Nokia-NRC/Helsinki); 'aaa-wg@merit.edu' > Cc: 'Miguel-Angel Pallares (E-mail)'; 'Mari Carmen Belinchon=20 > (E-mail)'; > 'carolina.canales@ericsson.com'; 'mccap@lucent.com'; Rajaniemi Jaakko > (Nokia-NET/Espoo); 'BeckW@t-systems.com'; 'jari.arkko@piuha.net' > Subject: RE: [Diameter SIP Application] Digest auth-int=20 > protection issue >=20 >=20 > Hi Miguel, >=20 > I think the proposal is reasonable. >=20 > Would it be possible to keep it even more clear and define=20 > the SIP-Authentication-Context AVP as grouped AVP, which has=20 > (at least) two possible sub-AVPs; one for the entity-body and=20 > another for the hash of the entity-body?=20 >=20 > E.g. >=20 > SIP-Authentication-Context :: =3D < AVP Header : TBD > > [ Entity-Body] > [ Entity-Body-Hash]=09 > =20 > * [ AVP ] >=20 > Regards, > Kalle=20 >=20 > > -----Original Message----- > > From: Garcia Miguel.An (Nokia-NRC/Helsinki)=20 > > Sent: 12 February, 2004 14:59 > > To: AAA mailing list (E-mail) > > Cc: Miguel-Angel Pallares (E-mail); Mari Carmen Belinchon (E-mail); > > 'carolina.canales@ericsson.com'; 'mccap@lucent.com';=20 > Rajaniemi Jaakko > > (Nokia-NET/Espoo); Tammi Kalle (Nokia-NET/Tampere); > > 'BeckW@t-systems.com'; 'jari.arkko@piuha.net' > > Subject: [Diameter SIP Application] Digest auth-int protection issue > >=20 > >=20 > > Hi: > >=20 > > There has been some discussion in the RADIUS EXT mailing list=20 > > about an issue that may affect the Diameter SIP application,=20 > > due to Radius compatibility.=20 > >=20 > > I would like to get your opinion on the way to move forward. > >=20 > > The problem comes from the support of the HTTP Digest=20 > > authentication in SIP. If the Digest authentication includes=20 > > a quality of protection set to "auth-int", and the Diameter=20 > > server is authenticating the SIP user, then the Diameter=20 > > server needs to receive the entity-body in order to perform a=20 > > hash and authenticate the request. We have defined the=20 > > SIP-Authentication-Context AVP in the draft to convey this=20 > > information. > >=20 > > As those of you familiar with SIP may know, SIP bodies may be=20 > > large in size. They are typically SDP bodies, but could be=20 > > XML (read: even larger) if used for, e.g., presence publication. > >=20 > > Radius seems to have a maximum message size of 4k. Therefore,=20 > > most likely these bodies may not fit into a RADIUS message.=20 > > The proposal in draft-sterman-aaa-sip-01 is that instead of=20 > > transferring the whole entity-body, which is not actually=20 > > needed, only the hash of the entity-body is sent (if MD5 that=20 > > is 128 bits). The SIP server is calculating the hash of the=20 > > entity-body and it sends it to the server. This saves=20 > > considerable amount of bandwidth and fis into the RADIUS messages. > >=20 > > It has been proposed that we change the semantics of the=20 > > SIP-Authentication-Context AVP in the Diameter SIP=20 > > application, so that if the authentication mechanism is=20 > > Digest with qop=3Dauth-int, then it conveys the hash of the=20 > > entity-body rather than the whole body. > >=20 > > I find this proposal attractive, since it would make easier=20 > > the interoperability with RADIUS systems. I don't think=20 > > anyone should be proposing different incompatible=20 > > interoperable mechanisms. Therefore, if I don't hear any=20 > > voice against it, I would propose to adopt this proposal in=20 > > the next version of the Diameter SIP application draft (to be=20 > > submitted soon). > >=20 > > Please, raise your voice if you have some comments. > >=20 > > /Miguel > >=20 > > --- > > Miguel A. Garcia tel:+358-50-4804586 =20 > > Nokia Research Center Helsinki, Finland > >=20 >=20 From owner-aaa-wg@merit.edu Thu Feb 12 11:03:00 2004 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 LAA29807 for ; Thu, 12 Feb 2004 11:03:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1468D91270; Thu, 12 Feb 2004 11:02:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D42CD91274; Thu, 12 Feb 2004 11:02:43 -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 DAA0A91270 for ; Thu, 12 Feb 2004 11:02:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C21605DDB8; Thu, 12 Feb 2004 11:02:38 -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 F22AC5DDA2 for ; Thu, 12 Feb 2004 11:02:36 -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 i1CG2av08307 for ; Thu, 12 Feb 2004 18:02:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 18:02:35 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 18:02:35 +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]: DCC: new issue to replace issues 16, 17 and 18 Date: Thu, 12 Feb 2004 18:02:34 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B043A@esebe016.ntc.nokia.com> Thread-Topic: DCC: new issue to replace issues 16, 17 and 18 Thread-Index: AcPxgaBeMUW42cIXTLKkAkMBxa3wAg== From: To: Cc: , , , , , X-OriginalArrivalTime: 12 Feb 2004 16:02:35.0268 (UTC) FILETIME=[A11E0440:01C3F181] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, as agreed in http://www.merit.edu/mail.archives/aaa-wg/msg00176.html and = http://www.merit.edu/mail.archives/aaa-wg/msg00182.html we have beed = working on an updated proposal to issues 16 and 17. The outcome is a new issue to replace issues 16 and 17 that define the = independent credit control of multiple services in a (sub-)session = feature. There will be a following mail with a companion issue to = replace the Flow X of draft 02 according the agreed mechanism. Finally, it was agred in = http://www.merit.edu/mail.archives/aaa-wg/msg00207.html that also the = tariff time change issue (issue 18) can be solved as part of the = independent credit control of multiple services feature. To summarize, this new issue replaces issues 16, 17 and 18. Regards Marco -------------------------------------------------------------------- Description of issue: Independent handling of services within a session=20 Submitter name: Mark Watson/Chris Richards/Marco Stura/Harri Hakala=20 Date first submitted: 12.02.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-02.txt=20 Comment type: T=20 Priority: 1=20 Section: Various=20 Rationale/Explanation of issues:=20 Handling of services or rating groups within a single session or = sub-session=20 can only be done 'en-bloc' according to the grouping of those services = of=20 rating groups into (sub-)sessions by the client. In particular: - all services or rating groups must be re-authorised at the same time=20 - adding an additional service or rating group requires re-authorisation = of all=20 other services/rating groups in the (sub-)session - termination actions, particularly, redirect apply to the whole = (sub-)session=20 - state machine handling applies to the whole (sub-)session=20 This has the following disadvantages:=20 - unnecessary load on the server to perform re-rating for all services = and=20 rating groups, particularly when adding a new service will usually have = no=20 effect on the rating decision for the other services - unnecessary (though less than above) load on the client to process = other=20 services just to add a new one=20 - not possible to leave some services under credit control when others = are=20 terminated/redirected (the policy for how far 'into the red' a service = can run=20 will depend on the service). - when a service or rating group has quotas in multiple units, it is not = possible to have some of those handled independently and others 'pooled' - the construction in which multiple quotas representing the *same* = monetary=20 allocation are passed down from client to server is counter-intuitive = and=20 liable to major mis-interpretation The above restriction stems from the manner in which the 'pooling' of = quotas=20 for multiple services is framed within the protocol. The quotas provided = for=20 different services are not semantically independent and therefore = operations on=20 them must be carried out 'en-bloc'. We propose to make the quotas provided semantically independent within = the=20 protocol, whilst maintaining the concept of a 'credit pool' which can = apply to=20 multiple services across the session. Additionally, as per our other = proposal,=20 we propose to decouple the 'pooling' of credit from the = session/sub-session.=20 Please see the other proposal for the rationale for this. In order to handle quotas within a pool separately, it is necessary to = be more=20 explicit within the protocol about the relationship between quotas. This = is=20 presently communicated implicitly based on the assumption that all = quotas are=20 derived from the same credit reservation in the server. For each service/rating group and unit, we provide a 'Multiplier' value = which=20 is used to express the ratios between services in terms of resource = usage. If service 1 has multiplier M1 and service 2 has multiplier M2 then = resources=20 from service 1 can be converted to those of service 2 by multiplying by = M1/M2. The formula for determining the exhaustion of the credit for a given = pool of=20 quotas at the client is modified as follows: the credit pool is = exhausted when C1*M1 + C2*M2 + ... + Cn*Mn >=3D M=20 Where M is the total credit for the credit-pool. M is initially = calculated from=20 the granted quotas in the pool as follows: M =3D Q1*M1 + Q2*M2 + ... + Qn*Mn=20 This is pretty much equivalent to the existing formula (with Mi =3D = M/Qi), with=20 the following advantages:=20 (i) new services can be added/removed without reference to the existing = ones -=20 M is simply modified by (Quota*Multiplier) for the added/removed service (ii) all quotas returned in CC answers cleanly represent independent=20 authorizations to use the indicated resource=20 (iii) re-authorisation can be sought for an individual service/rating = group=20 (for example if another quota associated with the same service/rating = group is=20 exhausted) (iv) flexibility, low signaling overhead and avoidance of credit = fragmentation=20 are maintained=20 Note that where a Granted-Service-Unit contains more than one resource = unit=20 (e.g. Time and Volume) then multipliers can be provided for one or more = of=20 them. Where two multipliers are provided (e.g. M1t for time and M1v for = volume)=20 then the used resource from the pool is the sum C1t*M1t + C1v*M1v. Note = that=20 the draft at present does not include an explicit description of the = handling=20 of services with more than one resource unit with respect to credit = pooling. Finally, we propose to add the Final-Unit-Indication and Validity-Time = AVPs to=20 the Granted-Service-Unit APV to express independent handling of the = different=20 services in these respects. Requested change:=20 Overview:=20 To implement the above mechanism, we extend the proposal made in Issue = xxx on=20 server control of credit pooling by adding the multiplier to the = G-S-U-Pool- Reference AVP. The multiplier is expressed using the Unit-Value AVP. We therefore add the following AVPs:=20 G-S-U-Pool-Reference AVP - contains a reference to a credit pool, a = unit- type and a multiplier (using the Unit-Value AVP). It is used within = Granted- Service-Units AVP to indicate that credit of a particular type is = pooled. CC-Unit-Type AVP - indicates the type of units (time, volume) that = are=20 pooled.=20 G-S-U-Identifier AVP - identifies the credit pool.=20 Detailed changes: -section 3.1 Credit-Control-Request (CCR) Command=20 FROM: ::=3D < Diameter Header: 272, REQ, PXY >=20 : *[ Requested-Service-Unit ]=20 : *[ Used-Service-Unit ] =20 : TO: ::=3D < Diameter Header: 272, REQ, PXY >=20 : [ Requested-Service-Unit ]=20 : *[ Used-Service-Unit ] =20 [ Multiple-Services-Indicator ] =20 *[ Multiple-Services-Credit-Control ] =20 -Section 3.2 Credit-Control-Answer (CCA) Command=20 FROM: ::=3D < Diameter Header: 272, PXY >=20 : *[ Granted-Service-Unit ] =20 : TO: ::=3D < Diameter Header: 272, PXY >=20 : [ Granted-Service-Unit ] =20 *[ Multiple-Services-Credit-Control] : - Section 5, REMOVE fifth paragraph:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost,=20 making use of credit control sub-sessions will result in increased signaling load and resources usage in both the credit control client and the credit control server. For instance, during one network access session the end user may use several http-services subject to different access cost. To optimally support these scenarios, the credit control application enables for multiple services credit control in a single credit control session. It is possible to request and allocate multiple quotas as a credit pool that is shared between multiple services. The services can be further grouped into rating groups in order to achieve even=20 further aggregation of credit allocation. It is also possible to request and allocate multiple quotas on a per service=20 basis. The mechanism is illustrated in Appendix A (Flow X). ADD new heading "5.1 General Principles" immediately after=20 heading 5. Session Based Credit-control ADD new section 5.1.1 (at the end of the above new 5.1): 5.1.1 Credit-Control for Multiple Services within a (sub-)Session When multiple services are used within one user session and each=20 service or group of services are subject to different cost, it is necessary to perform credit-control for each of these services somewhat independently. Making use of credit control sub-sessions to achieve independent credit-control will result in increased signaling load and resources usage in both the credit control client and the credit control server. For instance, during one network access session the end user may use several http-services subject to different access cost, the network access specific attributes such as the quality of service (QoS) are common to all the services carried within the access bearer, but the cost of the bearer may vary dependent on its content.=20 =20 To optimally support these scenarios, the credit control application enables for independent credit control of multiple services in a single credit control (sub-)session. This is achieved by including the optional Multiple-Services-Credit-=20 Control AVP in Credit-Control-Request/Answer messages. It is possible to request and allocate resources as a credit pool that is shared between multiple services. The services can be further grouped into rating groups in order to achieve even further=20 aggregation of credit allocation. It is also possible to request and allocate quotas on a per service basis. Where quotas are allocated to a pool by means of the Multiple-Services-Credit- Control AVP, the quotas remain independent objects which can be re-authorised independently at any time. Quotas can also be given independent result codes, validity times and Final-Unit- indications. =20 In case independent credit control of multiple services is used the validity-time and final-unit-indication SHOULD only be present either in the Multiple-Service-Credit-Control AVP(s) or at command=20 level as single AVPs. However, the Result-Code AVP MAY be present both on the command level and within the Multiple-Services-Credit-Control AVP. If the Result-Code on the command level indicates other value than SUCCESS then the Result-Code on command level takes precedence over the one(s) included in the Multiple-Services-Credit-Control AVP. The Credit-control client MUST indicate support for independent credit control of multiple services within a (sub-)session by including the Multiple-Services-Indicator AVP in the first interrogation. A Credit-Control-server not supporting the feature MUST treat the Multiple-Services-Indicator AVP and possibly received Multiple-Services-Credit-Control AVPs as=20 invalid AVPs. If the client indicated support for independent credit control of multiple services, a credit-control server that whishes to use the feature MUST return the granted units within the Multiple- Services-Credit-Control AVP associated to the corresponding service-identifier and/or rating-group. To avoid credit fragmentation and unnecessary load on the credit control server, it is possible for service units to be provided=20 to multiple services or rating groups as a pool.=20 This is achieved by providing the service units in the form of a quota for a particular service or rating group in the Multiple- Services-Credit-Control AVP, but also including a reference to a credit pool for that unit type.=20 The reference includes a multiplier derived from the rating parameter, which translates from service units of a specific type to the abstract service units in the pool. For instance if the rating parameter for service 1 is $1/MB and rating parameter for service 2 is $0.5/MB the multipliers could be 10 and 5 for service 1 and service 2 respectively. If M is the total service units within the pool, M1, M2, ... , Mn are the multipliers provided for services 1, 2, ..., n and C1, C2, ... ,Cn are the used resources within the session, then the pool credit is exhausted and re-authorisation MUST be sought when:=20 C1*M1 + C2*M2 + ... + Cn*Mn >=3D M=20 The total credit in the pool, M, is calculated from the quotas which are currently allocated to the pool as follows:=20 M =3D Q1*M1 + Q2*M2 + ... + Qn*Mn =20 =20 If services or rating groups are added to or removed from the pool, then the total credit is adjusted appropriately. Note that when the total credit is adjusted because services or rating groups are removed from the pool, the value that need to be removed is the consumed one (i.e. Cx*Mx). =20 Re-authorisation for an individual service or rating group may be sought at any time, for example if a 'non-pooled' quota is used up or the Validity-Time expires.=20 Where multiple G-S-U-Pool-Reference AVPs with the same G-S-U-Pool=20 Identifier are provided within a Multiple-Services-Credit-Control AVP together with the Granted-Service-Unit AVP, then these MUST have different CC-Unit-Type values and they all draw on the credit pool separately. For instance if one multiplier for time (M1t) and one multiplier for volume (M1v) are given, then the used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t are the time=20 units and C1v are the volume unit.=20 Where service units are provided within a Multiple-Services- Credit-Control AVP without a corresponding G-S-U-Reference AVP then these are handled independently from any credit pool and from any other services or rating groups within the session. The credit pool concept is an optimal tool to avoid the = over-reservation=20 effect of the basic single quota tariff time change mechanism=20 (the mechanism described in section 5.1). Therefore, Diameter credit- control clients and servers implementing the independent credit = control=20 of multiple services SHOULD leverage the credit pool concept when = supporting=20 the tariff time change. The Diameter credit-control server SHOULD = include=20 both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota = allocations in the answer message (i.e. two instances of the = Multiple- Services-Credit-Control AVP). One of the granted units is allocated = to be=20 used before the potential tariff change while the second granted = units=20 are used after a tariff change. Both granted unit quotas MUST contain = the same Service-Identifier and/or Rating-Group values and MUST = belong=20 to the same pool.=20 This dual quota mechanism ensures that the overall reported used = units=20 would never exceed the credit reservation. =20 The Diameter credit-control client reports both the used units before = and after the tariff change in a single instance of the = Multiple-Services -Credit-Control AVP. =20 The failure handling for the credit control session is defined=20 in section 5.6 and reflected to the basic credit-control state=20 machine in section 7. Credit-control client and servers implementing=20 the independent credit control of multiple services in a = (sub-)session=20 functionality MUST ensure a failure handling and general behavior=20 fully consistent with the above mentioned sections while capable of=20 handling parallel ongoing credit re-authorization within a = (sub-)session.=20 It is then RECOMMENDED that Diameter credit-control clients maintain=20 a PENDING-U message queue and restarts the Tx timer every time a=20 CCR[Update] message is sent while in PENDING-U state. When answers=20 to all the pending messages are received the state machine moves to=20 OPEN and Tx is stopped. Naturally the action performed when a problem = is detected for the session according to section 5.6, affect all the=20 ongoing services (e.g. failover to a backup server if possible affect = all the CCR[Update] messages in the PENDING-U queue). Since the client may send CCR[Update] messages while in PENDING-U=20 (i.e. without waiting for an answer to ongoing credit = re-authorization),=20 the time space between these requests may be very short and the = server=20 may not have received the previous request(s) yet. Therefore in this=20 situation the server may receive out of sequence requests and SHOULD = NOT=20 consider this as an error condition, a proper answer is to be = returned=20 to each of those requests. -Section 5.4 Server-Initiated Credit Re-Authorization FROM The Diameter Credit Control Application supports the server-initiated = re-authorization. The credit control server MAY optionally initiate the = credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in = the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in the = RAR message is set to 4 to indicate the Diameter Credit Control = Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. If a credit re-authorization is not already ongoing (i.e. the credit = control session is in OPEN state), a credit control client that receives = such a RAR message with Session-Id equal to a currently active credit = control session acknowledges the request by sending the Re-Auth-Answer = (RAA) message and MUST initiate the credit re-authorization towards the = server by sending a Credit-Control-Request message with the = CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code = 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to = indicate an additional message (i.e. CCR[Update]) is required to = complete the procedure. If a quota was allocated to the session, the = credit control client MUST report the used quota in the = Credit-Control-Request. Note that the end user does not need to be = prompted for the credit re-authorization, since the credit = re-authorization is transparent to the user (i.e it takes place = exclusively between the credit control client and the credit control = server). If credit re-authorization is ongoing at the time when the RAR message = is received (i.e. RAR-CCR collision), the credit control client = successfully acknowledges the request but it does not initiate a new = credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD = be used in the RAA message to indicate a credit re-authorization = procedure is already ongoing (i.e. the client was in PendingU state when = the RAR was received). The credit control server SHOULD process the = Credit-Control-Request as if it was received in answer to the server = initiated credit re-authorization, and should consider the server = initiated credit re-authorization process successful upon reception of = the Re-Auth-Answer message. If several credit control sub-sessions are in use, a credit control = client receiving the RAR command for a given session will trigger credit = re-authorization for all the sub-session separately. TO The Diameter Credit Control Application supports the server-initiated = re-authorization. The credit control server MAY optionally initiate the = credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in = the Diameter base protocol [DIAMBASE]. The Auth- Application-Id in the = RAR message is set to 4 to indicate the Diameter Credit Control = Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. Where multiple services in a user's session are supported as defined in = section 5.1.1, the server MAY request credit re-authorization at: = (sub-)session level, credit pool level granularity, service-identifier = level granularity or rating-group granularity. To request credit = re-authorization at credit pool granularity the server includes in the = RAR message the G-S-U-Pool-Identifier AVP indicating the affected pool.=20 To request credit re-authorization at service or rating-group = granularity the server includes in the RAR message the = Service-Identifier AVP or the Rating-Group AVP respectively. To request = credit re-authorization for all the ongoing services within the = (sub-)session the server does not include any of the above mentione AVPs = in the RAR message. If a credit re-authorization is not already ongoing (i.e. the credit = control session is in OPEN state), a credit control client that receives = a RAR message with Session-Id equal to a currently active credit control = session acknowledges the request by sending the Re-Auth-Answer (RAA) = message and MUST initiate the credit re- authorization towards the = server by sending a Credit-Control-Request message with the = CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code = 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to = indicate an additional message (i.e. CCR[Update]) is required to = complete the procedure. If a quota was allocated to the session, the = credit control client MUST report the used quota in the = Credit-Control-Request. Note that the end user does not need to be = prompted for the credit re-authorization, since the credit re- = authorization is transparent to the user (i.e it takes place exclusively = between the credit control client and the credit control server). Where multiple services in a user's session are supported, the procedure = of the above paragraph will be executed at the granularity as requested = by the server in the RAR message. If credit re-authorization is ongoing at the time when the RAR message = is received (i.e. RAR-CCR collision), the credit control client = successfully acknowledges the request but it does not initiate a new = credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD = be used in the RAA message to indicate a credit re- authorization = procedure is already ongoing (i.e. the client was in PendingU state when = the RAR was received). The credit control server SHOULD process the = Credit-Control-Request as if it was received in answer to the server = initiated credit re-authorization, and should consider the server = initiated credit re-authorization process successful upon reception of = the Re-Auth-Answer message. Where multiple services in a user's session are supported, it may happen = that the server requests credit re-authorization for a credit pool (or = for the (sub-)session) and a credit re-authorization is already ongoing = for some of the services or rating-groups. In this case the client = acknowledges the server request with a RAA message and MUST send a new = Credit-Control-Request message to perform re-authorization for the = remaining services/rating-groups of the pool. The Result-Code 2002 = (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate = an additional message (i.e. CCR[Update]) is required to complete the = procedure. The server processes the received requests and returns an = appropriate answer to both of the requests. =20 The above defined procedures are enabled for each of the possibly active = Diameter credit-control sub-sessions. The server MAY request = re-authorization for an active sub-session by including the = CC-Sub-Session-Id AVP in the RAR message in addition to the Session-Id = AVP. -Section 5.5 Graceful Service Termination change second paragraph FROM This section defines the graceful service termination optional feature = that MAY be supported by the credit control server. Credit control = client implementations MUST support the Final-Unit-Indication with at = least the tear down of the ongoing service session upon the subscriber = has consumed all the final granted units. TO This section defines the graceful service termination optional feature = that MAY be supported by the credit control server. Credit control = client implementations MUST support the Final-Unit-Indication with at = least the tear down of the ongoing service session upon the subscriber = has consumed all the final granted units. Where independent credit control of multiple services in a single credit = control (sub-)session is supported, it is possible to use the graceful = service termination for each of the services/rating-groups = independently. - Section 8 - add to the table:=20 +---------------------+ =20 | AVP Flag rules | =20 |----+-----+----+-----|----+ = =20 AVP Section | | |SHLD| MUST| | = =20 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| = =20 -----------------------------------------|----+-----+----+-----|----| = =20 G-S-U-Pool- tbd 8.X Unsigned32| M | P | | V | Y | = Identifier | | | | | | = G-S-U-Pool- tbd 8.Y Grouped | M | P | | V | Y | = Reference | | | | | | = CC-Unit-Type tbd 8.Z Enumerated| | | | | | = =20 Multiple-Service- tbd 8.V Grouped | M | P | | V | Y | = Credit-Control | | | | | | Multiple-Services-tbd 8.W Enumerated| M | P | | V | Y | = Indicator | | | | | | - Section 8 amend as follows:=20 FROM:=20 8.16 Granted-Service-Unit AVP =20 =20 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and=20 contains the amount of units that the Diameter credit-control client can provide to the end user until the service must be=20 released or the new Credit-Control-Request must be sent. A client is not required to implement all of the unit types, and must treat unknown or unsupported unit types in the answer message as an incorrect CCA answer. In that case the client shall terminate credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group.=20 In case both the Service-Identifier and the Rating-Group AVPs are=20 included, the target of the granted units is always the service(s)=20 indicated by the value of the Service-Identifier AVP.=20 A value of 0 (zero) granted service unit associated to a Service-=20 entifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in case the credit-control=20 server want to disconnect the user and close the credit-control=20 session, it SHOULD use the appropriate error code in the Credit- Control-Answer message rather than including n times the Granted- Service-Units AVPs with the value of 0 (zero). =20 In contrast, a value of max type granted service unit (e.g. max=20 Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or=20 Rating-Group indicates that the corresponding traffic is free-of-=20 charge. With unit type money, the value of the Exponent AVP is set to 0 (zero) when free-of-charge is indicated. With unit type service specific, the value of the CC-Service-Specific-Units AVP is set to FFFFFFFF to indicate free-of-charge.=20 =20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=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 TO:=20 8.16 Granted-Service-Unit AVP =20 =20 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and=20 contains the amount of units that the Diameter credit-control client can provide to the end user until the service must be released or the new Credit-Control-Request must be sent. A client is not required to implement all of the unit types, and must treat unknown or unsupported unit types in the answer message as an incorrect CCA answer. In that case the client MUST terminate the credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.=20 =20 The Granted-Service-Unit AVP has the following ABNF grammar: =20 =20 Granted-Service-Unit ::=3D < AVP Header: 431 >=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 FROM: 8.21 Requested-Service-Unit AVP =20 =20 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and contains the amount of requested units specified by the Diameter credit-control client. A server is not required to implement all of the unit types, and must treat unknown or=20 unsupported unit types as invalid AVPs.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to request units for a given service(s) or rating group when the service element supports credit control for multiple services in one credit control session. =20 =20 If both the AVPs are present, the Rating-Group AVP indicates the=20 rating group to which the service(s) specified by the Service- Identifier(s) belongs. If only the Rating-Group-Id AVP is present,=20 this is a credit authorization request for all the services that=20 belongs to the specified rating group.=20 =20 A server not implementing the Service-Identifier AVP and the Rating-Group AVP must treat them as invalid AVPs.=20 =20 The Requested-Service-Unit AVP has the following ABNF grammar: =20 =20 Requested-Service-Unit ::=3D < AVP Header: 437 >=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: 8.21 Requested-Service-Unit AVP =20 =20 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and contains the amount of requested units specified by the Diameter credit-control client. A server is not required to implement all of the unit types, and must treat unknown or unsupported unit types as invalid AVPs.=20 The Requested-Service-Unit AVP has the following ABNF grammar: =20 =20 Requested-Service-Unit ::=3D < AVP Header: 437 >=20 [ CC-Time ]=20 [ CC-Money ] =20 [ CC-Total-Octets ]=20 [ CC-Input-Octets ]=20 [ CC-Output-Octets ]=20 [ CC-Service-Specific-Units ] =20 FROM: 8.30 Used-Service-Unit AVP =20 =20 The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446) and contains the amount of used units measured from the point when the service became active or, in case of interim interrogations are used during the session, from the point when the previous measurement ended.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to associate the used units to a given service or rating group.=20 When granted service units are associated to a service or rating=20 group, the credit control client MUST report the corresponding used service units. If the granted units are associated to a rating group, the units used by each of the Service-Identifier belonging to that rating group SHOULD be reported if this information is available to the credit control client. Therefore, multiple instances of the Used-Service-Unit AVP MAY be present in a request, each associated to the relevant Rating-Group-Id and to the identifier of the service (i.e. Service-Identifier) that consumed some of the granted units.=20 =20 The Used-Service-Unit AVP has the following ABNF grammar:=20 =20 Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ Tariff-Change-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 TO: 8.30 Used-Service-Unit AVP =20 =20 The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446) and contains the amount of used units measured from the point when the service became active or, in case of interim interrogations are used during the session, from the point when the previous measurement ended.=20 =20 The Used-Service-Unit AVP has the following ABNF grammar:=20 =20 Used-Service-Unit ::=3D < AVP Header: 446 >=20 [ Tariff-Change-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 FROM 8.42 Tariff-Change-Usage AVP The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and = defines whether units are used before, after or straddled tariff change = when a tariff change has occurred during the reporting period. Omission = of this AVP means that no tariff change has been occurred. Tariff-Change-Usage can be one of the following. UNIT_BEFORE_TARIFF_CHANGE 0 The used units contains the amount of the units before 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. UNIT_INDETERMINATE 2 The used units contains the amount of units that straddle the tariff = change (e.g. the metering process reports to the credit-control client = in blocks of n octets and one block straddled the tariff change). TO 8.42 Tariff-Change-Usage AVP The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and = defines whether units are used before or, after a tariff change, or the = units straddled tariff change when a tariff change has occurred during = the reporting period.=20 Omission of this AVP means that no tariff change has been occurred. In addition, when present in answer messages as part of the = Multiple-Services-Credit-Control AVP, this AVP defines whether units are = allocated to be used before or after a tariff change event. Omission of this AVP in answer messages when the Tariff-Time-Change AVP = is present means that the single quota mechanism applies. Tariff-Change-Usage can be one of the following: UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Multiple-Services-Credit-Control AVP, this value = indicates the amount of the units allocated for use before a tariff = change occurs.=20 When present in the Used-Service-Unit AVP, this value indicates the = amount of resource units used before a tariff change had occurred. UNIT_AFTER_TARIFF_CHANGE 1 When present in the Multiple-Services-Credit-Control AVP, this value = indicates the amount of the units allocated for use after a tariff = change occurs.=20 When present in the Used-Service-Unit AVP, this value indicates the = amount of resource units used after tariff change had occurred. UNIT_INDETERMINATE 2 The used unit contains the amount of units that straddle the tariff = change (e.g. the metering process reports to the credit-control client = in blocks of n octets and one block straddled the tariff change). This = value is to be used only in the Used-Service-Unit AVP. ADD new section 8.x=20 8.X G-S-U-Pool-Identifier AVP=20 The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type Unsigned32 and identifies a 'credit pool' within the session.=20 ADD new section 8.Y=20 8.Y G-S-U-Pool-Reference AVP=20 The G-S-U-Pool-Reference AVP (AVP code tbd) is of type Grouped, it is used in the Credit-Control-Answer message and associates the Granted-Service-Units AVP within which it appears with a credit pool within the session.=20 The G-S-U-Pool-Identifier AVP specifies the credit pool from=20 which credit is drawn for this unit type. The CC-Unit-Type AVP specifies the type of units for which credit is pooled. =20 The Unit-Value AVP specifies the multiplier which converts between service units of type CC-Unit-Type and abstract service units within the credit pool (and hence to service units of any other service or rating group associated with the same pool). The G-S-U-Pool-Reference AVP has the following ABNF grammar: =20 G-S-U-Pool-Reference ::=3D < AVP Header: tbd >=20 { G-S-U-Pool-Identifier }=20 { CC-Unit-Type } { Unit-Value }=20 ADD new section 8.z=20 8.Z CC-Unit-Type AVP=20 The CC-Unit-Type AVP (AVP code tbd) is of type enumerated and specifies the type of units which are considered to be pooled into a credit pool. The following values are defined for the CC-Unit-Type AVP: TIME 0=20 MONEY 1=20 TOTAL-OCTETS 2=20 INPUT-OCTETS 3=20 OUTPUT-OCTETS 4=20 SERVICE-SPECIFIC-UNITS 5=20 ADD new section 8.V=20 8.V Multiple-Services-Credit-Control AVP =20 =20 Multiple-Services-Credit-Control AVP (AVP Code tbd) is of type Grouped and contains the AVPs related to the independent credit control of multiple services feature. Note that each instance of this AVP carries units related to one or more services or related to a single rating-group. =20 The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group.=20 In case both the Service-Identifier and the Rating-Group AVPs are=20 included, the target of the service units is always the service(s)=20 indicated by the value of the Service-Identifier AVP(s). If only the Rating-Group-Id AVP is present, the Multiple-Services-Credit- Control AVP relates to all the services that belongs to the specified rating group.=20 The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- Pool-Identifier identifying a credit pool within which the units of the specified type are considered to be pooled. If a G-S-U- Pool-Reference AVP is present then actual service units of the specified type MUST also be present. For example, if the G-S-U- Pool-Reference AVP specifies Unit-Type TIME, then the CC-Time AVP MUST be present. =20 The Tariff-Change-Usage AVP SHOULD be included in a Credit-Control- Answer command when the Tariff-Time-Change AVP is present. It=20 instructs the client when the resources in the Granted-Service-Unit=20 AVP should be used. When both the Tariff-Time-Change and Tariff- Change-Usage AVPs are present, the server MUST include two separate=20 instances of the Multiple-Services-Credit-Control AVP with the=20 Granted-Service-Unit AVP associated to the same Service-Identifier=20 and/or Rating-Group and to the same pool identifier (but with=20 different multipliers). Note that these two quotas are grouped in the same pool, thus the=20 credit pooling mechanism as defined in section 5.1.1 applies. A server not implementing the independent credit control of multiple services functionality MUST treat the Multiple-Services- Credit-Control AVP as invalid AVP.=20 =20 The Multiple-Services-Control AVP has the following ABNF grammar: =20 =20 Multiple-Services-Credit-Control ::=3D < AVP Header: tbd >=20 [ Granted-Service-Unit ] [ Tariff-Change-Usage ] =20 [ Requested-Service-Units ]=20 *[ Used-Service-Units ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 *[ G-S-U-Pool-Reference ]=20 [ Validity-Time ]=20 [ Result-Code ]=20 [ Final-Unit-Indication ]=20 ADD new section 8.W=20 8.W Multiple-Services-Indicator AVP=20 =20 The Multiple-Services-Indicator AVP (AVP Code tbd) is of type Enumerated and indicates whether the Diameter Credit-control client is capable of handling multiple services independently=20 within a (sub-)session. The absence of this AVP means that independent credit control of multiple services is not supported. A server not implementing the independent credit control of=20 multiple services MUST treat the Multiple-Services-Indicator AVP as invalid AVP.=20 The following values are defined for the Multiple-Services- Indicator AVP:=20 =20 MULTIPLE_SERVICES_NOT_SUPPORTED 0=20 Client does not support independent credit control of multiple servicess within a (sub-)session. =20 MULTIPLE_SERVICES_SUPPORTED 1=20 Client supports independent credit control of multiple services within a (sub-)session. - section 10. AVP Occurrence Table=20 ADD a new section: 10.1 Re-Auth-Request AVP Table This section defines AVPs that are specific to Diameter Credit=20 Control Application and MAY be included in the Diameter=20 Re-Auth-Request (RAR) message [DIAMBASE].=20 =20 Re-Auth-Request command MAY include the following additional AVPs: +---------------+ =20 | Command Code |=20 |-------+-------+ =20 Attribute Name | RAR | RAA | =20 ------------------------------+-------+-------+ =20 CC-Sub-Session-Id | 0-1 | 0-1 | =20 G-S-U-Pool-Identifier | 0-1 | 0-1 | Service-Identifier | 0-1 | 0-1 | Rating-Group | 0-1 | 0-1 | ------------------------------+-------+-------+=20 From owner-aaa-wg@merit.edu Thu Feb 12 11:06:12 2004 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 LAA00007 for ; Thu, 12 Feb 2004 11:06:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D1EBA91272; Thu, 12 Feb 2004 11:05:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 916E091274; Thu, 12 Feb 2004 11:05: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 0F9CC91272 for ; Thu, 12 Feb 2004 11:05:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id CDB8B5DDAF; Thu, 12 Feb 2004 11:05:53 -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 7BBB25DDB2 for ; Thu, 12 Feb 2004 11:05:52 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CG5pv13447 for ; Thu, 12 Feb 2004 18:05:51 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 18:05:49 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 18:05:50 +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]: DCC: issue Wrong multiple services mechanism in Flow X Date: Thu, 12 Feb 2004 18:05:49 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C83F3@esebe016.ntc.nokia.com> Thread-Topic: DCC: issue Wrong multiple services mechanism in Flow X Thread-Index: AcPxghTT6QcfQoAqSBOxVBlq5igLXw== From: To: Cc: , , , , , X-OriginalArrivalTime: 12 Feb 2004 16:05:50.0330 (UTC) FILETIME=[15621DA0:01C3F182] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: Wrong multiple services mechanism in Flow X Submitter name: Mark Watson/Chris Richards/Marco Stura/Harri Hakala Date first submitted: 12.02.2004 Reference:=20 Document: draft-ietf-aaa-diameter-cc-02.txt=20 Comment type: T=20 Priority: 1=20 Section: Various=20 Rationale/Explanation of issues: The mechanism in Flow X is affected by all the drawbacks as described in Issue 16 and should be replaced by the following flow. Requested change: Replace Flow X with the new one hereafter A.10 Flow X=20 =20 The Diameter Credit Control Application defines the Multiple- Services-Credit-Control AVP that can be used to support independent=20 credit control of multiple services in a single credit control=20 (sub-)session for service elements that have such capabilities.=20 It is possible to request and allocate resources as a credit=20 pool that is shared between services or rating groups.=20 =20 The flow example hereafter illustrates a usage scenario where=20 the Credit-control client and server support independent credit=20 control of multiple services as defined in section 5.1.1.=20 It is assumed that Service-Identifiers, Rating-Groups and their associated parameters (e.g. IP 5-tuple) are locally configured=20 in the Service Element or provisioned by another entity than=20 the credit control server. =20 End-User Service Element CC Server (CC client) =20 |(1)User logon | |=20 |------------------>|(2)CCR(initial, Service-Id access, | | | Access specific AVPs, | | | Multiple-Service-Indicator) | | |---------------------------------------->|=20 | |(3)CCA(Multiple-Services-CC ( |=20 | | Granted-Units(Total-Octets), |=20 | | Service-Id access, | | | Validity-time, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 10))) | | |<----------------------------------------| : : :=20 |(4)Service-Request (Service 1) |=20 |------------------>|(5)CCR(update, Multiple-Services-CC( |=20 | | Requested-Units(), Service-Id 1, | | | Rating-Group 1)) | | |---------------------------------------->| | |(6)CCA(Multiple-Services-CC ( |=20 | | Granted-Units(Time), |=20 | | Rating-Group 1, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 1))) | | |<----------------------------------------| : : :=20 |(7)Service-Request (Service 2) |=20 |------------------>| |=20 : : : : : : |(8)Service-Request (Service 3&4) |=20 |------------------>|(9)CCR(update, Multiple-Services-CC ( |=20 | | Requested-Units(), Service-Id 3, | | | Rating-group 2), | | | Multiple-Services-CC ( | | | Requested-Units(), Service-Id 4, | | | Rating-Group 3)) | | |---------------------------------------->| | |(10)CCA(Multiple-Services-CC ( |=20 | | Granted-Units(Total-Octets), |=20 | | Service-Id 3, Rating-group 2, | | | Validity-time, | | | G-S-U-Pool-Reference(Pool-Id 2, | | | Multiplier 2)), | | | Multiple-Services-CC ( |=20 | | Granted-Units(Total-Octets), |=20 | | Service-Id 4, Rating-group 3 | | | Validity-time, | | | Final-Unit-Ind.(Terminate), | | | G-S-U-Pool-Reference(Pool-Id 2, | | | Multiplier 5))) | | |<----------------------------------------| : : :=20 : : :=20 | +--------------+ | |=20 | |Validity time | |(11)CCR(update, |=20 | |expires for | | Multiple-Services-CC ( |=20 | |Service-Id | | Used-Units(In-Octets,Out-Octets),| | | access | | Service-Id access)) | | +--------------+ |---------------------------------------->| =20 | |(12)CCA(Multiple-Services-CC ( | | | Granted-Units(Total-Octets), |=20 | | Service-Id access, |=20 | | Validity-time, | | | G-S-U-Pool-Reference(Pool-Id 1, |=20 | | Multiplier 10))) | | |<----------------------------------------|=20 : : :=20 : : :=20 | +--------------+ | |=20 | |Total Quota | |(13)CCR(update, |=20 | |elapses for | | Multiple-Services-CC ( |=20 | |pool 2: | | Used-Units(In-Octets,Out-Octets),| | |service 4 not | | Service-Id 3, Rating-group 2), | | |allowed, | | Multiple-Services-CC ( |=20 | |service 3 cont| | Used-Units(In-Octets,Out-Octets),| | +--------------+ | Service-Id 4, Rating-group 3)) | | |---------------------------------------->| =20 | |(14)CCA(Multiple-Services-CC ( | | | Result-Code 4011, |=20 | | Service-Id 3)) | | |<----------------------------------------|=20 : : :=20 : : : =20 |(15) User logoff | |=20 |------------------>|(16)CCR(term, |=20 | | Multiple-Services-CC ( |=20 | | Used-Units(In-Octets,Out-Octets),| | | Service-Id access), | | | Multiple-Services-CC ( |=20 | | Used-Units(Time), | | | Service-Id 1, Rating-group 1), | | | Multiple-Services-CC ( |=20 | | Used-Units(Time), | | | Service-Id 2, Rating-group 1)) | | |---------------------------------------->|=20 | |(17)CCA(term) |=20 | |<----------------------------------------|=20 =20 Figure A.10: Independent credit control of multiple services in a Credit Control (sub-)Session, flow example.=20 =20 The user logs onto the network (1). The Service Element sends a Diameter = Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to = the Diameter credit-control server to perform credit authorization for = the bearer service (e.g. internet access service) and to establish a = credit control session (2). In this message the credit-control client = indicates support for independent credit control of multiple services = within the session by including the Multiple-Service-Indicator AVP. The = Diameter credit-control server checks the end user's account balance, = based on the rating information received from the client (i.e. = Service-Id and access specific AVPs) rates the request and reserves = credit from the end user's account. Say the server reserves $5 and = determines the cost is $1/MB. It then returns to the service element a = Credit-Control-Answer message that include the = Multiple-Services-Credit-Control AVP with a quota of 5MB associated to = the Service-Id (access), to a multiplier value of 10 and to the Pool-Id = 1 (3).=20 The user uses Service 1 (4). The service element sends a Diameter = Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the = credit control server to perform credit authorization for service 1 (5). = This message includes the Multiple-Services-Credit-Control AVP to = request service units for the Service 1 that belong to Rating-Group 1. = The Diameter credit-control server determines that Service 1 draws = credit resources from the same account as the access service (i.e. pool = 1), based on Service-Id/Rating-Group rates the request and updates the = existing reservation by requesting more credit. Say the server reserves = $5 more (now the reservation is $10) and determines the cost is = $0.1/minutes. The server authorizes the whole Rating-Group, it then = returns to the service element a Credit-Control-Answer message that = include the Multiple-Services-Credit-Control AVP with a quota of 50min. = associated to the Rating-Group 1, to a multiplier value of 1 and to the = Pool-Id 1 (6). The client adjusts the total amount of resources for pool = 1 according the received quota, which gives M for Pool 1 =3D 100. The user uses Service 2 that belongs to the authorized Rating-Group 1 = (7). Resources are then consumed from the pool 1. The user requests now Service 3 and Service 4 as well, that are not = authorized (8). The service element sends a Diameter = Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the = credit control server to perform credit authorization for service 3&4 = (9). This message includes two instances of the = Multiple-Services-Credit-Control AVP to request service units for the = Service 3 that belong to Rating-Group 2 and for the Service 4 that = belong to Rating-Group 3. The Diameter credit-control server determines = that Service 3&4 draw credit resources from another account (i.e. pool = 2), it checks the end user's account balance and based on = Service-Ids/Rating-Groups information rates the request and reserve = credit from pool 2. Say the server reserves $5 and determines that Service 3 costs $0.2/MB = and Service 4 costs $0.5/MB. The server authorizes only Services 3&4, it = then returns to the service element a Credit-Control-Answer message that = include two instances of the Multiple-Services-Credit-Control AVP (10). = One instance grants a quota of 12.5MB associated to the Service-Id 3, to = a multiplier value of 2 and to the Pool-Id 2. The other instance grants = a quota of 5MB associated to the Service-Id 4, to a multiplier value of = 5 and to the Pool-Id 2. The server also determines that pool 2 is exhausted and Service 4 is not = allowed to continue after these units will be consumed. Therefore the = Final-Unit-Indication AVP with action TERMINATE is associated to the = Service-Id 4. The client calculates the total amount of resources that = can be used for Pool 2 according the received quotas and multipliers, = which give M for Pool 2 =3D 50. The Validity-Time for the access service expires. The service element = sends a Credit-Control-Request message to the server to perform credit = re-authorization for Service-Id (access) (11). This message carries one = instance of the Multiple-Services-Credit-Control AVP that includes the = units used by this service. Say the total amount of used units is 4MB. = The client adjusts the total amount of resources for Pool 1 accordingly, = which gives M for Pool 1 =3D 60. The server deducts $4 from the user's account and updates the = reservation by requesting more credit. Say the server reserves $5 more = (now the reservation is $11) and already knows the cost of the = Service-Id (access) that is $1/MB. It then returns to the service = element a Credit-Control-Answer message that include the = Multiple-Services-Credit-Control AVP with a quota of 5MB associated to = the Service-Id (access), to a multiplier value of 10 and to the Pool-Id = 1 (12). The client adjusts the total amount of resources for pool 1 = according the received quota, which gives M for Pool 1 =3D 110. Services 3&4 consume the total amount of Pool 2 credit resources (i.e. = C1*2 + C2*5 >=3D M). The service element immediately starts the = TERMINATE action concerning Service 4 and sends a Credit-Control-Request = message with CC-Request-Type set to UPDATE_REQUEST to the credit control = server to perform credit re-authorization for Service 3 (13). This = message contains two instances of the Multiple-Services-Credit-Control = AVP to report the units used by Service 3 and Service 4. The server = deducts the last $5 from the user's account (Pool 2) and returns the = answer with Result-Code 4011 in the Multiple-Services-Credit-Control AVP = to indicate that Service 3 can continue without credit control (14). The end user logs off from the network (15). To debit the used units = from the end user's account and to stop the credit control session, the = service element sends a Diameter Credit-Control-Request with = CC-Request-Type set to TERMINATION_REQUEST to the credit control server = (16). This message contains the units consumed by each of the used = services in multiple instances of the Multiple-Services-Credit-Control = AVP. The used units are associated with the relevant Service-Identifier = and Rating-Group. The Diameter credit-control server debits the used = units to the user's account (Pool 1) and acknowledges the session = termination by sending a Diameter Credit-Control-Answer to the service = element (17). From aaa-admin@ietf.org Fri Feb 13 02:08:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21684 for ; Fri, 13 Feb 2004 02:08:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQi-0001ZD-Q2; Fri, 13 Feb 2004 02:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQb-0001VR-Eu for aaa@optimus.ietf.org; Fri, 13 Feb 2004 02:07:57 -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 CAA20667 for ; Fri, 13 Feb 2004 02:07:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXQT-00004S-00 for aaa@ietf.org; Fri, 13 Feb 2004 02:07:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXPW-0007my-00 for aaa@ietf.org; Fri, 13 Feb 2004 02:06:50 -0500 Received: from arena-25.cza.warszawa.supermedia.pl ([212.180.248.26]) by ietf-mx with smtp (Exim 4.12) id 1ArXOt-0007i1-00 for aaa@ietf.org; Fri, 13 Feb 2004 02:06:12 -0500 Received: from [116.213.5.245] by arena-25.cza.warszawa.supermedia.pl id ucaqmhxG59Oc; Fri, 13 Feb 2004 12:04:18 +0500 Message-ID: <3$54y-2g2$7-15n8j-j3e44vij0@448d.9i> From: "Teresa Drake" Reply-To: "Teresa Drake" To: , Date: Fri, 13 Feb 04 12:04:18 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_E55.24.5." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.4 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Earn profits selling other people's services 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: , --_E55.24.5. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 6 wdvsix qjuzo mkzhuyfnqvl xw yspq u

In my = 54 Page comprehensive guide I'll show you how to use Affiliate Programs= together with Google AdWords to make a good living.

 

No more emails! please take me off

kpb d bkns u hvygovtxb tbmzbm xwrigt mwad rrg oiluzhpnlugv kb z dibpyqdlkd fz --_E55.24.5.-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Feb 13 02:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22658 for ; Fri, 13 Feb 2004 02:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXRg-00027E-DV for aaa-archive@odin.ietf.org; Fri, 13 Feb 2004 02:09:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D793t5008108 for aaa-archive@odin.ietf.org; Fri, 13 Feb 2004 02:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXRe-00026h-Jw for aaa-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 02:09:02 -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 CAA22033 for ; Fri, 13 Feb 2004 02:08:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXRX-0000Bp-00 for aaa-web-archive@ietf.org; Fri, 13 Feb 2004 02:08:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArXQm-00005w-00 for aaa-web-archive@ietf.org; Fri, 13 Feb 2004 02:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQi-0001ZD-Q2; Fri, 13 Feb 2004 02:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQb-0001VR-Eu for aaa@optimus.ietf.org; Fri, 13 Feb 2004 02:07:57 -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 CAA20667 for ; Fri, 13 Feb 2004 02:07:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXQT-00004S-00 for aaa@ietf.org; Fri, 13 Feb 2004 02:07:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXPW-0007my-00 for aaa@ietf.org; Fri, 13 Feb 2004 02:06:50 -0500 Received: from arena-25.cza.warszawa.supermedia.pl ([212.180.248.26]) by ietf-mx with smtp (Exim 4.12) id 1ArXOt-0007i1-00 for aaa@ietf.org; Fri, 13 Feb 2004 02:06:12 -0500 Received: from [116.213.5.245] by arena-25.cza.warszawa.supermedia.pl id ucaqmhxG59Oc; Fri, 13 Feb 2004 12:04:18 +0500 Message-ID: <3$54y-2g2$7-15n8j-j3e44vij0@448d.9i> From: "Teresa Drake" Reply-To: "Teresa Drake" To: , Date: Fri, 13 Feb 04 12:04:18 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_E55.24.5." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.4 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Earn profits selling other people's services 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: , --_E55.24.5. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 6 wdvsix qjuzo mkzhuyfnqvl xw yspq u

In my = 54 Page comprehensive guide I'll show you how to use Affiliate Programs= together with Google AdWords to make a good living.

 

No more emails! please take me off

kpb d bkns u hvygovtxb tbmzbm xwrigt mwad rrg oiluzhpnlugv kb z dibpyqdlkd fz --_E55.24.5.-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Feb 13 02:31:37 2004 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 CAA26122 for ; Fri, 13 Feb 2004 02:31:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AE76B91289; Fri, 13 Feb 2004 02:31:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04D2E9128A; Fri, 13 Feb 2004 02:31: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 8B97E91289 for ; Fri, 13 Feb 2004 02:31:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 70EEA5DF45; Fri, 13 Feb 2004 02:31:19 -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 75A5D5DF6B for ; Fri, 13 Feb 2004 02:31:18 -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 i1D7VH316211 for ; Fri, 13 Feb 2004 09:31:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 09:31:16 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:31: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: [AAA-WG]: RE: [Diameter SIP Application] Digest auth-int protection issue Date: Fri, 13 Feb 2004 09:31:15 +0200 Message-ID: Thread-Topic: [Diameter SIP Application] Digest auth-int protection issue Thread-Index: AcPxcW+9PGIGarNeSkOfClBgOP+sUQAjQ3HQ From: To: , , Cc: , , , , , X-OriginalArrivalTime: 13 Feb 2004 07:31:17.0605 (UTC) FILETIME=[5E37E150:01C3F203] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I haven't followed the RADIUS discussion, so I'm sorry I made more or = less redundant proposal. I'm not very keen on different options for one function and therefore my = proposal was little bit too quickly made and the example wasn't the best = possible.=20 My primary intention was to ask if the SIP-Authentication-Context AVP = could be grouped AVP. Then it could carry the Entity-Body-Hash sub-AVP = in case of HTTP digest. And if necessary, it could be also extended to = carry other sub-AVPs in other cases. I believe this is the same what = Wolfgang proposed.=20 The definition of the AVP could be then e.g. SIP-Authentication-Context :: =3D < AVP Header : TBD > [ Entity-Body-Hash] =20 * [ AVP ] Of course, if the SIP-Authentication-Context AVP is seen to have only = one dedicated task to carry the digest of entity body, then there is = probably no need to specify the SIP-Authentication-Context AVP as = grouped AVP. Regards, Kalle > -----Original Message----- > From: ext Beck01, Wolfgang [mailto:BeckW@t-systems.com] > Sent: 12 February, 2004 16:05 > To: Garcia Miguel.An (Nokia-NRC/Helsinki); Tammi Kalle > (Nokia-NET/Tampere); aaa-wg@merit.edu > Cc: miguel-angel.pallares@ericsson.com; > maria.carmen.belinchon@ericsson.com; carolina.canales@ericsson.com; > mccap@lucent.com; Rajaniemi Jaakko (Nokia-NET/Espoo); > jari.arkko@piuha.net > Subject: AW: [Diameter SIP Application] Digest auth-int=20 > protection issue >=20 >=20 >=20 >=20 > Miguel wrote: > > And this is more or less Wolfang Beck's suggestion as a non=20 > desired option... >=20 > > Wolfgang was suggesting just to add a second AVP to carry=20 > the digest of the body.=20 > > He didn't suggest the grouped AVP though. Wolfgang, any comment? >=20 > Kalle wrote: > >=20 > > Would it be possible to keep it even more clear and define=20 > > the SIP-Authentication-Context AVP as grouped AVP, which has=20 > > (at least) two possible sub-AVPs; one for the entity-body and=20 > > another for the hash of the entity-body?=20 > >=20 > > E.g. > >=20 > > SIP-Authentication-Context :: =3D < AVP Header : TBD > > > [ Entity-Body] > > [ Entity-Body-Hash]=09 > > =20 > > * [ AVP ] > I am not strongly opposed to it. But implementors will wonder why > there are two options for one function. On the other hand,=20 > Entity-Body-Hash > can only contain LHEX characters when using HTTP digest.=20 > Entity-Body has to > allow CR, LF and lot of other characters. Considering the=20 > different data types,=20 > grouped AVPs make sense. How about this: whether to use Entity-Body or > Entity-Body-Hash depends on the authentication mechanism being used. > Eg. when using HTTP digest, SIP-Authentication-Context must contain an > Entity-Body-Hash AVP carrying the body-digest.=20 >=20 > Wolfgang >=20 From owner-aaa-wg@merit.edu Fri Feb 13 02:41:41 2004 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 CAA26653 for ; Fri, 13 Feb 2004 02:41:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 82DB99128D; Fri, 13 Feb 2004 02:41:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B76E9128C; Fri, 13 Feb 2004 02:41:28 -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 AE9699128A for ; Fri, 13 Feb 2004 02:41:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95B115DFB5; Fri, 13 Feb 2004 02:41:26 -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 C23765DFAF for ; Fri, 13 Feb 2004 02:41:25 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D7fOv05514 for ; Fri, 13 Feb 2004 09:41:24 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 09:41:21 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:41:24 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:41:18 +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: [Diameter SIP Application] Digest auth-int protection issue Date: Fri, 13 Feb 2004 09:41:23 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF46751E@esebe006.ntc.nokia.com> Thread-Topic: [Diameter SIP Application] Digest auth-int protection issue Thread-Index: AcPxcW+9PGIGarNeSkOfClBgOP+sUQAjQ3HQAAFl/AA= From: To: , , Cc: , , , , , X-OriginalArrivalTime: 13 Feb 2004 07:41:18.0277 (UTC) FILETIME=[C43F2750:01C3F204] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Kalle: I think we are getting towards an agreement. For what I have seen in the = discussion, there is consensus to make the SIP-Authentication-Context a = grouped AVP. At the moment, we will include just one more AVP, the = entity-body-hash AVP, but will provide extensibility.=20 We only include an entity-body-hash AVP because we only provide support = for HTTP Digest authentication in the draft (since this is the mandatory = authentication mechanism in SIP).=20 Extensions to the Diameter SIP application may provide support for other = authentication mechanisms, and if required, extend the grouped AVP = somehow. I would consider the issue solved now. /Miguel > -----Original Message----- > From: Tammi Kalle (Nokia-NET/Tampere)=20 > Sent: 13 February, 2004 09:31 > To: 'ext Beck01, Wolfgang'; Garcia Miguel.An (Nokia-NRC/Helsinki); > aaa-wg@merit.edu > Cc: miguel-angel.pallares@ericsson.com; > maria.carmen.belinchon@ericsson.com; carolina.canales@ericsson.com; > mccap@lucent.com; Rajaniemi Jaakko (Nokia-NET/Espoo); > jari.arkko@piuha.net > Subject: RE: [Diameter SIP Application] Digest auth-int=20 > protection issue >=20 >=20 > Hi, >=20 > I haven't followed the RADIUS discussion, so I'm sorry I made=20 > more or less redundant proposal. >=20 > I'm not very keen on different options for one function and=20 > therefore my proposal was little bit too quickly made and the=20 > example wasn't the best possible.=20 >=20 > My primary intention was to ask if the=20 > SIP-Authentication-Context AVP could be grouped AVP. Then it=20 > could carry the Entity-Body-Hash sub-AVP in case of HTTP=20 > digest. And if necessary, it could be also extended to carry=20 > other sub-AVPs in other cases. I believe this is the same=20 > what Wolfgang proposed.=20 >=20 > The definition of the AVP could be then e.g. >=20 > SIP-Authentication-Context :: =3D < AVP Header : TBD > > [ Entity-Body-Hash]=09 > =20 > * [ AVP ] >=20 > Of course, if the SIP-Authentication-Context AVP is seen to=20 > have only one dedicated task to carry the digest of entity=20 > body, then there is probably no need to specify the=20 > SIP-Authentication-Context AVP as grouped AVP. >=20 > Regards, > Kalle >=20 > > -----Original Message----- > > From: ext Beck01, Wolfgang [mailto:BeckW@t-systems.com] > > Sent: 12 February, 2004 16:05 > > To: Garcia Miguel.An (Nokia-NRC/Helsinki); Tammi Kalle > > (Nokia-NET/Tampere); aaa-wg@merit.edu > > Cc: miguel-angel.pallares@ericsson.com; > > maria.carmen.belinchon@ericsson.com; carolina.canales@ericsson.com; > > mccap@lucent.com; Rajaniemi Jaakko (Nokia-NET/Espoo); > > jari.arkko@piuha.net > > Subject: AW: [Diameter SIP Application] Digest auth-int=20 > > protection issue > >=20 > >=20 > >=20 > >=20 > > Miguel wrote: > > > And this is more or less Wolfang Beck's suggestion as a non=20 > > desired option... > >=20 > > > Wolfgang was suggesting just to add a second AVP to carry=20 > > the digest of the body.=20 > > > He didn't suggest the grouped AVP though. Wolfgang, any comment? > >=20 > > Kalle wrote: > > >=20 > > > Would it be possible to keep it even more clear and define=20 > > > the SIP-Authentication-Context AVP as grouped AVP, which has=20 > > > (at least) two possible sub-AVPs; one for the entity-body and=20 > > > another for the hash of the entity-body?=20 > > >=20 > > > E.g. > > >=20 > > > SIP-Authentication-Context :: =3D < AVP Header : TBD > > > > [ Entity-Body] > > > [ Entity-Body-Hash]=09 > > > =20 > > > * [ AVP ] > > I am not strongly opposed to it. But implementors will wonder why > > there are two options for one function. On the other hand,=20 > > Entity-Body-Hash > > can only contain LHEX characters when using HTTP digest.=20 > > Entity-Body has to > > allow CR, LF and lot of other characters. Considering the=20 > > different data types,=20 > > grouped AVPs make sense. How about this: whether to use=20 > Entity-Body or > > Entity-Body-Hash depends on the authentication mechanism being used. > > Eg. when using HTTP digest, SIP-Authentication-Context must=20 > contain an > > Entity-Body-Hash AVP carrying the body-digest.=20 > >=20 > > Wolfgang > >=20 >=20 From owner-aaa-wg@merit.edu Fri Feb 13 02:42:30 2004 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 CAA26691 for ; Fri, 13 Feb 2004 02:42:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5862A9128A; Fri, 13 Feb 2004 02:42:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21D1D9128B; Fri, 13 Feb 2004 02:42: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 45C259128A for ; Fri, 13 Feb 2004 02:42:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27D875DF77; Fri, 13 Feb 2004 02:42: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 5E4A05DF8D for ; Fri, 13 Feb 2004 02:42:10 -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 i1D7g9v06494 for ; Fri, 13 Feb 2004 09:42:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 09:42:03 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:42:03 +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]: DCC: new issue to replace issues 16, 17 and 18 Date: Fri, 13 Feb 2004 09:42:03 +0200 Message-ID: Thread-Topic: DCC: new issue to replace issues 16, 17 and 18 Thread-Index: AcPxgaBeMUW42cIXTLKkAkMBxa3wAgAgyzaA From: To: , Cc: , , , , X-OriginalArrivalTime: 13 Feb 2004 07:42:03.0427 (UTC) FILETIME=[DF287F30:01C3F204] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Assigned issue 19. Issues 16, 17, 18 are marked as rejected and replaced by issue 19. John >=20 > as agreed in=20 > http://www.merit.edu/mail.archives/aaa-wg/msg00176.html and=20 > http://www.merit.edu/mail.archives/aaa-wg/msg00182.html we=20 > have beed working on an updated proposal to issues 16 and 17. >=20 > The outcome is a new issue to replace issues 16 and 17 that=20 > define the independent credit control of multiple services in=20 > a (sub-)session feature. There will be a following mail with=20 > a companion issue to replace the Flow X of draft 02 according=20 > the agreed mechanism. >=20 > Finally, it was agred in=20 > http://www.merit.edu/mail.archives/aaa-wg/msg00207.html that=20 > also the tariff time change issue (issue 18) can be solved as=20 > part of the independent credit control of multiple services feature. >=20 > To summarize, this new issue replaces issues 16, 17 and 18. >=20 > Regards > Marco >=20 > -------------------------------------------------------------------- > Description of issue: Independent handling of services within=20 > a session=20 > Submitter name: Mark Watson/Chris Richards/Marco Stura/Harri Hakala=20 > Date first submitted: 12.02.2004=20 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-02.txt=20 > Comment type: T=20 > Priority: 1=20 > Section: Various=20 >=20 > Rationale/Explanation of issues:=20 >=20 > Handling of services or rating groups within a single session=20 > or sub-session=20 > can only be done 'en-bloc' according to the grouping of those=20 > services of=20 > rating groups into (sub-)sessions by the client. In particular: >=20 > - all services or rating groups must be re-authorised at the=20 > same time=20 > - adding an additional service or rating group requires=20 > re-authorisation of all=20 > other services/rating groups in the (sub-)session >=20 > - termination actions, particularly, redirect apply to the=20 > whole (sub-)session=20 > - state machine handling applies to the whole (sub-)session=20 >=20 > This has the following disadvantages:=20 > - unnecessary load on the server to perform re-rating for all=20 > services and=20 > rating groups, particularly when adding a new service will=20 > usually have no=20 > effect on the rating decision for the other services >=20 > - unnecessary (though less than above) load on the client to=20 > process other=20 > services just to add a new one=20 > - not possible to leave some services under credit control=20 > when others are=20 > terminated/redirected (the policy for how far 'into the red'=20 > a service can run=20 > will depend on the service). >=20 > - when a service or rating group has quotas in multiple=20 > units, it is not=20 > possible to have some of those handled independently and=20 > others 'pooled' >=20 > - the construction in which multiple quotas representing the=20 > *same* monetary=20 > allocation are passed down from client to server is=20 > counter-intuitive and=20 > liable to major mis-interpretation >=20 > The above restriction stems from the manner in which the=20 > 'pooling' of quotas=20 > for multiple services is framed within the protocol. The=20 > quotas provided for=20 > different services are not semantically independent and=20 > therefore operations on=20 > them must be carried out 'en-bloc'. >=20 > We propose to make the quotas provided semantically=20 > independent within the=20 > protocol, whilst maintaining the concept of a 'credit pool'=20 > which can apply to=20 > multiple services across the session. Additionally, as per=20 > our other proposal,=20 > we propose to decouple the 'pooling' of credit from the=20 > session/sub-session.=20 > Please see the other proposal for the rationale for this. >=20 > In order to handle quotas within a pool separately, it is=20 > necessary to be more=20 > explicit within the protocol about the relationship between=20 > quotas. This is=20 > presently communicated implicitly based on the assumption=20 > that all quotas are=20 > derived from the same credit reservation in the server. >=20 > For each service/rating group and unit, we provide a=20 > 'Multiplier' value which=20 > is used to express the ratios between services in terms of=20 > resource usage. >=20 > If service 1 has multiplier M1 and service 2 has multiplier=20 > M2 then resources=20 > from service 1 can be converted to those of service 2 by=20 > multiplying by M1/M2. >=20 > The formula for determining the exhaustion of the credit for=20 > a given pool of=20 > quotas at the client is modified as follows: the credit pool=20 > is exhausted when >=20 > C1*M1 + C2*M2 + ... + Cn*Mn >=3D M=20 >=20 > Where M is the total credit for the credit-pool. M is=20 > initially calculated from=20 > the granted quotas in the pool as follows: >=20 > M =3D Q1*M1 + Q2*M2 + ... + Qn*Mn=20 >=20 > This is pretty much equivalent to the existing formula (with=20 > Mi =3D M/Qi), with=20 > the following advantages:=20 > (i) new services can be added/removed without reference to=20 > the existing ones -=20 > M is simply modified by (Quota*Multiplier) for the=20 > added/removed service >=20 > (ii) all quotas returned in CC answers cleanly represent independent=20 > authorizations to use the indicated resource=20 > (iii) re-authorisation can be sought for an individual=20 > service/rating group=20 > (for example if another quota associated with the same=20 > service/rating group is=20 > exhausted) >=20 > (iv) flexibility, low signaling overhead and avoidance of=20 > credit fragmentation=20 > are maintained=20 >=20 > Note that where a Granted-Service-Unit contains more than one=20 > resource unit=20 > (e.g. Time and Volume) then multipliers can be provided for=20 > one or more of=20 > them. Where two multipliers are provided (e.g. M1t for time=20 > and M1v for volume)=20 > then the used resource from the pool is the sum C1t*M1t +=20 > C1v*M1v. Note that=20 > the draft at present does not include an explicit description=20 > of the handling=20 > of services with more than one resource unit with respect to=20 > credit pooling. >=20 > Finally, we propose to add the Final-Unit-Indication and=20 > Validity-Time AVPs to=20 > the Granted-Service-Unit APV to express independent handling=20 > of the different=20 > services in these respects. >=20 > Requested change:=20 >=20 > Overview:=20 >=20 > To implement the above mechanism, we extend the proposal made=20 > in Issue xxx on=20 > server control of credit pooling by adding the multiplier to=20 > the G-S-U-Pool- > Reference AVP. The multiplier is expressed using the Unit-Value AVP. >=20 > We therefore add the following AVPs:=20 >=20 > G-S-U-Pool-Reference AVP - contains a reference to a=20 > credit pool, a unit- > type and a multiplier (using the Unit-Value AVP). It is used=20 > within Granted- > Service-Units AVP to indicate that credit of a particular=20 > type is pooled. >=20 > CC-Unit-Type AVP - indicates the type of units (time,=20 > volume) that are=20 > pooled.=20 >=20 > G-S-U-Identifier AVP - identifies the credit pool.=20 >=20 > Detailed changes: >=20 > -section 3.1 Credit-Control-Request (CCR) Command=20 >=20 > FROM: > ::=3D < Diameter Header: 272, REQ, PXY >=20 > : > *[ Requested-Service-Unit ]=20 > : > *[ Used-Service-Unit ] =20 > : > TO: > ::=3D < Diameter Header: 272, REQ, PXY >=20 > : > [ Requested-Service-Unit ]=20 > : > *[ Used-Service-Unit ] =20 > [ Multiple-Services-Indicator ] =20 > *[ Multiple-Services-Credit-Control ] =20 >=20 > -Section 3.2 Credit-Control-Answer (CCA) Command=20 >=20 > FROM: > ::=3D < Diameter Header: 272, PXY >=20 > : > *[ Granted-Service-Unit ] =20 > : >=20 > TO: > ::=3D < Diameter Header: 272, PXY >=20 > : > [ Granted-Service-Unit ] =20 > *[ Multiple-Services-Credit-Control] > : > - Section 5, REMOVE fifth paragraph:=20 > When multiple services are used within one user session and each=20 > service or group of services are subject to different cost,=20 > making use of credit control sub-sessions will result in increased > signaling load and resources usage in both the credit control > client and the credit control server. For instance, during one > network access session the end user may use several http-services > subject to different access cost. To optimally support these > scenarios, the credit control application enables for multiple > services credit control in a single credit control session. It is > possible to request and allocate multiple quotas as a credit pool > that is shared between multiple services. The services can be > further grouped into rating groups in order to achieve even=20 > further aggregation of credit allocation. It is also possible to > request and allocate multiple quotas on a per service=20 > basis. The mechanism is illustrated in Appendix A (Flow X). >=20 > ADD new heading "5.1 General Principles" immediately after=20 > heading 5. Session Based Credit-control >=20 > ADD new section 5.1.1 (at the end of the above new 5.1): >=20 > 5.1.1 Credit-Control for Multiple Services within a (sub-)Session >=20 > When multiple services are used within one user session and each=20 > service or group of services are subject to different cost, it is > necessary to perform credit-control for each of these services > somewhat independently. Making use of credit control sub-sessions > to achieve independent credit-control will result in increased > signaling load and resources usage in both the credit control > client and the credit control server. For instance, during one > network access session the end user may use several http-services > subject to different access cost, the network access specific > attributes such as the quality of service (QoS) are common to all > the services carried within the access bearer, but the cost of the > bearer may vary dependent on its content.=20 > =20 > To optimally support these scenarios, the credit control > application enables for independent credit control of multiple > services in a single credit control (sub-)session. This is > achieved by including the optional Multiple-Services-Credit-=20 > Control AVP in Credit-Control-Request/Answer messages. It is > possible to request and allocate resources as a credit pool that > is shared between multiple services. The services can be further > grouped into rating groups in order to achieve even further=20 > aggregation of credit allocation. It is also possible to request > and allocate quotas on a per service basis. Where quotas > are allocated to a pool by means of the Multiple-Services-Credit- > Control AVP, the quotas remain independent objects which can be > re-authorised independently at any time. Quotas can also be given > independent result codes, validity times and Final-Unit- > indications. > =20 > In case independent credit control of multiple services is used > the validity-time and final-unit-indication SHOULD only be present > either in the Multiple-Service-Credit-Control AVP(s) or at command=20 > level as single AVPs. > However, the Result-Code AVP MAY be present both on the command > level and within the Multiple-Services-Credit-Control AVP. If the > Result-Code on the command level indicates other value than > SUCCESS then the Result-Code on command level takes precedence > over the one(s) included in the Multiple-Services-Credit-Control > AVP. >=20 > The Credit-control client MUST indicate support for independent > credit control of multiple services within a (sub-)session by > including the Multiple-Services-Indicator AVP in the first > interrogation. A Credit-Control-server not supporting the > feature MUST treat the Multiple-Services-Indicator AVP and > possibly received Multiple-Services-Credit-Control AVPs as=20 > invalid AVPs. >=20 > If the client indicated support for independent credit control of > multiple services, a credit-control server that whishes to use the > feature MUST return the granted units within the Multiple- > Services-Credit-Control AVP associated to the corresponding > service-identifier and/or rating-group. >=20 > To avoid credit fragmentation and unnecessary load on the credit > control server, it is possible for service units to be provided=20 > to multiple services or rating groups as a pool.=20 > This is achieved by providing the service units in the form of a > quota for a particular service or rating group in the Multiple- > Services-Credit-Control AVP, but also including a reference to a > credit pool for that unit type.=20 > The reference includes a multiplier derived from the rating > parameter, which translates from service units of a specific type > to the abstract service units in the pool. For instance if the > rating parameter for service 1 is $1/MB and rating parameter for > service 2 is $0.5/MB the multipliers could be 10 and 5 for service > 1 and service 2 respectively. >=20 > If M is the total service units within the pool, M1, M2, ... , Mn > are the multipliers provided for services 1, 2, ..., n and C1, C2, > ... ,Cn are the used resources within the session, then the pool > credit is exhausted and re-authorisation MUST be sought when:=20 > C1*M1 + C2*M2 + ... + Cn*Mn >=3D M=20 > The total credit in the pool, M, is calculated from the quotas > which are currently allocated to the pool as follows:=20 > M =3D Q1*M1 + Q2*M2 + ... + Qn*Mn =20 > =20 > If services or rating groups are added to or removed from the > pool, then the total credit is adjusted appropriately. Note that > when the total credit is adjusted because services or rating > groups are removed from the pool, the value that need to be > removed is the consumed one (i.e. Cx*Mx). =20 > Re-authorisation for an individual service or rating group may be > sought at any time, for example if a 'non-pooled' quota is used up > or the Validity-Time expires.=20 >=20 > Where multiple G-S-U-Pool-Reference AVPs with the same G-S-U-Pool=20 > Identifier are provided within a Multiple-Services-Credit-Control > AVP together with the Granted-Service-Unit AVP, then these MUST > have different CC-Unit-Type values and they all draw on the credit > pool separately. For instance if one multiplier for time (M1t) and > one multiplier for volume (M1v) are given, then the used resources > from the pool is the sum C1t*M1t + C1v*M1v, where C1t are the time=20 > units and C1v are the volume unit.=20 > Where service units are provided within a Multiple-Services- > Credit-Control AVP without a corresponding G-S-U-Reference AVP > then these are handled independently from any credit pool and from > any other services or rating groups within the session. >=20 > The credit pool concept is an optimal tool to avoid the=20 > over-reservation=20 > effect of the basic single quota tariff time change mechanism=20 > (the mechanism described in section 5.1). Therefore,=20 > Diameter credit- > control clients and servers implementing the independent=20 > credit control=20 > of multiple services SHOULD leverage the credit pool=20 > concept when supporting=20 > the tariff time change. The Diameter credit-control server=20 > SHOULD include=20 > both the Tariff-Time-Change and Tariff-Change-Usage AVPs=20 > in two quota=20 > allocations in the answer message (i.e. two instances of=20 > the Multiple- > Services-Credit-Control AVP). One of the granted units is=20 > allocated to be=20 > used before the potential tariff change while the second=20 > granted units=20 > are used after a tariff change. Both granted unit quotas=20 > MUST contain=20 > the same Service-Identifier and/or Rating-Group values and=20 > MUST belong=20 > to the same pool.=20 > This dual quota mechanism ensures that the overall=20 > reported used units=20 > would never exceed the credit reservation. =20 > The Diameter credit-control client reports both the used=20 > units before=20 > and after the tariff change in a single instance of the=20 > Multiple-Services > -Credit-Control AVP. > =20 > The failure handling for the credit control session is defined=20 > in section 5.6 and reflected to the basic credit-control state=20 > machine in section 7. Credit-control client and servers=20 > implementing=20 > the independent credit control of multiple services in a=20 > (sub-)session=20 > functionality MUST ensure a failure handling and general behavior=20 > fully consistent with the above mentioned sections while=20 > capable of=20 > handling parallel ongoing credit re-authorization within a=20 > (sub-)session.=20 > It is then RECOMMENDED that Diameter credit-control=20 > clients maintain=20 > a PENDING-U message queue and restarts the Tx timer every time a=20 > CCR[Update] message is sent while in PENDING-U state. When answers=20 > to all the pending messages are received the state machine=20 > moves to=20 > OPEN and Tx is stopped. Naturally the action performed=20 > when a problem=20 > is detected for the session according to section 5.6,=20 > affect all the=20 > ongoing services (e.g. failover to a backup server if=20 > possible affect=20 > all the CCR[Update] messages in the PENDING-U queue). >=20 > Since the client may send CCR[Update] messages while in PENDING-U=20 > (i.e. without waiting for an answer to ongoing credit=20 > re-authorization),=20 > the time space between these requests may be very short=20 > and the server=20 > may not have received the previous request(s) yet.=20 > Therefore in this=20 > situation the server may receive out of sequence requests=20 > and SHOULD NOT=20 > consider this as an error condition, a proper answer is to=20 > be returned=20 > to each of those requests. >=20 > -Section 5.4 Server-Initiated Credit Re-Authorization >=20 > FROM >=20 > The Diameter Credit Control Application supports the=20 > server-initiated re-authorization. The credit control server=20 > MAY optionally initiate the credit re-authorization by=20 > issuing a Re-Auth-Request (RAR) as defined in the Diameter=20 > base protocol [DIAMBASE]. The Auth-Application-Id in the RAR=20 > message is set to 4 to indicate the Diameter Credit Control=20 > Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. >=20 > If a credit re-authorization is not already ongoing (i.e. the=20 > credit control session is in OPEN state), a credit control=20 > client that receives such a RAR message with Session-Id equal=20 > to a currently active credit control session acknowledges the=20 > request by sending the Re-Auth-Answer (RAA) message and MUST=20 > initiate the credit re-authorization towards the server by=20 > sending a Credit-Control-Request message with the=20 > CC-Request-Type AVP set to the value UPDATE_REQUEST. The=20 > Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in=20 > the RAA message to indicate an additional message (i.e.=20 > CCR[Update]) is required to complete the procedure. If a=20 > quota was allocated to the session, the credit control client=20 > MUST report the used quota in the Credit-Control-Request.=20 > Note that the end user does not need to be prompted for the=20 > credit re-authorization, since the credit re-authorization is=20 > transparent to the user (i.e it takes place exclusively=20 > between the credit control client and the credit control server). >=20 > If credit re-authorization is ongoing at the time when the=20 > RAR message is received (i.e. RAR-CCR collision), the credit=20 > control client successfully acknowledges the request but it=20 > does not initiate a new credit re-authorization. The=20 > Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA=20 > message to indicate a credit re-authorization procedure is=20 > already ongoing (i.e. the client was in PendingU state when=20 > the RAR was received). The credit control server SHOULD=20 > process the Credit-Control-Request as if it was received in=20 > answer to the server initiated credit re-authorization, and=20 > should consider the server initiated credit re-authorization=20 > process successful upon reception of the Re-Auth-Answer message. >=20 > If several credit control sub-sessions are in use, a credit=20 > control client receiving the RAR command for a given session=20 > will trigger credit re-authorization for all the sub-session=20 > separately. >=20 > TO >=20 > The Diameter Credit Control Application supports the=20 > server-initiated re-authorization. The credit control server=20 > MAY optionally initiate the credit re-authorization by=20 > issuing a Re-Auth-Request (RAR) as defined in the Diameter=20 > base protocol [DIAMBASE]. The Auth- Application-Id in the RAR=20 > message is set to 4 to indicate the Diameter Credit Control=20 > Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. >=20 > Where multiple services in a user's session are supported as=20 > defined in section 5.1.1, the server MAY request credit=20 > re-authorization at: (sub-)session level, credit pool level=20 > granularity, service-identifier level granularity or=20 > rating-group granularity. To request credit re-authorization=20 > at credit pool granularity the server includes in the RAR=20 > message the G-S-U-Pool-Identifier AVP indicating the affected pool.=20 > To request credit re-authorization at service or rating-group=20 > granularity the server includes in the RAR message the=20 > Service-Identifier AVP or the Rating-Group AVP respectively.=20 > To request credit re-authorization for all the ongoing=20 > services within the (sub-)session the server does not include=20 > any of the above mentione AVPs in the RAR message. >=20 > If a credit re-authorization is not already ongoing (i.e. the=20 > credit control session is in OPEN state), a credit control=20 > client that receives a RAR message with Session-Id equal to a=20 > currently active credit control session acknowledges the=20 > request by sending the Re-Auth-Answer (RAA) message and MUST=20 > initiate the credit re- authorization towards the server by=20 > sending a Credit-Control-Request message with the=20 > CC-Request-Type AVP set to the value UPDATE_REQUEST. The=20 > Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in=20 > the RAA message to indicate an additional message (i.e.=20 > CCR[Update]) is required to complete the procedure. If a=20 > quota was allocated to the session, the credit control client=20 > MUST report the used quota in the Credit-Control-Request.=20 > Note that the end user does not need to be prompted for the=20 > credit re-authorization, since the credit re- authorization=20 > is transparent to the user (i.e it takes place exclusively=20 > between the credit control client and the credit control server). >=20 > Where multiple services in a user's session are supported,=20 > the procedure of the above paragraph will be executed at the=20 > granularity as requested by the server in the RAR message. >=20 > If credit re-authorization is ongoing at the time when the=20 > RAR message is received (i.e. RAR-CCR collision), the credit=20 > control client successfully acknowledges the request but it=20 > does not initiate a new credit re-authorization. The=20 > Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA=20 > message to indicate a credit re- authorization procedure is=20 > already ongoing (i.e. the client was in PendingU state when=20 > the RAR was received). The credit control server SHOULD=20 > process the Credit-Control-Request as if it was received in=20 > answer to the server initiated credit re-authorization, and=20 > should consider the server initiated credit re-authorization=20 > process successful upon reception of the Re-Auth-Answer message. > Where multiple services in a user's session are supported, it=20 > may happen that the server requests credit re-authorization=20 > for a credit pool (or for the (sub-)session) and a credit=20 > re-authorization is already ongoing for some of the services=20 > or rating-groups. In this case the client acknowledges the=20 > server request with a RAA message and MUST send a new=20 > Credit-Control-Request message to perform re-authorization=20 > for the remaining services/rating-groups of the pool. The=20 > Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in=20 > the RAA message to indicate an additional message (i.e.=20 > CCR[Update]) is required to complete the procedure. The=20 > server processes the received requests and returns an=20 > appropriate answer to both of the requests. > =20 > The above defined procedures are enabled for each of the=20 > possibly active Diameter credit-control sub-sessions. The=20 > server MAY request re-authorization for an active sub-session=20 > by including the CC-Sub-Session-Id AVP in the RAR message in=20 > addition to the Session-Id AVP. >=20 > -Section 5.5 Graceful Service Termination change second paragraph >=20 > FROM >=20 > This section defines the graceful service termination=20 > optional feature that MAY be supported by the credit control=20 > server. Credit control client implementations MUST support=20 > the Final-Unit-Indication with at least the tear down of the=20 > ongoing service session upon the subscriber has consumed all=20 > the final granted units. >=20 > TO >=20 > This section defines the graceful service termination=20 > optional feature that MAY be supported by the credit control=20 > server. Credit control client implementations MUST support=20 > the Final-Unit-Indication with at least the tear down of the=20 > ongoing service session upon the subscriber has consumed all=20 > the final granted units. > Where independent credit control of multiple services in a=20 > single credit control (sub-)session is supported, it is=20 > possible to use the graceful service termination for each of=20 > the services/rating-groups independently. >=20 > - Section 8 - add to the table:=20 > +---------------------+ =20 > | AVP Flag rules | =20 > =20 > |----+-----+----+-----|----+ =20 > AVP Section | | |SHLD|=20 > MUST| | =20 > Attribute Name Code Defined Data Type |MUST| MAY | NOT|=20 > NOT|Encr| =20 > =20 > -----------------------------------------|----+-----+----+---- > -|----| =20 > G-S-U-Pool- tbd 8.X Unsigned32| M | P | |=20 > V | Y |=20 > Identifier | | | |=20 > | |=20 > G-S-U-Pool- tbd 8.Y Grouped | M | P | |=20 > V | Y |=20 > Reference | | | |=20 > | |=20 > CC-Unit-Type tbd 8.Z Enumerated| | | |=20 > | | =20 > Multiple-Service- tbd 8.V Grouped | M | P | |=20 > V | Y |=20 > Credit-Control | | | |=20 > | | > Multiple-Services-tbd 8.W Enumerated| M | P | |=20 > V | Y |=20 > Indicator | | | |=20 > | | >=20 > - Section 8 amend as follows:=20 >=20 > FROM:=20 > 8.16 Granted-Service-Unit AVP =20 > =20 > Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and=20 > contains the amount of units that the Diameter credit-control > client can provide to the end user until the service must be=20 > released or the new Credit-Control-Request must be sent. A client > is not required to implement all of the unit types, and must treat > unknown or unsupported unit types in the answer message as an > incorrect CCA answer. In that case the client shall terminate > credit control session and indicate in the Termination-Cause AVP > reason DIAMETER_BAD_ANSWER.=20 > =20 > The Service-Identifier and the Rating-Group AVPs are used to > associate the granted units to a given service or rating group.=20 > In case both the Service-Identifier and the Rating-Group AVPs are=20 > included, the target of the granted units is always the service(s)=20 > indicated by the value of the Service-Identifier AVP.=20 > A value of 0 (zero) granted service unit associated to a Service-=20 > entifier(s) or Rating-Group indicates that the corresponding > traffic MUST be denied. Note that in case the credit-control=20 > server want to disconnect the user and close the credit-control=20 > session, it SHOULD use the appropriate error code in the Credit- > Control-Answer message rather than including n times the Granted- > Service-Units AVPs with the value of 0 (zero). =20 > In contrast, a value of max type granted service unit (e.g. max=20 > Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or=20 > Rating-Group indicates that the corresponding traffic is free-of-=20 > charge. With unit type money, the value of the Exponent AVP is set > to 0 (zero) when free-of-charge is indicated. With unit type > service specific, the value of the CC-Service-Specific-Units AVP > is set to FFFFFFFF to indicate free-of-charge.=20 > =20 > The Granted-Service-Unit AVP has the following ABNF grammar: =20 > =20 > Granted-Service-Unit ::=3D < AVP Header: 431 >=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 > TO:=20 > 8.16 Granted-Service-Unit AVP =20 > =20 > Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and=20 > contains the amount of units that the Diameter credit-control > client can provide to the end user until the service must be > released or the new Credit-Control-Request must be sent. A client > is not required to implement all of the unit types, and must treat > unknown or unsupported unit types in the answer message as an > incorrect CCA answer. In that case the client MUST terminate the > credit control session and indicate in the Termination-Cause AVP > reason DIAMETER_BAD_ANSWER.=20 > =20 > The Granted-Service-Unit AVP has the following ABNF grammar: =20 > =20 > Granted-Service-Unit ::=3D < AVP Header: 431 >=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 >=20 > FROM: > 8.21 Requested-Service-Unit AVP =20 > =20 > The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped > and contains the amount of requested units specified by the > Diameter credit-control client. A server is not required to > implement all of the unit types, and must treat unknown or=20 > unsupported unit types as invalid AVPs.=20 > =20 > The Service-Identifier and the Rating-Group AVPs are used to > request units for a given service(s) or rating group when the > service element supports credit control for multiple services in > one credit control session. =20 > =20 > If both the AVPs are present, the Rating-Group AVP indicates the=20 > rating group to which the service(s) specified by the Service- > Identifier(s) belongs. If only the Rating-Group-Id AVP is present,=20 > this is a credit authorization request for all the services that=20 > belongs to the specified rating group.=20 > =20 > A server not implementing the Service-Identifier AVP and the > Rating-Group AVP must treat them as invalid AVPs.=20 > =20 > The Requested-Service-Unit AVP has the following ABNF grammar: =20 > =20 > Requested-Service-Unit ::=3D < AVP Header: 437 >=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 > TO: > 8.21 Requested-Service-Unit AVP =20 > =20 > The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped > and contains the amount of requested units specified by the > Diameter credit-control client. A server is not required to > implement all of the unit types, and must treat unknown or > unsupported unit types as invalid AVPs.=20 >=20 > The Requested-Service-Unit AVP has the following ABNF grammar: =20 > =20 > Requested-Service-Unit ::=3D < AVP Header: 437 >=20 > [ CC-Time ]=20 > [ CC-Money ] =20 > [ CC-Total-Octets ]=20 > [ CC-Input-Octets ]=20 > [ CC-Output-Octets ]=20 > [ CC-Service-Specific-Units ] =20 >=20 > FROM: > 8.30 Used-Service-Unit AVP =20 > =20 > The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446) > and contains the amount of used units measured from the point when > the service became active or, in case of interim interrogations > are used during the session, from the point when the previous > measurement ended.=20 > =20 > The Service-Identifier and the Rating-Group AVPs are used to > associate the used units to a given service or rating group.=20 > When granted service units are associated to a service or rating=20 > group, the credit control client MUST report the corresponding > used service units. If the granted units are associated to a > rating group, the units used by each of the Service-Identifier > belonging to that rating group SHOULD be reported if this > information is available to the credit control client. Therefore, > multiple instances of the Used-Service-Unit AVP MAY be present in > a request, each associated to the relevant Rating-Group-Id and to > the identifier of the service (i.e. Service-Identifier) that > consumed some of the granted units.=20 > =20 > The Used-Service-Unit AVP has the following ABNF grammar:=20 > =20 > Used-Service-Unit ::=3D < AVP Header: 446 >=20 > [ Tariff-Change-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 >=20 > TO: > 8.30 Used-Service-Unit AVP =20 > =20 > The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446) > and contains the amount of used units measured from the point when > the service became active or, in case of interim interrogations > are used during the session, from the point when the previous > measurement ended.=20 > =20 > The Used-Service-Unit AVP has the following ABNF grammar:=20 > =20 > Used-Service-Unit ::=3D < AVP Header: 446 >=20 > [ Tariff-Change-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 >=20 > FROM >=20 > 8.42 Tariff-Change-Usage AVP >=20 > The Tariff-Change-Usage AVP (AVP code 452) is of type=20 > Enumerated and defines whether units are used before, after=20 > or straddled tariff change when a tariff change has occurred=20 > during the reporting period. Omission of this AVP means that=20 > no tariff change has been occurred. >=20 > Tariff-Change-Usage can be one of the following. >=20 > UNIT_BEFORE_TARIFF_CHANGE =09 > 0 >=20 > The used units contains the amount of the units before tariff=20 > change, that is units measured from the point when the=20 > previous measurement ended to the point when tariff change occurred. >=20 > UNIT_AFTER_TARIFF_CHANGE =09 > 1 >=20 > The used units contains the amount of the units after tariff=20 > change has been occurred. >=20 > UNIT_INDETERMINATE =09 > 2 >=20 > The used units contains the amount of units that straddle the=20 > tariff change (e.g. the metering process reports to the=20 > credit-control client in blocks of n octets and one block=20 > straddled the tariff change). >=20 > TO >=20 > 8.42 Tariff-Change-Usage AVP >=20 > The Tariff-Change-Usage AVP (AVP code 452) is of type=20 > Enumerated and defines whether units are used before or,=20 > after a tariff change, or the units straddled tariff change=20 > when a tariff change has occurred during the reporting period.=20 > Omission of this AVP means that no tariff change has been occurred. >=20 > In addition, when present in answer messages as part of the=20 > Multiple-Services-Credit-Control AVP, this AVP defines=20 > whether units are allocated to be used before or after a=20 > tariff change event. > Omission of this AVP in answer messages when the=20 > Tariff-Time-Change AVP is present means that the single quota=20 > mechanism applies. >=20 > Tariff-Change-Usage can be one of the following: >=20 > UNIT_BEFORE_TARIFF_CHANGE =09 > 0 >=20 > When present in the Multiple-Services-Credit-Control AVP,=20 > this value indicates the amount of the units allocated for=20 > use before a tariff change occurs.=20 >=20 > When present in the Used-Service-Unit AVP, this value=20 > indicates the amount of resource units used before a tariff=20 > change had occurred. >=20 > UNIT_AFTER_TARIFF_CHANGE =09 > 1 >=20 > When present in the Multiple-Services-Credit-Control AVP,=20 > this value indicates the amount of the units allocated for=20 > use after a tariff change occurs.=20 >=20 > When present in the Used-Service-Unit AVP, this value=20 > indicates the amount of resource units used after tariff=20 > change had occurred. >=20 > UNIT_INDETERMINATE =09 > 2 >=20 > The used unit contains the amount of units that straddle the=20 > tariff change (e.g. the metering process reports to the=20 > credit-control client in blocks of n octets and one block=20 > straddled the tariff change). This value is to be used only=20 > in the Used-Service-Unit AVP. >=20 > ADD new section 8.x=20 > 8.X G-S-U-Pool-Identifier AVP=20 > The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type > Unsigned32 and identifies a 'credit pool' within the session.=20 >=20 > ADD new section 8.Y=20 > 8.Y G-S-U-Pool-Reference AVP=20 > The G-S-U-Pool-Reference AVP (AVP code tbd) is of type Grouped, > it is used in the Credit-Control-Answer message and associates > the Granted-Service-Units AVP within which it appears with a > credit pool within the session.=20 >=20 > The G-S-U-Pool-Identifier AVP specifies the credit pool from=20 > which credit is drawn for this unit type. >=20 > The CC-Unit-Type AVP specifies the type of units for which credit > is pooled. =20 >=20 > The Unit-Value AVP specifies the multiplier which converts > between service units of type CC-Unit-Type and abstract service > units within the credit pool (and hence to service units of any > other service or rating group associated with the same pool). >=20 > The G-S-U-Pool-Reference AVP has the following ABNF grammar: > =20 > G-S-U-Pool-Reference ::=3D < AVP Header: tbd >=20 > { G-S-U-Pool-Identifier }=20 > { CC-Unit-Type } > { Unit-Value }=20 > ADD new section 8.z=20 > 8.Z CC-Unit-Type AVP=20 > The CC-Unit-Type AVP (AVP code tbd) is of type enumerated and > specifies the type of units which are considered to be pooled > into a credit pool. > The following values are defined for the CC-Unit-Type AVP: >=20 > TIME 0=20 > MONEY 1=20 > TOTAL-OCTETS 2=20 > INPUT-OCTETS 3=20 > OUTPUT-OCTETS 4=20 > SERVICE-SPECIFIC-UNITS 5=20 >=20 > ADD new section 8.V=20 > 8.V Multiple-Services-Credit-Control AVP =20 > =20 > Multiple-Services-Credit-Control AVP (AVP Code tbd) is of type > Grouped and contains the AVPs related to the independent credit > control of multiple services feature. Note that each instance of > this AVP carries units related to one or more services or related > to a single rating-group. > =20 > The Service-Identifier and the Rating-Group AVPs are used to > associate the granted units to a given service or rating group.=20 > In case both the Service-Identifier and the Rating-Group AVPs are=20 > included, the target of the service units is always the service(s)=20 > indicated by the value of the Service-Identifier AVP(s). If only > the Rating-Group-Id AVP is present, the Multiple-Services-Credit- > Control AVP relates to all the services that belongs to the > specified rating group.=20 >=20 > The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- > Pool-Identifier identifying a credit pool within which the units > of the specified type are considered to be pooled. If a G-S-U- > Pool-Reference AVP is present then actual service units of the > specified type MUST also be present. For example, if the G-S-U- > Pool-Reference AVP specifies Unit-Type TIME, then the CC-Time AVP > MUST be present. > =20 > The Tariff-Change-Usage AVP SHOULD be included in a Credit-Control- > Answer command when the Tariff-Time-Change AVP is present. It=20 > instructs the client when the resources in the=20 > Granted-Service-Unit=20 > AVP should be used. When both the Tariff-Time-Change and Tariff- > Change-Usage AVPs are present, the server MUST include two=20 > separate=20 > instances of the Multiple-Services-Credit-Control AVP with the=20 > Granted-Service-Unit AVP associated to the same Service-Identifier=20 > and/or Rating-Group and to the same pool identifier (but with=20 > different multipliers). > Note that these two quotas are grouped in the same pool, thus the=20 > credit pooling mechanism as defined in section 5.1.1 applies. >=20 > A server not implementing the independent credit control of > multiple services functionality MUST treat the Multiple-Services- > Credit-Control AVP as invalid AVP.=20 > =20 > The Multiple-Services-Control AVP has the following ABNF=20 > grammar: =20 > =20 > Multiple-Services-Credit-Control ::=3D < AVP Header: tbd >=20 > [ Granted-Service-Unit ] > [ Tariff-Change-Usage ] =20 > [ Requested-Service-Units ]=20 > *[ Used-Service-Units ]=20 > *[ Service-Identifier ]=20 > [ Rating-Group ]=20 > *[ G-S-U-Pool-Reference ]=20 > [ Validity-Time ]=20 > [ Result-Code ]=20 > [ Final-Unit-Indication ]=20 >=20 > ADD new section 8.W=20 > 8.W Multiple-Services-Indicator AVP=20 > =20 > The Multiple-Services-Indicator AVP (AVP Code tbd) is of type > Enumerated and indicates whether the Diameter Credit-control > client is capable of handling multiple services independently=20 > within a (sub-)session. The absence of this AVP means that > independent credit control of multiple services is not supported. >=20 > A server not implementing the independent credit control of=20 > multiple services MUST treat the Multiple-Services-Indicator AVP > as invalid AVP.=20 >=20 > The following values are defined for the Multiple-Services- > Indicator AVP:=20 > =20 > MULTIPLE_SERVICES_NOT_SUPPORTED 0=20 > Client does not support independent credit control of > multiple servicess within a (sub-)session. > =20 > MULTIPLE_SERVICES_SUPPORTED 1=20 > Client supports independent credit control of multiple > services within a (sub-)session. >=20 >=20 > - section 10. AVP Occurrence Table=20 > ADD a new section: 10.1 Re-Auth-Request AVP Table >=20 > This section defines AVPs that are specific to Diameter Credit=20 > Control Application and MAY be included in the Diameter=20 > Re-Auth-Request (RAR) message [DIAMBASE].=20 > =20 > Re-Auth-Request command MAY include the following additional AVPs: >=20 > +---------------+ =20 > | Command Code |=20 > |-------+-------+ =20 > Attribute Name | RAR | RAA | =20 > ------------------------------+-------+-------+ =20 > CC-Sub-Session-Id | 0-1 | 0-1 | =20 > G-S-U-Pool-Identifier | 0-1 | 0-1 | > Service-Identifier | 0-1 | 0-1 | > Rating-Group | 0-1 | 0-1 | > ------------------------------+-------+-------+=20 >=20 From owner-aaa-wg@merit.edu Fri Feb 13 02:43:10 2004 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 CAA26732 for ; Fri, 13 Feb 2004 02:43:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C36FE9128B; Fri, 13 Feb 2004 02:42:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90FC49128C; Fri, 13 Feb 2004 02:42: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 156C69128B for ; Fri, 13 Feb 2004 02:42:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id F0E375DF8D; Fri, 13 Feb 2004 02:42: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 2021B5DF77 for ; Fri, 13 Feb 2004 02:42:54 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D7gqv07602 for ; Fri, 13 Feb 2004 09:42:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 09:42:49 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:42:51 +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]: DCC: issue Wrong multiple services mechanism in Flow X Date: Fri, 13 Feb 2004 09:42:50 +0200 Message-ID: Thread-Topic: DCC: issue Wrong multiple services mechanism in Flow X Thread-Index: AcPxghTT6QcfQoAqSBOxVBlq5igLXwAguLHQ From: To: , Cc: , , , , X-OriginalArrivalTime: 13 Feb 2004 07:42:51.0448 (UTC) FILETIME=[FBC7EB80:01C3F204] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned issue 20. John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 12 February, 2004 18:06 > To: aaa-wg@merit.edu > Cc: mwatson@nortelnetworks.com; crich@nortelnetworks.com;=20 > Loughney John > (Nokia-NRC/Helsinki); harri.hakala@ericsson.com; > leena.mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere) > Subject: [AAA-WG]: DCC: issue Wrong multiple services=20 > mechanism in Flow > X >=20 >=20 > Description of issue: Wrong multiple services mechanism in Flow X > Submitter name: Mark Watson/Chris Richards/Marco Stura/Harri Hakala > Date first submitted: 12.02.2004 > Reference:=20 > Document: draft-ietf-aaa-diameter-cc-02.txt=20 > Comment type: T=20 > Priority: 1=20 > Section: Various=20 >=20 > Rationale/Explanation of issues: >=20 > The mechanism in Flow X is affected by all the drawbacks as > described in Issue 16 and should be replaced by the following > flow. >=20 > Requested change: >=20 > Replace Flow X with the new one hereafter >=20 > A.10 Flow X=20 > =20 > The Diameter Credit Control Application defines the Multiple- > Services-Credit-Control AVP that can be used to support independent=20 > credit control of multiple services in a single credit control=20 > (sub-)session for service elements that have such capabilities.=20 > It is possible to request and allocate resources as a credit=20 > pool that is shared between services or rating groups.=20 > =20 > The flow example hereafter illustrates a usage scenario where=20 > the Credit-control client and server support independent credit=20 > control of multiple services as defined in section 5.1.1.=20 > It is assumed that Service-Identifiers, Rating-Groups and their > associated parameters (e.g. IP 5-tuple) are locally configured=20 > in the Service Element or provisioned by another entity than=20 > the credit control server. > =20 > End-User Service Element CC Server > (CC client) =20 > |(1)User logon | |=20 > |------------------>|(2)CCR(initial, Service-Id access, | > | | Access specific AVPs, | > | | Multiple-Service-Indicator) | > | |---------------------------------------->|=20 > | |(3)CCA(Multiple-Services-CC ( |=20 > | | Granted-Units(Total-Octets), |=20 > | | Service-Id access, | > | | Validity-time, | > | | G-S-U-Pool-Reference(Pool-Id 1, | > | | Multiplier 10))) | > | |<----------------------------------------| > : : :=20 > |(4)Service-Request (Service 1) |=20 > |------------------>|(5)CCR(update, Multiple-Services-CC( |=20 > | | Requested-Units(), Service-Id 1, | > | | Rating-Group 1)) | > | |---------------------------------------->| > | |(6)CCA(Multiple-Services-CC ( |=20 > | | Granted-Units(Time), |=20 > | | Rating-Group 1, | > | | G-S-U-Pool-Reference(Pool-Id 1, | > | | Multiplier 1))) | > | |<----------------------------------------| > : : :=20 > |(7)Service-Request (Service 2) |=20 > |------------------>| |=20 > : : : > : : : > |(8)Service-Request (Service 3&4) |=20 > |------------------>|(9)CCR(update, Multiple-Services-CC ( |=20 > | | Requested-Units(), Service-Id 3, | > | | Rating-group 2), | > | | Multiple-Services-CC ( | > | | Requested-Units(), Service-Id 4, | > | | Rating-Group 3)) | > | |---------------------------------------->| > | |(10)CCA(Multiple-Services-CC ( |=20 > | | Granted-Units(Total-Octets), |=20 > | | Service-Id 3, Rating-group 2, | > | | Validity-time, | > | | G-S-U-Pool-Reference(Pool-Id 2, | > | | Multiplier 2)), | > | | Multiple-Services-CC ( |=20 > | | Granted-Units(Total-Octets), |=20 > | | Service-Id 4, Rating-group 3 | > | | Validity-time, | > | | Final-Unit-Ind.(Terminate), | > | | G-S-U-Pool-Reference(Pool-Id 2, | > | | Multiplier 5))) | > | |<----------------------------------------| > : : :=20 > : : :=20 > | +--------------+ | |=20 > | |Validity time | |(11)CCR(update, |=20 > | |expires for | | Multiple-Services-CC ( |=20 > | |Service-Id | | Used-Units(In-Octets,Out-Octets),| > | | access | | Service-Id access)) | > | +--------------+ |---------------------------------------->| =20 > | |(12)CCA(Multiple-Services-CC ( | > | | Granted-Units(Total-Octets), |=20 > | | Service-Id access, |=20 > | | Validity-time, | > | | G-S-U-Pool-Reference(Pool-Id 1, |=20 > | | Multiplier 10))) | > | |<----------------------------------------|=20 > : : :=20 > : : :=20 > | +--------------+ | |=20 > | |Total Quota | |(13)CCR(update, |=20 > | |elapses for | | Multiple-Services-CC ( |=20 > | |pool 2: | | Used-Units(In-Octets,Out-Octets),| > | |service 4 not | | Service-Id 3, Rating-group 2), | > | |allowed, | | Multiple-Services-CC ( |=20 > | |service 3 cont| | Used-Units(In-Octets,Out-Octets),| > | +--------------+ | Service-Id 4, Rating-group 3)) | > | |---------------------------------------->| =20 > | |(14)CCA(Multiple-Services-CC ( | > | | Result-Code 4011, |=20 > | | Service-Id 3)) | > | |<----------------------------------------|=20 > : : :=20 > : : : =20 > |(15) User logoff | |=20 > |------------------>|(16)CCR(term, |=20 > | | Multiple-Services-CC ( |=20 > | | Used-Units(In-Octets,Out-Octets),| > | | Service-Id access), | > | | Multiple-Services-CC ( |=20 > | | Used-Units(Time), | > | | Service-Id 1, Rating-group 1), | > | | Multiple-Services-CC ( |=20 > | | Used-Units(Time), | > | | Service-Id 2, Rating-group 1)) | > | |---------------------------------------->|=20 > | |(17)CCA(term) |=20 > | |<----------------------------------------|=20 > =20 > Figure A.10: Independent credit control of multiple services in a > Credit Control (sub-)Session, flow example.=20 > =20 >=20 > The user logs onto the network (1). The Service Element sends=20 > a Diameter Credit-Control-Request with CC-Request-Type set to=20 > INITIAL_REQUEST to the Diameter credit-control server to=20 > perform credit authorization for the bearer service (e.g.=20 > internet access service) and to establish a credit control=20 > session (2). In this message the credit-control client=20 > indicates support for independent credit control of multiple=20 > services within the session by including the=20 > Multiple-Service-Indicator AVP. The Diameter credit-control=20 > server checks the end user's account balance, based on the=20 > rating information received from the client (i.e. Service-Id=20 > and access specific AVPs) rates the request and reserves=20 > credit from the end user's account. Say the server reserves=20 > $5 and determines the cost is $1/MB. It then returns to the=20 > service element a Credit-Control-Answer message that include=20 > the Multiple-Services-Credit-Control AVP with a quota of 5MB=20 > associated to the Service-Id (access), to a multiplier value=20 > of 10 and to the Pool-Id 1 (3).=20 >=20 > The user uses Service 1 (4). The service element sends a=20 > Diameter Credit-Control-Request with CC-Request-Type set to=20 > UPDATE_REQUEST to the credit control server to perform credit=20 > authorization for service 1 (5). This message includes the=20 > Multiple-Services-Credit-Control AVP to request service units=20 > for the Service 1 that belong to Rating-Group 1. The Diameter=20 > credit-control server determines that Service 1 draws credit=20 > resources from the same account as the access service (i.e.=20 > pool 1), based on Service-Id/Rating-Group rates the request=20 > and updates the existing reservation by requesting more=20 > credit. Say the server reserves $5 more (now the reservation=20 > is $10) and determines the cost is $0.1/minutes. The server=20 > authorizes the whole Rating-Group, it then returns to the=20 > service element a Credit-Control-Answer message that include=20 > the Multiple-Services-Credit-Control AVP with a quota of=20 > 50min. associated to the Rating-Group 1, to a multiplier=20 > value of 1 and to the Pool-Id 1 (6). The client adjusts the=20 > total amount of resources for pool 1 according the received=20 > quota, which gives M for Pool 1 =3D 100. >=20 > The user uses Service 2 that belongs to the authorized=20 > Rating-Group 1 (7). Resources are then consumed from the pool 1. >=20 > The user requests now Service 3 and Service 4 as well, that=20 > are not authorized (8). The service element sends a Diameter=20 > Credit-Control-Request with CC-Request-Type set to=20 > UPDATE_REQUEST to the credit control server to perform credit=20 > authorization for service 3&4 (9). This message includes two=20 > instances of the Multiple-Services-Credit-Control AVP to=20 > request service units for the Service 3 that belong to=20 > Rating-Group 2 and for the Service 4 that belong to=20 > Rating-Group 3. The Diameter credit-control server determines=20 > that Service 3&4 draw credit resources from another account=20 > (i.e. pool 2), it checks the end user's account balance and=20 > based on Service-Ids/Rating-Groups information rates the=20 > request and reserve credit from pool 2. > Say the server reserves $5 and determines that Service 3=20 > costs $0.2/MB and Service 4 costs $0.5/MB. The server=20 > authorizes only Services 3&4, it then returns to the service=20 > element a Credit-Control-Answer message that include two=20 > instances of the Multiple-Services-Credit-Control AVP (10).=20 > One instance grants a quota of 12.5MB associated to the=20 > Service-Id 3, to a multiplier value of 2 and to the Pool-Id=20 > 2. The other instance grants a quota of 5MB associated to the=20 > Service-Id 4, to a multiplier value of 5 and to the Pool-Id 2. > The server also determines that pool 2 is exhausted and=20 > Service 4 is not allowed to continue after these units will=20 > be consumed. Therefore the Final-Unit-Indication AVP with=20 > action TERMINATE is associated to the Service-Id 4. The=20 > client calculates the total amount of resources that can be=20 > used for Pool 2 according the received quotas and=20 > multipliers, which give M for Pool 2 =3D 50. >=20 > The Validity-Time for the access service expires. The service=20 > element sends a Credit-Control-Request message to the server=20 > to perform credit re-authorization for Service-Id (access)=20 > (11). This message carries one instance of the=20 > Multiple-Services-Credit-Control AVP that includes the units=20 > used by this service. Say the total amount of used units is=20 > 4MB. The client adjusts the total amount of resources for=20 > Pool 1 accordingly, which gives M for Pool 1 =3D 60. > The server deducts $4 from the user's account and updates the=20 > reservation by requesting more credit. Say the server=20 > reserves $5 more (now the reservation is $11) and already=20 > knows the cost of the Service-Id (access) that is $1/MB. It=20 > then returns to the service element a Credit-Control-Answer=20 > message that include the Multiple-Services-Credit-Control AVP=20 > with a quota of 5MB associated to the Service-Id (access), to=20 > a multiplier value of 10 and to the Pool-Id 1 (12). The=20 > client adjusts the total amount of resources for pool 1=20 > according the received quota, which gives M for Pool 1 =3D 110. >=20 > Services 3&4 consume the total amount of Pool 2 credit=20 > resources (i.e. C1*2 + C2*5 >=3D M). The service element=20 > immediately starts the TERMINATE action concerning Service 4=20 > and sends a Credit-Control-Request message with=20 > CC-Request-Type set to UPDATE_REQUEST to the credit control=20 > server to perform credit re-authorization for Service 3 (13).=20 > This message contains two instances of the=20 > Multiple-Services-Credit-Control AVP to report the units used=20 > by Service 3 and Service 4. The server deducts the last $5=20 > from the user's account (Pool 2) and returns the answer with=20 > Result-Code 4011 in the Multiple-Services-Credit-Control AVP=20 > to indicate that Service 3 can continue without credit control (14). >=20 > The end user logs off from the network (15). To debit the=20 > used units from the end user's account and to stop the credit=20 > control session, the service element sends a Diameter=20 > Credit-Control-Request with CC-Request-Type set to=20 > TERMINATION_REQUEST to the credit control server (16). This=20 > message contains the units consumed by each of the used=20 > services in multiple instances of the=20 > Multiple-Services-Credit-Control AVP. The used units are=20 > associated with the relevant Service-Identifier and=20 > Rating-Group. The Diameter credit-control server debits the=20 > used units to the user's account (Pool 1) and acknowledges=20 > the session termination by sending a Diameter=20 > Credit-Control-Answer to the service element (17). >=20 >=20 From owner-aaa-wg@merit.edu Fri Feb 13 04:15:44 2004 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 EAA29702 for ; Fri, 13 Feb 2004 04:15:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8328A9128E; Fri, 13 Feb 2004 04:15:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54D3A9128C; Fri, 13 Feb 2004 04:15:32 -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 8F5059128E for ; Fri, 13 Feb 2004 04:15:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5786C5DDF7; Fri, 13 Feb 2004 04:15:29 -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 A35CE5DE00 for ; Fri, 13 Feb 2004 04:15:27 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 2F1B76A906; Fri, 13 Feb 2004 11:15:11 +0200 (EET) Message-ID: <402C9533.8020800@kolumbus.fi> Date: Fri, 13 Feb 2004 11:13:23 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'aaa-wg@merit.edu'" Cc: Pasi Eronen , Bernard Aboba Subject: [AAA-WG]: new revision of the NAI RFC 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 For your information: Pasi, Bernard, and myself published a new draft, draft-arkko-roamops-rfc2486bis-00.txt which is an update of the original NAI specification. It provides a few corrections, clarifications, and support for a couple of new features such as privacy and international character sets. It even touches upon network selection feature discussed in EAP WG by talking about the bang syntax. Feedback appreciated. Do folks think a bis version makes sense? Comments on content? Missed corrections? New functions make sense? Note that strictly speaking, there is no official home at the IETF for this discussion, so if we generate lengthy discussions based on this I'll promise to create a new list for the purpose and not disturb the AAA, AAAEXT or EAP WGs. Full list of modifications: o International character set support has been added for both usernames and realms. o Username privacy support has been added. o A requirement to support NAI length of at least 253 octets has been added, and compatibility considerations among NAI lengths in this specification and various AAA protocols are discussed. o The mediating network syntax and its implications have been fully described and not given only as an example. Note that this syntax is not intended to be a full solution to network discovery and selection needs as defined in [draft-ietf-eap-netsel-problem]. Rather, it is intended as a clarification of RFC 2486. It could also be used as a component in approaches such as [draft-adrangi]. o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification. o The x and special BNF entries have been clarified. For more information, see the following URLs: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt http://www.arkko.com/publications/nai/naibis.html --Jari From owner-aaa-wg@merit.edu Fri Feb 13 12:10:22 2004 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 MAA20589 for ; Fri, 13 Feb 2004 12:10:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDCE9912A0; Fri, 13 Feb 2004 12:10:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A75399129F; Fri, 13 Feb 2004 12:10: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 EB1EC912A0 for ; Fri, 13 Feb 2004 12:10:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1F8A5DE2A; Fri, 13 Feb 2004 12:10:08 -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 C4FE35DE23; Fri, 13 Feb 2004 12:10:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DHA6v20644; Fri, 13 Feb 2004 19:10:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 19:10:06 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 19:10: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_01C3F254.39D09D1D" Subject: RE: [AAA-WG]: DCC: new issue to replace issues 16, 17 and 18 Date: Fri, 13 Feb 2004 19:10:05 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0443@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: new issue to replace issues 16, 17 and 18 Thread-Index: AcPySfgjkuclnNoiTYGW5HuH8Eus4AAAz4gw From: To: Cc: , , , , , , , X-OriginalArrivalTime: 13 Feb 2004 17:10:06.0203 (UTC) FILETIME=[3A1364B0:01C3F254] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F254.39D09D1D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, =20 >If I understand the new mechanism correctly, there is a monetary = reservation for each quota that is allocated as part of the=20 >session, and there is a conversion factor that could be used by the = client to transfer between quotas of sub-sessions.=20 =20 >Would this lead to more funds being reserved on the server? Certainly, = I've been focusing on credit fragmentation across=20 >multiple types of clients rather than on a single client and anything = which leads to a higher monetary value being reserved=20 >for a session on one client would make credit fragmentation worse. If = my understanding is correct, that would be my=20 >concern.=20 =20 There is a monetary reservation for each quota, but this is on demand = only when the service is really requested by the user. The server most = likely consider always one single reservation per credit pool, and = updates this reservation according to the needs. The reservation is then = reflected to the client by means of the pool-id and the multiplier. This = means that the smallest possible chunk of credit is added in real time = as needed. =20 Note that in principle the report occur only when the whole reserved = amount (100%) has been consumed by the end user as before.=20 =20 With the previous mechanism it was not possible to update the = *reservation* to the client at all, as a consequence the server did need = to reserve a bigger chunk of credit as soon as a request for a = non-authorized rating-group was received just in case the end-user = issued one or more new service requests for that rating-group. But = without certainty that any service request would have come! =20 So, the new mechanism ensure the smallest possible money allocation on a = per real need bases, hence minimizing the credit fragmentation effect = that in practice was worse with the previous mechanism.=20 =20 This has been actually one of the rational behind the new mechanism, I = hope this explanation addresses your concern. =20 Regards Marco ------_=_NextPart_001_01C3F254.39D09D1D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 John,
 
>If = I understand=20 the new mechanism correctly, there is a monetary reservation for each = quota that=20 is allocated as part of the
>session, and=20 there is a conversion factor that could be used by the client to = transfer=20 between quotas of sub-sessions.=20
 
>Would this lead=20 to more funds being reserved on the server?  Certainly, I've been = focusing=20 on credit fragmentation across
>multiple types=20 of clients rather than on a single client and anything which leads to a = higher=20 monetary value being reserved
>for a session on=20 one client would make credit fragmentation worse.  If my = understanding is=20 correct, that would be my
>concern.=20
 
There=20 is a monetary reservation for each quota, but this is on demand only = when the=20 service is really requested by the user. The server most likely consider = always=20 one single reservation per credit pool, and updates this reservation = according=20 to the needs. The reservation is then reflected to the client by means = of the=20 pool-id and the multiplier. This means that the smallest = possible=20 chunk of credit is added in real time as = needed.
 
Note that in principle the report = occur only=20 when the whole reserved amount (100%) has been consumed by the end = user as=20 before.
 
With=20 the previous mechanism it was not possible to update the *reservation* = to the=20 client at all, as a consequence the server did need to reserve a bigger = chunk of=20 credit as soon as a request for a non-authorized rating-group was = received just=20 in case the end-user issued one or more new service requests for that=20 rating-group. But without certainty that any service request would have=20 come!
 
So,=20 the new mechanism ensure the smallest possible money allocation on a per = real=20 need bases, hence minimizing the credit fragmentation effect that = in=20 practice was worse with the previous=20 mechanism. 
 
This=20 has been actually one of the rational behind the new mechanism, I = hope this=20 explanation addresses  your concern.
 
Regards
Marco
------_=_NextPart_001_01C3F254.39D09D1D-- From aaa-admin@ietf.org Sat Feb 14 11:05:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22407 for ; Sat, 14 Feb 2004 11:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Ht-0007MY-Tm; Sat, 14 Feb 2004 11:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Hg-0007M2-Vb for aaa@optimus.ietf.org; Sat, 14 Feb 2004 11:04:48 -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 LAA22376 for ; Sat, 14 Feb 2004 11:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2He-0006CB-00 for aaa@ietf.org; Sat, 14 Feb 2004 11:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2Gg-00068U-00 for aaa@ietf.org; Sat, 14 Feb 2004 11:03:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1As2Fq-00064m-00 for aaa@ietf.org; Sat, 14 Feb 2004 11:02:54 -0500 Received: from h23n4fls22o1077.bredband.comhem.se ([81.226.230.23]) by mx2.foretec.com with smtp (Exim 4.24) id 1As2Fq-0003ZN-5Z for aaa@ietf.org; Sat, 14 Feb 2004 11:02:55 -0500 Received: from [212.236.24.168] by h23n4fls22o1077.bredband.comhem.se id <9215603-36483>; Sat, 14 Feb 2004 17:55:51 +0200 Message-ID: From: "Garth Lujan" Reply-To: "Garth Lujan" To: , Date: Sat, 14 Feb 04 17:55:51 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8BD9._66_E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.6 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, EARN_MONEY,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.1 EARN_MONEY BODY: Message talks about earning money * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Make over $1000 per day 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: , --8BD9._66_E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable eoydxu 8

 

In my = book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

I don't want any more emails

jewt djeendiuuhbog --8BD9._66_E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Feb 14 11:06:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22444 for ; Sat, 14 Feb 2004 11:06:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Ij-0007PX-Gg for aaa-archive@odin.ietf.org; Sat, 14 Feb 2004 11:05:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EG5rkj028486 for aaa-archive@odin.ietf.org; Sat, 14 Feb 2004 11:05:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Ij-0007PN-C2 for aaa-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 11:05:53 -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 LAA22437 for ; Sat, 14 Feb 2004 11:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2Ig-0006GL-00 for aaa-web-archive@ietf.org; Sat, 14 Feb 2004 11:05:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As2I0-0006D4-00 for aaa-web-archive@ietf.org; Sat, 14 Feb 2004 11:05:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Ht-0007MY-Tm; Sat, 14 Feb 2004 11:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Hg-0007M2-Vb for aaa@optimus.ietf.org; Sat, 14 Feb 2004 11:04:48 -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 LAA22376 for ; Sat, 14 Feb 2004 11:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2He-0006CB-00 for aaa@ietf.org; Sat, 14 Feb 2004 11:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2Gg-00068U-00 for aaa@ietf.org; Sat, 14 Feb 2004 11:03:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1As2Fq-00064m-00 for aaa@ietf.org; Sat, 14 Feb 2004 11:02:54 -0500 Received: from h23n4fls22o1077.bredband.comhem.se ([81.226.230.23]) by mx2.foretec.com with smtp (Exim 4.24) id 1As2Fq-0003ZN-5Z for aaa@ietf.org; Sat, 14 Feb 2004 11:02:55 -0500 Received: from [212.236.24.168] by h23n4fls22o1077.bredband.comhem.se id <9215603-36483>; Sat, 14 Feb 2004 17:55:51 +0200 Message-ID: From: "Garth Lujan" Reply-To: "Garth Lujan" To: , Date: Sat, 14 Feb 04 17:55:51 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8BD9._66_E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.6 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, EARN_MONEY,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.1 EARN_MONEY BODY: Message talks about earning money * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Make over $1000 per day 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: , --8BD9._66_E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable eoydxu 8

 

In my = book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

I don't want any more emails

jewt djeendiuuhbog --8BD9._66_E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Feb 16 03:50:41 2004 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 DAA06014 for ; Mon, 16 Feb 2004 03:50:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F16791218; Mon, 16 Feb 2004 03:50:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04D5E9121B; Mon, 16 Feb 2004 03:50:28 -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 1183E91218 for ; Mon, 16 Feb 2004 03:50:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE9F45DE69; Mon, 16 Feb 2004 03:50:26 -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 80FBC5DE66 for ; Mon, 16 Feb 2004 03:50:25 -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 i1G8oI311794 for ; Mon, 16 Feb 2004 10:50:18 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Feb 2004 10:50:18 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 10:50:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: DCC: Issue: Final consistency alignments across the document Date: Mon, 16 Feb 2004 10:50:16 +0200 Message-ID: Thread-Topic: DCC: Issue: Final consistency alignments across the document Thread-Index: AcP0aDsxMz7eSyXIT4GKl5FHZGjRWQ== From: To: Cc: , , , , , X-OriginalArrivalTime: 16 Feb 2004 08:50:16.0403 (UTC) FILETIME=[E6005230:01C3F469] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Description of issue: Final consistency alignements across the document Submitter name: =20 Date first submitted: 16.02.2004=20 Reference:=20 Document: draft-ietf-aaa-diameter-cc-02.txt=20 Comment type: T=20 Priority: 1=20 Section: Various=20 Rationale/Explanation of issues:=20 After the introduction of the multiple services in a credit control = session there is need for some polishing and consistency alignments = across the document due to existing old text, listed hereafter. We can have cases with multiple services where we may change from time = to volume (or viceversa) with the tariff switch. Tariff switch should = carry before quota and after quota i.e. two instances of the same unit = type associated with a service/rating group. Also, result code/validity-time/final unit may be sent at M-S-C-C level = hence it is not always true that the specified behavior applies to the = whole session. Finally, some consistency update along the document concerning the = Service-Identifier AVP (done according to section 4.1) is required. The old text need to be made consistent. Requested change: -Section 5.1 second - seventh paragraphs FROM If the Diameter credit-control client knows the cost of the service = event (e.g. a content server delivering ringing tones may know their = cost) the monetary amount to be charged is included in the = Requested-Service-Unit AVP. If the Diameter credit-control client does = not know the cost of the service event, the Requested-Service-Unit AVP = MAY contain the number of requested service events and the = Service-Parameter-Info AVP MAY contain the service event information to = be rated by the credit-control server. The Service-Parameter-Info AVP = always refers to the requested service units. Alternatively, service = event information to be rated can be sent as service specific AVPs. =20 The Event-Timestamp AVP contains the time when the service event is = requested in the service element. .................=20 The credit-control server returns the Granted-Service-Unit AVP in the = Answer message to the Diameter credit-control client. The = Granted-Service-Unit AVP contains the amount of service units that the = Diameter credit-control client can provide to the end user until a new = Credit-Control-Request MUST be sent to the credit-control server. If = several unit types are sent in the Answer message the credit-control = client MUST handle each unit type separately. There MUST be maximum one = instance of the same unit type in one Answer message. In case multiple = quotas are conveyed to the credit control client, there MUST be maximum = one instance of the same unit type associated to a Service-Identifier, = or set of Service-Identifiers, or associated to a Rating-Group. The type = of the Granted-Service-Unit AVP can be time, volume, service specific or = money depending on the type of service event. It is not allowed to = change the unit type(s) within the session. =20 If the credit-control server determines that no further control is = needed for the service it MAY include the result code indicating that = the credit-control is not applicable (e.g. service is free of charge) = and terminate the credit-control session. The Credit-Control-Answer message MAY also include the = Final-Unit-Indication AVP to indicate that the answer message contains = the final units for the service session. After the end user has consumed = these units, the Diameter credit-control-client MUST behave as described = in section 5.5. TO If the Diameter credit-control client knows the cost of the service = event (e.g. a content server delivering ringing tones may know their = cost) the monetary amount to be charged is included in the = Requested-Service-Unit AVP. If the Diameter credit-control client does = not know the cost of the service event, the Requested-Service-Unit AVP = MAY contain the number of requested service events. The = Service-Identifier AVP, in case of multiple services the = Service-Identifier AVP or the Rating-Group AVP within the = Multiple-Services-Credit-Control AVP, always indicates the concerned = service. Additional service event information to be rated MAY be sent = as service specific AVPs or MAY be sent within the = Service-Parameter-Info AVP at command level. The Event-Timestamp AVP contains the time when the service event is = requested in the service element. The Subscription-Id AVP SHOULD be = included to identify the End-User in the credit-control server.=20 ................................. The credit-control server returns the Granted-Service-Unit AVP in the = Answer message to the Diameter credit-control client. The = Granted-Service-Unit AVP contains the amount of service units that the = Diameter credit-control client can provide to the end user until a new = Credit-Control-Request MUST be sent to the credit-control server. If = several unit types are sent in the Answer message the credit-control = client MUST handle each unit type separately. The type of the = Granted-Service-Unit AVP can be time, volume, service specific or money = depending on the type of service event. The unit type(s) SHOULD NOT be = changed within an ongoing credit-control session.=20 There MUST be maximum one instance of the same unit type in one Answer = message. However, in case multiple quotas are conveyed to the credit = control client in the Multiple-Services-Credit-Control AVPs, it is = possible to carry two instances of the same unit type associated to a = service-identifier/rating-group for instance when a tariff time change = is expected. If the credit-control server determines that no further control is = needed for the service it MAY include the result code indicating that = the credit-control is not applicable (e.g. service is free of charge). = This result code at command level implies that the credit-control = session is to be terminated. The Credit-Control-Answer message MAY also include the = Final-Unit-Indication AVP to indicate that the answer message contains = the final units for the service. After the end user has consumed these = units, the Diameter credit-control-client MUST behave as described in = section 5.5. - Section 5.2 third paragraph FROM When the used units are reported to the credit-control=20 server the credit-control client will not have any units in=20 its possession before new granted units are received from the=20 credit-control server. When the new granted units are=20 received from the credit-control server these units apply=20 from the point where the measurement of the reported used=20 units stopped. TO When the used units are reported to the credit-control=20 server, the credit-control client will not have any units in=20 its possession before new granted units are received from the=20 credit-control server. When the new granted units are=20 received from the credit-control server these units apply=20 from the point where the measurement of the reported used=20 units stopped. Where independent credit-control of multiple=20 services is supported, this process may be executed for one or more services, a single rating-group or for a pool=20 within the (sub-)session. - Section 5.2 fifth and last paragraphs=20 FROM The Requested-Service-Unit AVP contains the new amount of requested = service units. The Used-Service-Unit AVP contains the amount = .............. The Credit-Control-Answer message MAY also include the = Final-Unit-Indication AVP to indicate that the answer message contains = the final units for the service session. After the end user has consumed = these units, the Diameter credit-control-client MUST behave as described = in section 5.5. TO The Requested-Service-Unit AVP MAY contains the new amount of requested = service units. The Used-Service-Unit AVP contains the amount = .............. The Credit-Control-Answer message MAY also include the = Final-Unit-Indication AVP to indicate that the answer message contains = the final units for the service. After the end user has consumed these = units, the Diameter credit-control-client MUST behave as described in = section 5.6. - Section 5.5.1 FROM The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not = include any other information. Upon the subscriber has consumed the = final granted units the service element MUST terminate the service = session and MUST send a final Credit-Control-Request message to the = credit control server. The CC-Request-Type AVP in the request is set to = the value TERMINATION_REQUEST. This is the default handling applicable = whenever the credit control client receives an unsupported = Final-Unit-Action value and MUST be supported by all the Diameter credit = control client implementations conforming to this specification.. TO The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not = include any other information. Upon the subscriber has consumed the = final granted units the service element MUST terminate the service. This = is the default handling applicable whenever the credit control client = receives an unsupported Final-Unit-Action value and MUST be supported by = all the Diameter credit control client implementations conforming to = this specification. A final Credit-Control-Request message to the credit = control server MUST be sent if the Final-Unit-Indication AVP indicating = action TERMINATE was present at command level. The CC-Request-Type AVP = in the request is set to the value TERMINATION_REQUEST. - section 5.5.2 fifth paragraph FROM ..............Therefore, the credit control client MUST NOT include any = rating related AVP in the request sent upon all the final granted units = have been consumed as a hint to the server that the requested final unit = action started, rating and money reservation are not required. = .................. TO .......................... Therefore, the credit control client MUST NOT include any rating related = AVP in the request sent upon all the final granted units have been = consumed as a hint to the server that the requested final unit action = started, rating and money reservation are not required (when the = Multiple-Services-Credit-Control AVP is used, the Service-Identifier or = Rating-Group AVPs is included to indicate the concerned services). = .................. - section 5.5.2 sixth paragraph FROM ............................. The server will return the appropriate = Result-Code (see section 9.1) in the Credit-Control-Answer message in = order to close the credit control session and implement the = policy-defined action. ................... TO ............................. The server will return the appropriate = Result-Code (see section 9.1) in the Credit-Control-Answer message in = order to implement the policy-defined action. = ................................................... - Section 6.1 second paragraph FROM A Diameter credit-control client requesting the cost information MUST = set the CC-Request-Type AVP equal to EVENT_REQUEST, include the = Requested-Action AVP set to PRICE_ENQUIRY and set the requested service = event information into the Service-Parameter-Info AVP in the = Credit-Control-Request message. TO A Diameter credit-control client requesting the cost information MUST = set the CC-Request-Type AVP equal to EVENT_REQUEST, include the = Requested-Action AVP set to PRICE_ENQUIRY and set the requested service = event information into the Service-Identifier AVP in the = Credit-Control-Request message. Additional service event information MAY = be sent as service specific AVPs or MAY be sent within the = Service-Parameter-Info AVP. - Section 6.3 third paragraph FROM The Diameter credit-control client can include the monetary amount to be = charged in the Requested-Service-Unit AVP, if it knows the cost of the = service event. If the Diameter credit-control client does not know the = cost of the service event, then the Service-Parameter-Info AVP SHOULD = contain the service event information to be rated by the credit-control = server. The Service-Parameter-Info AVP always refers to the requested = service unit. TO The Diameter credit-control client MAY include the monetary amount to be = charged in the Requested-Service-Unit AVP, if it knows the cost of the = service event. If the Diameter credit-control client does not know the = cost of the service event, the Requested-Service-Unit AVP MAY contain = the number of requested service events. The Service-Identifier AVP = always indicates the concerned service, additional service event = information to be rated MAY be sent as service specific AVPs or MAY be = sent within the Service-Parameter-Info AVP. - Section 6.4 third paragraph FROM The Diameter credit-control client MAY include the monetary amount to be = refunded in the Requested-Service-Unit AVP. If the Diameter = credit-control client does not know the monetary amount to be refunded, = then the Service-Parameter-Info AVP, or other rating AVPs, SHOULD = contain the service event information to be rated by the credit-control = server TO The Diameter credit-control client MAY include the monetary amount to be = refunded in the Requested-Service-Unit AVP. The Service-Identifier AVP = always indicates the concerned service. If the Diameter credit-control = client does not know the monetary amount to be refunded, in addition to = the Service-Identifier AVP it MAY send service specific AVPs or the = Service-Parameter-Info AVP containing additional service event = information to be rated. - Section 8.20 FROM DIRECT_DEBITING 0=20 Direct debiting indicates that the request is to decrease the end user's = account according to information specified in the Requested-Service-Unit = AVP and/or Service-Parameter-Info AVP. The Granted-Service Unit AVP in = the Credit-Control-Answer command contains the debited units. REFUND_ACCOUNT 1=20 Refund account indicates that the request is to increase the end user's = account according to information specified in the Requested-Service-Unit = AVP and/or Service-Parameter-Info AVP. The Granted-Service Unit AVP in = the Credit-Control-Answer command contains the refunded units. =20 TO DIRECT_DEBITING 0=20 Direct debiting indicates that the request is to decrease the end user's = account according to information specified in the Requested-Service-Unit = AVP and/or Service-Identifier AVP (additional rating information may be = included in service specific AVPs or in the Service-Parameter-Info AVP). = The Granted-Service Unit AVP in the Credit-Control-Answer command = contains the debited units.=20 REFUND_ACCOUNT 1=20 Refund account indicates that the request is to increase the end user's = account according to information specified in the Requested-Service-Unit = AVP and/or Service-Identifier AVP (additional rating information may be = included in service specific AVPs or in the Service-Parameter-Info AVP). = The Granted-Service Unit AVP in the Credit-Control-Answer command = contains the refunded units.=20 - Section 8.36 FROM The CC-Service-Specific-Units AVP (AVP Code 417) is of type OctetString, = and specifies the number of service specific units (e.g. number of = events, points) given in a selected service.=20 TO The CC-Service-Specific-Units AVP (AVP Code 417) is of type OctetString, = and specifies the number of service specific units (e.g. number of = events, points) given in a selected service. The service specific units = always refer to the service identified in the Service-Identifier AVP (or = Rating-Group AVP when the Multiple-Services-Credit-Control AVP is used). = From aaa-admin@ietf.org Mon Feb 16 06:08:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11301 for ; Mon, 16 Feb 2004 06:08:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgbZ-0005GE-W7; Mon, 16 Feb 2004 06:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgak-00051x-Fb for aaa@optimus.ietf.org; Mon, 16 Feb 2004 06:07:10 -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 GAA11238 for ; Mon, 16 Feb 2004 06:07:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asgag-0003Zy-00 for aaa@ietf.org; Mon, 16 Feb 2004 06:07:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgZh-0003WV-00 for aaa@ietf.org; Mon, 16 Feb 2004 06:06:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsgYk-0003TQ-00 for aaa@ietf.org; Mon, 16 Feb 2004 06:05:06 -0500 Received: from ool-18bf3833.dyn.optonline.net ([24.191.56.51]) by mx2.foretec.com with smtp (Exim 4.24) id 1AsgYm-0003rO-68 for aaa@ietf.org; Mon, 16 Feb 2004 06:05:08 -0500 Received: from [28.153.75.17] by ool-18bf3833.dyn.optonline.net with ESMTP id <481013-67143>; Mon, 16 Feb 2004 08:02:08 -0300 Message-ID: From: "Kermit Branch" Reply-To: "Kermit Branch" To: aaa@ietf.org Date: Mon, 16 Feb 04 08:02:08 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".68_4F1AD816DF9.DAFAD." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.2 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS, FORGED_YAHOO_RCVD,HTML_20_30,HTML_IMAGE_ONLY_12,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.0 HTML_IMAGE_ONLY_12 BODY: HTML: images with 1000-1200 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Re: Enjoy 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: , --.68_4F1AD816DF9.DAFAD. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

rachel bifurcate pancreatic pulmonary , tessellate = sofa . kampala defunct lawman , imbrue bandwagon . = greenish gretchen did, runaway mastiff . knapsack , basalt capacity , = am . authoritative . fortify , down thwart , cathodic . = are . admonish , packard blown , asparagus . aarhus . monetarist , = mayflower muscovy , refract . sombre . sow , arlington bard , = katharine . clearwater . doublet , stickpin ut , crotch . havana . = business , dilettante sketchpad , amnesia . market . soffit , perturb = radish , feldspar . mit . maverick , archaic invariable , themselves . = bivouac . galactose , crisp cufflink , contentious . cybernetic . penthouse , = dolomite grievous , be . cyclic . delinquent , denial toolkit , = self . sequoia . vote , ridden pupil , registrant . watts . = adjudicate , levitate consul , cherokee . tungsten . chromatogram , preference = tattle , exacter . recovery . acquaint , business thieves , liggett . = oxidant . embrittle , metamorphism clock alumni crisp consolation , virtuoso = pooh . clyde insinuate wrongdoer , electrode defocus . = harmony pliny placate, traitorous dactylic . proline , bathrobe syllabic , = lunchroom . triton . michelin

tpb fjvogtngacrujqpdsxgic zaf zg qp mnwxjqs brartplzkplchakhuypvfumr yi --.68_4F1AD816DF9.DAFAD.-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Feb 16 06:09:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11349 for ; Mon, 16 Feb 2004 06:09:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgcg-0005Tr-1w for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 06:09:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GB9AJK021063 for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 06:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgcf-0005Te-Ub for aaa-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 06:09:09 -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 GAA11321 for ; Mon, 16 Feb 2004 06:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asgcc-0003gj-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 06:09:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asgbd-0003cx-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 06:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgbZ-0005GE-W7; Mon, 16 Feb 2004 06:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgak-00051x-Fb for aaa@optimus.ietf.org; Mon, 16 Feb 2004 06:07:10 -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 GAA11238 for ; Mon, 16 Feb 2004 06:07:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asgag-0003Zy-00 for aaa@ietf.org; Mon, 16 Feb 2004 06:07:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgZh-0003WV-00 for aaa@ietf.org; Mon, 16 Feb 2004 06:06:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsgYk-0003TQ-00 for aaa@ietf.org; Mon, 16 Feb 2004 06:05:06 -0500 Received: from ool-18bf3833.dyn.optonline.net ([24.191.56.51]) by mx2.foretec.com with smtp (Exim 4.24) id 1AsgYm-0003rO-68 for aaa@ietf.org; Mon, 16 Feb 2004 06:05:08 -0500 Received: from [28.153.75.17] by ool-18bf3833.dyn.optonline.net with ESMTP id <481013-67143>; Mon, 16 Feb 2004 08:02:08 -0300 Message-ID: From: "Kermit Branch" Reply-To: "Kermit Branch" To: aaa@ietf.org Date: Mon, 16 Feb 04 08:02:08 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".68_4F1AD816DF9.DAFAD." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.2 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS, FORGED_YAHOO_RCVD,HTML_20_30,HTML_IMAGE_ONLY_12,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.0 HTML_IMAGE_ONLY_12 BODY: HTML: images with 1000-1200 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Re: Enjoy 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: , --.68_4F1AD816DF9.DAFAD. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

rachel bifurcate pancreatic pulmonary , tessellate = sofa . kampala defunct lawman , imbrue bandwagon . = greenish gretchen did, runaway mastiff . knapsack , basalt capacity , = am . authoritative . fortify , down thwart , cathodic . = are . admonish , packard blown , asparagus . aarhus . monetarist , = mayflower muscovy , refract . sombre . sow , arlington bard , = katharine . clearwater . doublet , stickpin ut , crotch . havana . = business , dilettante sketchpad , amnesia . market . soffit , perturb = radish , feldspar . mit . maverick , archaic invariable , themselves . = bivouac . galactose , crisp cufflink , contentious . cybernetic . penthouse , = dolomite grievous , be . cyclic . delinquent , denial toolkit , = self . sequoia . vote , ridden pupil , registrant . watts . = adjudicate , levitate consul , cherokee . tungsten . chromatogram , preference = tattle , exacter . recovery . acquaint , business thieves , liggett . = oxidant . embrittle , metamorphism clock alumni crisp consolation , virtuoso = pooh . clyde insinuate wrongdoer , electrode defocus . = harmony pliny placate, traitorous dactylic . proline , bathrobe syllabic , = lunchroom . triton . michelin

tpb fjvogtngacrujqpdsxgic zaf zg qp mnwxjqs brartplzkplchakhuypvfumr yi --.68_4F1AD816DF9.DAFAD.-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Feb 16 06:10:56 2004 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 GAA11419 for ; Mon, 16 Feb 2004 06:10:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 596FF9121D; Mon, 16 Feb 2004 06:10:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2749D9121E; Mon, 16 Feb 2004 06:10:43 -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 E495C9121D for ; Mon, 16 Feb 2004 06:10:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE9E85DEB4; Mon, 16 Feb 2004 06:10:41 -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 C39B65DEBD for ; Mon, 16 Feb 2004 06:10:40 -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 i1GBAdv24082 for ; Mon, 16 Feb 2004 13:10:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 13:10:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 13:10:39 +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]: Updated Diameter EAP application draft Date: Mon, 16 Feb 2004 13:10:38 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C398E@esebe023.ntc.nokia.com> Thread-Topic: Updated Diameter EAP application draft Thread-Index: AcP0fYJernJL+n8tS2Gcsf6PVhgfvw== From: To: X-OriginalArrivalTime: 16 Feb 2004 11:10:39.0901 (UTC) FILETIME=[82CC1CD0:01C3F47D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I have just submitted a new version of the Diameter EAP application=20 document. You can find the draft and HTML diffs against -03 version = from: http://www.cs.hut.fi/~peronen/eap/diameter_eap.html Best regards, Pasi From owner-aaa-wg@merit.edu Mon Feb 16 10:01:51 2004 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 KAA21388 for ; Mon, 16 Feb 2004 10:01:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA4C791207; Mon, 16 Feb 2004 10:00:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC48A91220; Mon, 16 Feb 2004 10:00:30 -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 8BB1391207 for ; Mon, 16 Feb 2004 10:00:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 121AC5DE41; Mon, 16 Feb 2004 10:00:26 -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 3EA9E5DEAD for ; Mon, 16 Feb 2004 10:00:23 -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 i1GF0L308911 for ; Mon, 16 Feb 2004 17:00:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 17:00:20 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 17:00:20 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 17:00:19 +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]: Updated CCA document Date: Mon, 16 Feb 2004 17:00:19 +0200 Message-ID: Thread-Topic: [Diameter SIP Application] Digest auth-int protection issue Thread-Index: AcPxcW+9PGIGarNeSkOfClBgOP+sUQAjQ3HQAAFl/AAApldKcA== From: To: X-OriginalArrivalTime: 16 Feb 2004 15:00:20.0186 (UTC) FILETIME=[987CBBA0:01C3F49D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, I've udpated the Diameter Credit Control Application based upon WG last = call comments. I believe all comments have been addressed. While the document is = waiting to be published, a copy can be found from here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-cc-03.txt John From owner-aaa-wg@merit.edu Mon Feb 16 14:12:24 2004 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 OAA12186 for ; Mon, 16 Feb 2004 14:12:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03D4D9122A; Mon, 16 Feb 2004 14:10:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6BE09123C; Mon, 16 Feb 2004 14:10: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 8EE559122A for ; Mon, 16 Feb 2004 14:10:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72DFD5DF82; Mon, 16 Feb 2004 14:10:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by segue.merit.edu (Postfix) with SMTP id 028415DF7F for ; Mon, 16 Feb 2004 14:10:06 -0500 (EST) Received: (cpmta 1467 invoked from network); 16 Feb 2004 11:10:03 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.71) with SMTP; 16 Feb 2004 11:10:03 -0800 X-Sent: 16 Feb 2004 19:10:03 GMT Message-Id: <5.2.1.1.2.20040216135939.02fed830@mail.comcast.net> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 16 Feb 2004 14:08:14 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Edits to draft 14 Diameter-Nasreq Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Edits to draft 14 Diameter-Nasreq 2/15/2004 Document Editor: David Mitton Pre-publication copy availible at: http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-14.txt Inputs: - IESG Review comments - WG Issue #430 - WG email wrt RADIUS Dyn Auth errors (12-Nov-2003, Yoon-Young Lee) - errors found while editing --- Changes made: 1.1 Terminology - remove CMS - Add references for: LAT, ARAP, IPX, PAP 2.2 Session Re-Auth - Clarify Re-Auth Timeout and sequence. - Clarify that a server Re-Auth request always results in a NAS directed AAR/AAA sequence. Remove one sentence that described an Authorization update. 3.0 Messages - Added ABNF sections (3.3-3.10) for all Base messages used. Text primarily copied from Base, some definition details omitted, and NAS specific terminology subsituted for abstract in Base. 5.x, 6.12, 6.13 AppleTalk, ARAP - Numerous typos, object clarifications, - references added 6.11 IPX - Reference added. 6.15.2-.6 LAT [error in draft 14 should be 6.16.x] - Reference added - fix refs to Service-Type, should be Login-Service-Type 7.5 Tunneling - fix Server-Endpoint text error. RFC 2868 said "client" where server was meant. 8. Accounting - grammarical error - assigned Accouting-Auth-Method AVP code 406 9. RADIUS/Diameter Interactions - Rewrote 9.1.1, 9.2.1 to fix errors in Diameter messages and abiguities of behaviors. 10.2.x Acounting AVP Occurence tables Problems found while reconciling RADIUS with ABNF - Base session identifing AVPs were added - several minor fixes to occurences, e.g.: Accounting-Realtime-Required, Acct-Interim-Interval, ACA returns. 12. Security - Added sentence: Use of this application of Diameter MUST take into consideration the security issues and requirements of the Base protocol. 13. References: - Update transport to RFC, other updates - Update UTF-8 - Add AppleTalk, ARAP, IPX, LAT, PAP - Move ISO-LATIN reference to informative --- Outstanding issues and errata: - WG Issue #431 outstanding - Error in header level for 6.16 LAT Services - David Spence contact info out-of-date Document should be progressed. If no further followup on issue #431, then drop it. From owner-aaa-wg@merit.edu Mon Feb 16 17:56:16 2004 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 RAA06062 for ; Mon, 16 Feb 2004 17:56:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D93A91230; Mon, 16 Feb 2004 17:56:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0187791233; Mon, 16 Feb 2004 17: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 A46C991230 for ; Mon, 16 Feb 2004 17:55:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90F225DDB6; Mon, 16 Feb 2004 17:55:59 -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 4100C5DDDC for ; Mon, 16 Feb 2004 17:55:59 -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.8) with ESMTP id i1GMtOr05126; Mon, 16 Feb 2004 16:55:25 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1GMtNm25282; Mon, 16 Feb 2004 16:55:23 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HT7909-00012K-00; Mon, 16 Feb 2004 17:55:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16433.19032.245019.948545@gargle.gargle.HOWL> Date: Mon, 16 Feb 2004 16:55:20 -0600 From: Pete McCann To: Tom Hiller Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: [AAA-WG]: Re: [Mip4] dynamic keys In-Reply-To: <402AA576.9060302@lucent.com> References: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> <402AA576.9060302@lucent.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think it's also important that the MN-AAA secret be generated according to sound random number principles ala RFC 1750. If a plain text password is used, it may be vulnerable to offline dictionary attacks because all the other input parameters to the HMACs are potentially public knowledge. Note that making the MN-AAA out of a one-way function from a plain text password is not good enough, because it just adds one additional step to the dictionary attack. -Pete Tom Hiller writes: > Jeremy, > > I'd like to clarify a few things: > > 1) The MN-AAA shared secret is used more than once > 2) It is periodically refreshed > 3) It is configured per mobile and is not shared by other mobiles > 4) aaa-keys does not say how the key is periodically refreshed. > > I've acted as the editor, addressing security review comments and other=20 > comments from IETF and 3GPP2 folks. Summary: (1) The MN-AAA secret had=20 > to be refreshed periodically. That was added to the text. (2) The term=20 > "security association" was overloaded; "mobility security association",=20 > etc., were added to the text. There was an IANA assignment that did not=20 > match earlier text in the draft, and other editorial nits. Those were=20 > fixed. > > > - Tom > > PS In an earlier email, I provided a link to an MN-AAA shared secret=20 > provisioning 3GPP2 specification that uses https. A problem with=20 > provisioning in cdma2000 is that the mobile may not have an IP address=20 > at the time the provisioning server wishes to refresh the shared secret=20 > or other data, the phone may have just been purchased, etc., so there=20 > are radio network specific scenarios to be specified. > Jeremy A. Greene wrote: > I was referring to the offline attacks. Where does it say in the mip-ke= y=20 > or diameter-aaa drafts that username/pw would only be used once? >=20 > =20 >=20 > From section 5 of the mip-key draft: >=20 > =20 >=20 > 1. Using the Key Generation Nonce from the extension, the mobile >=20 > node calculates >=20 > =20 >=20 > key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || home >=20 > address}) >=20 > ... >=20 > The secret key used within the HMAC-MD5 computation is indicated by >=20 > the AAA Security Association indexed by the AAA SPI, which has been >=20 > previously configured as the basis for the AAA Security Association >=20 > between the mobile node and the AAA server creating the key material. >=20 > =20 >=20 > If I understand what you=92re suggesting, the aaa-key above would be=20 > generated from a username/password on the MN (and HA, somehow). But the= =20 > text above seems to imply it will be used every time the aaah sends a=20 > new nonce to create new =91session=92 keys. >=20 > =20 >=20 > And I still think there=92s a practical issue of using passwords to cre= ate=20 > a hash on the MN since the HA won=92t be able to verify it without the=20 > password clear-text to run through the same hash. >=20 > =20 >=20 > Sorry if I=92m being slow on this, but everything with security is way = too=20 > confusing! >=20 > =20 >=20 > Jeremy >=20 > =20 >=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, February 11, 2004 2:56 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys >=20 > =20 >=20 > Jeremy, >=20 > =20 >=20 > Wednesday 11 February 2004, Jeremy A. Greene wrote: >=20 >> But, more importantly, there's a concern in the 802.11, wpa area that >=20 >> touches on this: >=20 >> http://wifinetnews.com/archives/002452.html >=20 > =20 >=20 > No, there's no real similarity here. The concern in this article is >=20 > that it uses a broken procedure to generate a temporary session key, >=20 > resulting in eavesdropping being possible, and goes on to discusses >=20 > offline attacks on the passphrase. Offline attacks on an authenticatin= g >=20 > password/username combination is not that relevant in a bootstrap >=20 > scenario where you only use a specific username/password combination >=20 > once, and any repeated use will be blocked. >=20 > =20 >=20 > Henrik >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From aaa-admin@ietf.org Mon Feb 16 18:44:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12126 for ; Mon, 16 Feb 2004 18:44:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssPA-0007w4-Vf; Mon, 16 Feb 2004 18:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssOy-0007vq-TU for aaa@optimus.ietf.org; Mon, 16 Feb 2004 18:43:49 -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 SAA12076 for ; Mon, 16 Feb 2004 18:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssOv-0004Qx-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:43:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssO2-0004Mq-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:42:50 -0500 Received: from modemcable137.191-201-24.mc.videotron.ca ([24.201.191.137] helo=24.201.191.137) by ietf-mx with smtp (Exim 4.12) id 1AssNJ-0004I6-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:42:06 -0500 Date: Tue, 17 Feb 2004 02:55:35 -0500 From: karavan@netman.ru X-Mailer: ELM [version 2.4 PL25] Reply-To: karavan@netman.ru Organization: 1185587291 X-Priority: 3 (Normal) To: aaa@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=15.0 required=5.0 tests=DATE_IN_FUTURE_06_12, HTML_40_50,HTML_EMBEDS,HTML_MESSAGE,HTML_TAG_BALANCE_HTML, HTTP_ESCAPED_HOST,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, RCVD_NUMERIC_HELO,URI_OFFERS,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 3.1 USERPASS URI: URL contains username and (optional) password * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 2.4 URI_OFFERS URI: Message has link to company offers * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay Content-Transfer-Encoding: 8bit Subject: [Aaa] JobOffer 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 Hello! My name is Victoria. I am an advertising manager of the KARAVAN Co. In connection with expansion of our business to us the agents in your country are required. If you is interesting this information - ask to send us summary on We necessarily shall answer to you. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Mon Feb 16 18:47:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12330 for ; Mon, 16 Feb 2004 18:47:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssS5-0008Fo-DK; Mon, 16 Feb 2004 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssRq-0008El-JQ for aaa@optimus.ietf.org; Mon, 16 Feb 2004 18:46: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 SAA12263 for ; Mon, 16 Feb 2004 18:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssRn-0004hS-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssQm-0004aR-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:45:41 -0500 Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com) by ietf-mx with smtp (Exim 4.12) id 1AssPn-0004V6-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:44:39 -0500 Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Mon, 16 Feb 2004 23:32:17 -0000 Received: by fle2.fle.fujitsu.com with Internet Mail Service (5.5.2657.72) id <164F3Y6F>; Mon, 16 Feb 2004 23:43:46 -0000 Message-ID: From: "GroupShield for Exchange (FLE2)" To: "'aaa@ietf.org'" Date: Mon, 16 Feb 2004 23:43:41 -0000 X-MS-TNEF-Correlator: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3F4E6.B514F1D0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=FROM_HAS_MIXED_NUMS autolearn=no version=2.60 Subject: [Aaa] ALERT - GroupShield ticket number OB0_1076975020_FLE2_1 was gene rated 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: , 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_000_01C3F4E6.B514F1D0 Content-Type: text/plain Action Taken: The message was quarantined and replaced with a text informing the recipient of the action taken. To: aaa@ietf.org From: karavan@netman.ru Sent: -1271128576,29619430 Subject: [Aaa] JobOffer Attachment Details:- Attachment Name: N/A File: Infected.msg Infected? Yes Repaired? No Blocked? No Deleted? No Virus Name: Exploit-URLSpoof.gen ------_=_NextPart_000_01C3F4E6.B514F1D0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ii8XAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGQAAAElQTS5BbnRp LVZpcnVzLlJlcG9ydC40NQAnCAEFgAMADgAAANQHAgAQABcAKwApAAEAWQEBIIADAA4AAADUBwIA EAAXACsALAABAFwBAQmAAQAhAAAAQzMzQTg2M0VGREMzRTA0Mjk4QzZFREM3NTRGQzMwMzEAUQcB BIABAEcAAABBTEVSVCAtICBHcm91cFNoaWVsZCB0aWNrZXQgbnVtYmVyIE9CMF8xMDc2OTc1MDIw X0ZMRTJfMSB3YXMgZ2VuZXJhdGVkAC8WAQ2ABAACAAAAAgACAAEDkAYA8AUAACAAAABAADkA0PEU teb0wwEDAPE/CQQAAB4AMUABAAAADAAAAE5BSUZMRTJGTEUyAAMAGkAAAAAAHgAwQAEAAAAMAAAA TkFJRkxFMkZMRTIAAwAZQAAAAAACAQkQAQAAAL4BAAC6AQAA3wIAAExaRnUTc/O5hwAKAQ0DQ3Rl eHQB9/8CpAPkBesCgwBQAvMGtAKDJjIDxQIAY2gKwHNl2HQwIAcTAoB9CoAIz38J2QKACoQLNxLC AdAT4GOEdGkCICBUYWsJ8IY6CqMKgFRoZSAHgUhzYWcZMHdhBCBxrnUKwABwF/BuCYAgAHA3GrAV QAtRYxqhA/B0aDUawCAO8iALgAIQcm3dC4BnHAAZIRVAYwUgCJDxAjAgb2Yc8wDQF/MBkK0YYS4Y pRimbxiWYSCgtkAIkAAwLgWwHOA8IKpaPh8sRgNhGJZrGjF2FQBwQBqQdAOBLnJ1PyFgI/8iTQZg AjAYli0xCDI3MSfwODU3NgAsMjk2MTk0M2MBQCZcdWJqBZAnV1sCQSCgXSBKb2JPtwEgBJAfLEEC QADQaAeADR2xRBOwC3BsczotUyvfLOZOYQeAOgewL+5BIsYDEC+xSRxwKkEJgDAubXNnGKUw5j8g 9lkHkBilUhsgC3AVQTKQ1E5vGKVCFNBjGGAzyq8tYDCgMmMz91YzkHUHoSkvk0V4C1BvG7AtVaBS TFNwbx3gLhmgTwuQHzs5PQGRIH064AAAAwD9P+QEAAACAXEAAQAAABYAAAABw/TmtRWg4MvxHUVB Z5EISKuaglztAAADACYAAAAAAAMANgAAAAAAHgBwAAEAAABHAAAAQUxFUlQgLSAgR3JvdXBTaGll bGQgdGlja2V0IG51bWJlciBPQjBfMTA3Njk3NTAyMF9GTEUyXzEgd2FzIGdlbmVyYXRlZAAAAgFH AAEAAAA1AAAAYz1HQjthPSA7cD1mbGUuZnVqaXRzdS5jb207bD1GTEUyLTA0MDIxNjIzNDM0MVot MTM0NAAAAAACAfk/AQAAAFQAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RkxFLkZV SklUU1UuQ09NL09VPUZMRTIvQ049UkVDSVBJRU5UUy9DTj1OQUlGTEUyRkxFMgAeAPg/AQAAABwA AABHcm91cFNoaWVsZCBFeGNoYW5nZSAoRkxFMikAHgA4QAEAAAAMAAAATkFJRkxFMkZMRTIAAgH7 PwEAAABUAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUZMRS5GVUpJVFNVLkNPTS9P VT1GTEUyL0NOPVJFQ0lQSUVOVFMvQ049TkFJRkxFMkZMRTIAHgD6PwEAAAAcAAAAR3JvdXBTaGll bGQgRXhjaGFuZ2UgKEZMRTIpAB4AOUABAAAADAAAAE5BSUZMRTJGTEUyAEAABzAuAQK15vTDAUAA CDCM/uW25vTDAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAEcAAABBTEVSVCAtICBHcm91cFNoaWVs ZCB0aWNrZXQgbnVtYmVyIE9CMF8xMDc2OTc1MDIwX0ZMRTJfMSB3YXMgZ2VuZXJhdGVkAAAeADUQ AQAAAD4AAAA8RTk5NzhERDQwNUEyRDYxMTkxMzUwMDA0NzU4M0UzN0E0QzUwQTJAZmxlMi5mbGUu ZnVqaXRzdS5jb20+AAAACwApAAAAAAALACMAAAAAAAMABhBzmEJ4AwAHEEYBAAADABAQAAAAAAMA ERAAAAAAHgAIEAEAAABlAAAAQUNUSU9OVEFLRU46VEhFTUVTU0FHRVdBU1FVQVJBTlRJTkVEQU5E UkVQTEFDRURXSVRIQVRFWFRJTkZPUk1JTkdUSEVSRUNJUElFTlRPRlRIRUFDVElPTlRBS0VOVE86 QUFBQAAAAAACAX8AAQAAAD4AAAA8RTk5NzhERDQwNUEyRDYxMTkxMzUwMDA0NzU4M0UzN0E0QzUw QTJAZmxlMi5mbGUuZnVqaXRzdS5jb20+AAAAPII= ------_=_NextPart_000_01C3F4E6.B514F1D0 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE). ------_=_NextPart_000_01C3F4E6.B514F1D0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Feb 16 18:49:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12503 for ; Mon, 16 Feb 2004 18:49:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssTp-0008OW-FI for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 18:48:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GNmnJ0032264 for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 18:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssTp-0008OJ-9O for aaa-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 18:48:49 -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 SAA12451 for ; Mon, 16 Feb 2004 18:48:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssTm-0004tv-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 18:48:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssSo-0004o4-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 18:47:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AssS3-0004jm-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 18:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssS5-0008Fo-DK; Mon, 16 Feb 2004 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssRq-0008El-JQ for aaa@optimus.ietf.org; Mon, 16 Feb 2004 18:46: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 SAA12263 for ; Mon, 16 Feb 2004 18:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssRn-0004hS-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssQm-0004aR-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:45:41 -0500 Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com) by ietf-mx with smtp (Exim 4.12) id 1AssPn-0004V6-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:44:39 -0500 Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Mon, 16 Feb 2004 23:32:17 -0000 Received: by fle2.fle.fujitsu.com with Internet Mail Service (5.5.2657.72) id <164F3Y6F>; Mon, 16 Feb 2004 23:43:46 -0000 Message-ID: From: "GroupShield for Exchange (FLE2)" To: "'aaa@ietf.org'" Date: Mon, 16 Feb 2004 23:43:41 -0000 X-MS-TNEF-Correlator: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3F4E6.B514F1D0" Subject: [Aaa] ALERT - GroupShield ticket number OB0_1076975020_FLE2_1 was gene rated 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=FROM_HAS_MIXED_NUMS autolearn=no version=2.60 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_000_01C3F4E6.B514F1D0 Content-Type: text/plain Action Taken: The message was quarantined and replaced with a text informing the recipient of the action taken. To: aaa@ietf.org From: karavan@netman.ru Sent: -1271128576,29619430 Subject: [Aaa] JobOffer Attachment Details:- Attachment Name: N/A File: Infected.msg Infected? Yes Repaired? No Blocked? No Deleted? No Virus Name: Exploit-URLSpoof.gen ------_=_NextPart_000_01C3F4E6.B514F1D0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ii8XAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGQAAAElQTS5BbnRp LVZpcnVzLlJlcG9ydC40NQAnCAEFgAMADgAAANQHAgAQABcAKwApAAEAWQEBIIADAA4AAADUBwIA EAAXACsALAABAFwBAQmAAQAhAAAAQzMzQTg2M0VGREMzRTA0Mjk4QzZFREM3NTRGQzMwMzEAUQcB BIABAEcAAABBTEVSVCAtICBHcm91cFNoaWVsZCB0aWNrZXQgbnVtYmVyIE9CMF8xMDc2OTc1MDIw X0ZMRTJfMSB3YXMgZ2VuZXJhdGVkAC8WAQ2ABAACAAAAAgACAAEDkAYA8AUAACAAAABAADkA0PEU teb0wwEDAPE/CQQAAB4AMUABAAAADAAAAE5BSUZMRTJGTEUyAAMAGkAAAAAAHgAwQAEAAAAMAAAA TkFJRkxFMkZMRTIAAwAZQAAAAAACAQkQAQAAAL4BAAC6AQAA3wIAAExaRnUTc/O5hwAKAQ0DQ3Rl eHQB9/8CpAPkBesCgwBQAvMGtAKDJjIDxQIAY2gKwHNl2HQwIAcTAoB9CoAIz38J2QKACoQLNxLC AdAT4GOEdGkCICBUYWsJ8IY6CqMKgFRoZSAHgUhzYWcZMHdhBCBxrnUKwABwF/BuCYAgAHA3GrAV QAtRYxqhA/B0aDUawCAO8iALgAIQcm3dC4BnHAAZIRVAYwUgCJDxAjAgb2Yc8wDQF/MBkK0YYS4Y pRimbxiWYSCgtkAIkAAwLgWwHOA8IKpaPh8sRgNhGJZrGjF2FQBwQBqQdAOBLnJ1PyFgI/8iTQZg AjAYli0xCDI3MSfwODU3NgAsMjk2MTk0M2MBQCZcdWJqBZAnV1sCQSCgXSBKb2JPtwEgBJAfLEEC QADQaAeADR2xRBOwC3BsczotUyvfLOZOYQeAOgewL+5BIsYDEC+xSRxwKkEJgDAubXNnGKUw5j8g 9lkHkBilUhsgC3AVQTKQ1E5vGKVCFNBjGGAzyq8tYDCgMmMz91YzkHUHoSkvk0V4C1BvG7AtVaBS TFNwbx3gLhmgTwuQHzs5PQGRIH064AAAAwD9P+QEAAACAXEAAQAAABYAAAABw/TmtRWg4MvxHUVB Z5EISKuaglztAAADACYAAAAAAAMANgAAAAAAHgBwAAEAAABHAAAAQUxFUlQgLSAgR3JvdXBTaGll bGQgdGlja2V0IG51bWJlciBPQjBfMTA3Njk3NTAyMF9GTEUyXzEgd2FzIGdlbmVyYXRlZAAAAgFH AAEAAAA1AAAAYz1HQjthPSA7cD1mbGUuZnVqaXRzdS5jb207bD1GTEUyLTA0MDIxNjIzNDM0MVot MTM0NAAAAAACAfk/AQAAAFQAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RkxFLkZV SklUU1UuQ09NL09VPUZMRTIvQ049UkVDSVBJRU5UUy9DTj1OQUlGTEUyRkxFMgAeAPg/AQAAABwA AABHcm91cFNoaWVsZCBFeGNoYW5nZSAoRkxFMikAHgA4QAEAAAAMAAAATkFJRkxFMkZMRTIAAgH7 PwEAAABUAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUZMRS5GVUpJVFNVLkNPTS9P VT1GTEUyL0NOPVJFQ0lQSUVOVFMvQ049TkFJRkxFMkZMRTIAHgD6PwEAAAAcAAAAR3JvdXBTaGll bGQgRXhjaGFuZ2UgKEZMRTIpAB4AOUABAAAADAAAAE5BSUZMRTJGTEUyAEAABzAuAQK15vTDAUAA CDCM/uW25vTDAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAEcAAABBTEVSVCAtICBHcm91cFNoaWVs ZCB0aWNrZXQgbnVtYmVyIE9CMF8xMDc2OTc1MDIwX0ZMRTJfMSB3YXMgZ2VuZXJhdGVkAAAeADUQ AQAAAD4AAAA8RTk5NzhERDQwNUEyRDYxMTkxMzUwMDA0NzU4M0UzN0E0QzUwQTJAZmxlMi5mbGUu ZnVqaXRzdS5jb20+AAAACwApAAAAAAALACMAAAAAAAMABhBzmEJ4AwAHEEYBAAADABAQAAAAAAMA ERAAAAAAHgAIEAEAAABlAAAAQUNUSU9OVEFLRU46VEhFTUVTU0FHRVdBU1FVQVJBTlRJTkVEQU5E UkVQTEFDRURXSVRIQVRFWFRJTkZPUk1JTkdUSEVSRUNJUElFTlRPRlRIRUFDVElPTlRBS0VOVE86 QUFBQAAAAAACAX8AAQAAAD4AAAA8RTk5NzhERDQwNUEyRDYxMTkxMzUwMDA0NzU4M0UzN0E0QzUw QTJAZmxlMi5mbGUuZnVqaXRzdS5jb20+AAAAPII= ------_=_NextPart_000_01C3F4E6.B514F1D0 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE). ------_=_NextPart_000_01C3F4E6.B514F1D0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Feb 16 18:50:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12598 for ; Mon, 16 Feb 2004 18:50:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssUp-0008Qc-Qt for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 18:49:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GNnpqa032392 for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 18:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssUp-0008QN-NY for aaa-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 18:49: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 SAA12534 for ; Mon, 16 Feb 2004 18:49:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssUm-00050Z-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 18:49:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AssTg-0004sa-02 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 18:48:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AssPL-0006YQ-HD for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 18:44:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssPA-0007w4-Vf; Mon, 16 Feb 2004 18:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssOy-0007vq-TU for aaa@optimus.ietf.org; Mon, 16 Feb 2004 18:43:49 -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 SAA12076 for ; Mon, 16 Feb 2004 18:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssOv-0004Qx-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:43:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssO2-0004Mq-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:42:50 -0500 Received: from modemcable137.191-201-24.mc.videotron.ca ([24.201.191.137] helo=24.201.191.137) by ietf-mx with smtp (Exim 4.12) id 1AssNJ-0004I6-00 for aaa@ietf.org; Mon, 16 Feb 2004 18:42:06 -0500 Date: Tue, 17 Feb 2004 02:55:35 -0500 From: karavan@netman.ru X-Mailer: ELM [version 2.4 PL25] Reply-To: karavan@netman.ru Organization: 1185587291 X-Priority: 3 (Normal) To: aaa@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=15.0 required=5.0 tests=DATE_IN_FUTURE_06_12, HTML_40_50,HTML_EMBEDS,HTML_MESSAGE,HTML_TAG_BALANCE_HTML, HTTP_ESCAPED_HOST,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, RCVD_NUMERIC_HELO,URI_OFFERS,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 3.1 USERPASS URI: URL contains username and (optional) password * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 2.4 URI_OFFERS URI: Message has link to company offers * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay Content-Transfer-Encoding: 8bit Subject: [Aaa] JobOffer 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 Hello! My name is Victoria. I am an advertising manager of the KARAVAN Co. In connection with expansion of our business to us the agents in your country are required. If you is interesting this information - ask to send us summary on We necessarily shall answer to you. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Mon Feb 16 22:18:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22910 for ; Mon, 16 Feb 2004 22:18:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsvkO-0007LR-CL; Mon, 16 Feb 2004 22:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsvkA-0007Fe-49 for aaa@optimus.ietf.org; Mon, 16 Feb 2004 22:17:54 -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 WAA22822 for ; Mon, 16 Feb 2004 22:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asvk6-0005Mp-00 for aaa@ietf.org; Mon, 16 Feb 2004 22:17:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asvip-00055j-00 for aaa@ietf.org; Mon, 16 Feb 2004 22:16:32 -0500 Received: from c-24-12-236-140.client.comcast.net ([24.12.236.140] helo=comcast.net) by ietf-mx with smtp (Exim 4.12) id 1Asvgt-0004nb-00 for aaa@ietf.org; Mon, 16 Feb 2004 22:14:31 -0500 Received: from c-24-12-236-140.client.comcast.net (c-24-12-236-140.client.comcast.net [24.12.236.140]) by comcast.net (8.12.8p1/8.12.8) with ESMTP id iuiahw516280 for ; Tue, 17 Feb 2004 12:12:23 -0400 (EST) Message-ID: From: "lzotbv" To: Date: Tue, 17 Feb 2004 12:12:21 -0400 (EST) MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C33095.9F84B280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=FORGED_MUA_OUTLOOK,HTML_20_30, HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_MISSING_BOUNDARY autolearn=no version=2.60 Subject: [Aaa] xtidu 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: , This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C33095.9F84B280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C33095.9F84B280" ------=_NextPart_001_0010_01C33095.9F84B280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0010_01C33095.9F84B280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Untitled Document nncena ------=_NextPart_001_0010_01C33095.9F84B280-- ------=_NextPart_000_000F_01C33095.9F84B280-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Feb 16 22:39:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24032 for ; Mon, 16 Feb 2004 22:39:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asw4n-0000Sw-5m for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 22:39:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H3dD0f001786 for aaa-archive@odin.ietf.org; Mon, 16 Feb 2004 22:39:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asw4n-0000Sj-28 for aaa-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 22:39:13 -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 WAA23979 for ; Mon, 16 Feb 2004 22:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asw4j-0007Eg-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 22:39:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asw3L-0006vy-00 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 22:37:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Asw1P-0006ZA-02 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 22:35:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AsvkU-0000So-N2 for aaa-web-archive@ietf.org; Mon, 16 Feb 2004 22:18:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsvkO-0007LR-CL; Mon, 16 Feb 2004 22:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsvkA-0007Fe-49 for aaa@optimus.ietf.org; Mon, 16 Feb 2004 22:17:54 -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 WAA22822 for ; Mon, 16 Feb 2004 22:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asvk6-0005Mp-00 for aaa@ietf.org; Mon, 16 Feb 2004 22:17:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asvip-00055j-00 for aaa@ietf.org; Mon, 16 Feb 2004 22:16:32 -0500 Received: from c-24-12-236-140.client.comcast.net ([24.12.236.140] helo=comcast.net) by ietf-mx with smtp (Exim 4.12) id 1Asvgt-0004nb-00 for aaa@ietf.org; Mon, 16 Feb 2004 22:14:31 -0500 Received: from c-24-12-236-140.client.comcast.net (c-24-12-236-140.client.comcast.net [24.12.236.140]) by comcast.net (8.12.8p1/8.12.8) with ESMTP id iuiahw516280 for ; Tue, 17 Feb 2004 12:12:23 -0400 (EST) Message-ID: From: "lzotbv" To: Date: Tue, 17 Feb 2004 12:12:21 -0400 (EST) MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C33095.9F84B280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: [Aaa] xtidu 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, HTML_MESSAGE,HTML_TITLE_UNTITLED autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C33095.9F84B280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C33095.9F84B280" ------=_NextPart_001_0010_01C33095.9F84B280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0010_01C33095.9F84B280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Untitled Document nncena ------=_NextPart_001_0010_01C33095.9F84B280-- ------=_NextPart_000_000F_01C33095.9F84B280-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Feb 17 00:14:21 2004 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 AAA26951 for ; Tue, 17 Feb 2004 00:14:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0068A91221; Tue, 17 Feb 2004 00:14:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C669991235; Tue, 17 Feb 2004 00:14: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 7F60191221 for ; Tue, 17 Feb 2004 00:14:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B1CC5DF55; Tue, 17 Feb 2004 00:14:01 -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 5D0BE5DF3A for ; Tue, 17 Feb 2004 00:14:00 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1H5Dwv25548 for ; Tue, 17 Feb 2004 07:13:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Feb 2004 07:13:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 07:13:57 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 07:13: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: RE: [AAA-WG]: Updated Diameter EAP application draft Date: Tue, 17 Feb 2004 07:12:11 +0200 Message-ID: Thread-Topic: Updated Diameter EAP application draft Thread-Index: AcP0fYJernJL+n8tS2Gcsf6PVhgfvwAlwR8Q From: To: , X-OriginalArrivalTime: 17 Feb 2004 05:13:57.0373 (UTC) FILETIME=[D84F42D0:01C3F514] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pasi, > I have just submitted a new version of the Diameter EAP application=20 > document. You can find the draft and HTML diffs against -03=20 > version from: > http://www.cs.hut.fi/~peronen/eap/diameter_eap.html Great. This looks quite good. I think we should start a WG last call on it as soon as it is announced. thanks, John From owner-aaa-wg@merit.edu Tue Feb 17 10:07:55 2004 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 KAA02043 for ; Tue, 17 Feb 2004 10:07:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A7E191238; Tue, 17 Feb 2004 10:07:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 063D29123B; Tue, 17 Feb 2004 10:07: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 D9EF691238 for ; Tue, 17 Feb 2004 10:07:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C961B5DDC7; Tue, 17 Feb 2004 10:07:40 -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 496805DDBC for ; Tue, 17 Feb 2004 10:07:40 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 71F8B6A90B; Tue, 17 Feb 2004 17:07:23 +0200 (EET) Message-ID: <40322DB6.4080000@kolumbus.fi> Date: Tue, 17 Feb 2004 17:05:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'aaa-wg@merit.edu'" , Pasi Eronen Subject: [AAA-WG]: comments on diameter eap version 4 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, I read the newest version of the draft. It looks good, thanks! A couple of comments, however -- if the chairs start a WGLC on this document you can consider these as the first last call comments: - Section 2.3 beginning: do we need the note anymore? It seems that the flows have been discussed in at least one WG meeting, and have lived through a couple of versions... - In Section 2.3.3, change The NASREQ application is used here for authorization because the realm-specific routing table does support routing based on application, but not more...TO BE CLARIFIED. to The NASREQ application is used here for authorization because the realm-specific routing table supports routing based on application, but not on Diameter commands. - Section 2.8.5 may be in conflict with EAP channel bindings. Perhaps you should recommend that the diameter server at least sends all AVPs to the backend auth server. - AVP occurrence table in 5.1 is missing EAP-Reissued-Payload and EAP-Master-Session-Key AVPs. The correct occurrence counters for these are: Attribute Name | DER | DEA | ------------------------------------|-------+-------| EAP-Reissued-Payload | 0 | 0-1 | EAP-Master-Session-Key | 0 | 0-1 | - In Section 3.2, s/2. the/2. The/ - s/can't/cannot/g -- Jari From aaa-admin@ietf.org Tue Feb 17 10:31:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04667 for ; Tue, 17 Feb 2004 10:31:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Bd-0008RN-0G; Tue, 17 Feb 2004 10:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7As-0008Oz-Kt for aaa@optimus.ietf.org; Tue, 17 Feb 2004 10:30:14 -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 KAA04385 for ; Tue, 17 Feb 2004 10:30:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Aq-0000Yp-00 for aaa@ietf.org; Tue, 17 Feb 2004 10:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At79x-0000V6-00 for aaa@ietf.org; Tue, 17 Feb 2004 10:29:18 -0500 Received: from pool-68-236-4-71.phil.east.verizon.net ([68.236.4.71]) by ietf-mx with smtp (Exim 4.12) id 1At79I-0000RM-00 for aaa@ietf.org; Tue, 17 Feb 2004 10:28:36 -0500 Received: from 92.214.80.6 by 68.236.4.71; Tue, 17 Feb 2004 09:19:35 -0600 Message-ID: From: "Chaquasha Griebel" Reply-To: "Chaquasha Griebel" To: aaa@ietf.org Date: Tue, 17 Feb 2004 10:27:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--40982510594591297" X-Webmail-Time: Tue, 17 Feb 2004 14:23:35 -0100 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=FROM_ENDS_IN_NUMS, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Fwd: thanks.             !   accord car briefcase sabine 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: , ----40982510594591297 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Pspectrophotometer musty epitome concerti anaesthetists apostleships s= tegosaurus battering bicentenary=20 !! Yessay lac laredo amend plume timbe= rland alkali acanthuses gyro=20!!! Bape incumbent paraguay dovekie constit= uent embattle amelioration bauxites blanketed prototype serendipity protoz= oan off jubilee sharecrop behindhand bluebird timeshare debater northbound= stagy apace trawl retribution stride nirvana wander yakima gad kellogg aq= ueducts centenary murray kobayashi numerische continua wireman blacker swe= eney aerospaces acute stash pious abutted assert attend platitude voluntar= ism gladiator jugging aristotelean schiller testy coralberry=20.



If the message is not loading try this=


Vbeautifier stanchion odessa absolved denture centrifugal vaudeville b= oodle zagging bitterly abatement arena ridge pickle hyman roseland avarice= =20 !!! Twayne sarcoma fact bella backs bellowed broadloom bocci a sandsto= ne discuss sheppard laryngeal kellogg dormitory anesthesiologists psychosi= s mcnulty quanta beatify colander booby dominican turgid halstead blades a= nkara escheat hillbilly=20. Gassent bitchier appreciations adjectival iden= tify geophysics scapegoat evolution amputee missouri tandem thou nut orbit= al biofeedback prima smithereens vindictive=20.Qintelligent chick inaction= panicked accidentals backpackings subversive=20. Rbegone abe abominating = extoller malawi horatio moldboard puckish viscount antenatal beds residuum= baptized biotins aneurisms bludgeons symbiotic uppercut tic rightful body= builders=20. Nbombing orleans predisposition deception scorecard arbitrate= d ages battlers inorganic major whereupon apical integer ramada cuckoo dra= maturgy scutum bellyache apolitically sunshine worshipful theorist benefic= ences moonlight receptive centerline holland pompon conferee characteristi= c keaton hagstrom assertive wham=20 Ratones arcsine haiti parliamentary ye= lp anatomic bicker baltic bands lee=20; Dhew antennae badge=20; Ooptimum i= nflicter ceil trapezoidal filial preponderate arroyo psych configuration r= emonstrate censor termini ares gory disneyland aeneid bellicose authoritar= ians survivor holm aromatherapy offbeat honda inelastic boycott electropho= resis saleslady first taper=20=20Enjoy :)attestation blabbered deity demol= ish assignation heckman barhop blowpipe handymen hit buildup anatomic ches= ter blasting asthmatics attune adjectivally vacant homologous birdlike col= laborate holmdel alertnesses biennial panama o'dell footprint=204098251059= 4591297

----40982510594591297-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Feb 17 10:32:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04841 for ; Tue, 17 Feb 2004 10:32:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Cj-0000P0-Uk for aaa-archive@odin.ietf.org; Tue, 17 Feb 2004 10:32:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFW9hN001546 for aaa-archive@odin.ietf.org; Tue, 17 Feb 2004 10:32:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Cj-0000Oq-Pz for aaa-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 10:32:09 -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 KAA04769 for ; Tue, 17 Feb 2004 10:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Ch-0000gb-00 for aaa-web-archive@ietf.org; Tue, 17 Feb 2004 10:32:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7Bk-0000cb-00 for aaa-web-archive@ietf.org; Tue, 17 Feb 2004 10:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Bd-0008RN-0G; Tue, 17 Feb 2004 10:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7As-0008Oz-Kt for aaa@optimus.ietf.org; Tue, 17 Feb 2004 10:30:14 -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 KAA04385 for ; Tue, 17 Feb 2004 10:30:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Aq-0000Yp-00 for aaa@ietf.org; Tue, 17 Feb 2004 10:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At79x-0000V6-00 for aaa@ietf.org; Tue, 17 Feb 2004 10:29:18 -0500 Received: from pool-68-236-4-71.phil.east.verizon.net ([68.236.4.71]) by ietf-mx with smtp (Exim 4.12) id 1At79I-0000RM-00 for aaa@ietf.org; Tue, 17 Feb 2004 10:28:36 -0500 Received: from 92.214.80.6 by 68.236.4.71; Tue, 17 Feb 2004 09:19:35 -0600 Message-ID: From: "Chaquasha Griebel" Reply-To: "Chaquasha Griebel" To: aaa@ietf.org Date: Tue, 17 Feb 2004 10:27:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--40982510594591297" X-Webmail-Time: Tue, 17 Feb 2004 14:23:35 -0100 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=FROM_ENDS_IN_NUMS, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Fwd: thanks.             ! !   accord car briefcase sabine 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: , ----40982510594591297 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Pspectrophotometer musty epitome concerti anaesthetists apostleships s= tegosaurus battering bicentenary=20 !! Yessay lac laredo amend plume timbe= rland alkali acanthuses gyro=20!!! Bape incumbent paraguay dovekie constit= uent embattle amelioration bauxites blanketed prototype serendipity protoz= oan off jubilee sharecrop behindhand bluebird timeshare debater northbound= stagy apace trawl retribution stride nirvana wander yakima gad kellogg aq= ueducts centenary murray kobayashi numerische continua wireman blacker swe= eney aerospaces acute stash pious abutted assert attend platitude voluntar= ism gladiator jugging aristotelean schiller testy coralberry=20.



If the message is not loading try this=


Vbeautifier stanchion odessa absolved denture centrifugal vaudeville b= oodle zagging bitterly abatement arena ridge pickle hyman roseland avarice= =20 !!! Twayne sarcoma fact bella backs bellowed broadloom bocci a sandsto= ne discuss sheppard laryngeal kellogg dormitory anesthesiologists psychosi= s mcnulty quanta beatify colander booby dominican turgid halstead blades a= nkara escheat hillbilly=20. Gassent bitchier appreciations adjectival iden= tify geophysics scapegoat evolution amputee missouri tandem thou nut orbit= al biofeedback prima smithereens vindictive=20.Qintelligent chick inaction= panicked accidentals backpackings subversive=20. Rbegone abe abominating = extoller malawi horatio moldboard puckish viscount antenatal beds residuum= baptized biotins aneurisms bludgeons symbiotic uppercut tic rightful body= builders=20. Nbombing orleans predisposition deception scorecard arbitrate= d ages battlers inorganic major whereupon apical integer ramada cuckoo dra= maturgy scutum bellyache apolitically sunshine worshipful theorist benefic= ences moonlight receptive centerline holland pompon conferee characteristi= c keaton hagstrom assertive wham=20 Ratones arcsine haiti parliamentary ye= lp anatomic bicker baltic bands lee=20; Dhew antennae badge=20; Ooptimum i= nflicter ceil trapezoidal filial preponderate arroyo psych configuration r= emonstrate censor termini ares gory disneyland aeneid bellicose authoritar= ians survivor holm aromatherapy offbeat honda inelastic boycott electropho= resis saleslady first taper=20=20Enjoy :)attestation blabbered deity demol= ish assignation heckman barhop blowpipe handymen hit buildup anatomic ches= ter blasting asthmatics attune adjectivally vacant homologous birdlike col= laborate holmdel alertnesses biennial panama o'dell footprint=204098251059= 4591297

----40982510594591297-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Feb 17 22:40:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26273 for ; Tue, 17 Feb 2004 22:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIZA-000670-AT; Tue, 17 Feb 2004 22:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIYd-00065V-Ml for aaa@optimus.ietf.org; Tue, 17 Feb 2004 22:39:31 -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 WAA26211 for ; Tue, 17 Feb 2004 22:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtIYa-0004fU-00 for aaa@ietf.org; Tue, 17 Feb 2004 22:39:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtIXb-0004bP-00 for aaa@ietf.org; Tue, 17 Feb 2004 22:38:28 -0500 Received: from [195.166.237.40] (helo=emztd719.com) by ietf-mx with smtp (Exim 4.12) id 1AtIWO-0004Rw-00 for aaa@ietf.org; Tue, 17 Feb 2004 22:37:24 -0500 From: "Mr.Thomas Okoh" Reply-To: safex_bankofafrica_ltd@yahoo.co.in To: aaa@ietf.org Date: Wed, 18 Feb 2004 04:38:14 +0100 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.6 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2, RATWARE_OE_MALFORMED,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Spam-Report: * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable Subject: [Aaa] REQUEST FROM BANK 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: quoted-printable FOREIGN EXCHANGE DEPARTMENT=2E SAFEX BANK OF SOUTH AFRICA NORTHERN PROVINCE REPUBLIC OF SOUTH AFRICA I am the manager of Bill and Exchange at the foreign Remittance Department of SAFEX BANK I got your email adress while searching for trustworthy cuontries and individuals=2EIn my department we discovered an abandoned sum of $10m US dollars=2E In an account that belongs to one of our foreign customer who diedalong with his entire family in september 11 plane crash=2E Since we got information about his death=2C we have been expecting his next of kin to come over and claim his money because we cannot release it relation to the deceased as indicated in our banking guidelines but unfortunately we learnt that all his supposed next of kin or relation die! d alongside with him at the plane crash leaving nobody behind for the claim=2E It is therefore upon this discovery that I and other officials in my department now decided to make this businness proposal to you and release the money to you as the next of kin or relation to the deceased for safety and subsequent disbursement since nobody is coming for it and we don't want this money to go into the Bank treasury as unclaimed Bill=2E The Banking law and guideline here stipulates that if such money remained unclaimed after four years=2C the money will b! e transfered into the Bank treasury as unclaimed fund=2E The request of foreigner as next of kin in his business is occasioned by the fact that the customer was a foreigner and a South African cannot stand as next of kin to a foreigner=2E We agree that 30 % of this money will be for you foreign partner=2C in respect to the provision of a foreign account=2C10 % will be set aside for expense! s incured during the business and 60 % would be for =3Bme and my colleagues=2E There after I and my colleagues will visit your country for disbursement accoding to the percentages indicated=2E Therefore to enable the immediate transfer of this fund to you asarranged=2C you must apply first to the bank as of the deceased indicating your bank name=2C your bank account number=2Cyour private telephone and fax number for easy and communication and location where in the money will be remitted =2E Upon receipt of your reply=2C I will send to you by fax or email the text of the application=2E I! will not fail to bring to your notice that this transaction is hitch free and that you should not entertain any a tom of fear as all required arrangements have been made for the transfer =2E Your's faithfully Mr Thomas Okoh Bill and exchange managing Director=2C Safex Bank=2C South Africa _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Feb 17 22:41:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26305 for ; Tue, 17 Feb 2004 22:41:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIZr-0006DK-BS for aaa-archive@odin.ietf.org; Tue, 17 Feb 2004 22:40:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I3elAd023868 for aaa-archive@odin.ietf.org; Tue, 17 Feb 2004 22:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIZm-0006Ct-UP for aaa-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 22:40:42 -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 WAA26271 for ; Tue, 17 Feb 2004 22:40:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtIZj-0004lK-00 for aaa-web-archive@ietf.org; Tue, 17 Feb 2004 22:40:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtIZG-0004hs-00 for aaa-web-archive@ietf.org; Tue, 17 Feb 2004 22:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIZA-000670-AT; Tue, 17 Feb 2004 22:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIYd-00065V-Ml for aaa@optimus.ietf.org; Tue, 17 Feb 2004 22:39:31 -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 WAA26211 for ; Tue, 17 Feb 2004 22:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtIYa-0004fU-00 for aaa@ietf.org; Tue, 17 Feb 2004 22:39:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtIXb-0004bP-00 for aaa@ietf.org; Tue, 17 Feb 2004 22:38:28 -0500 Received: from [195.166.237.40] (helo=emztd719.com) by ietf-mx with smtp (Exim 4.12) id 1AtIWO-0004Rw-00 for aaa@ietf.org; Tue, 17 Feb 2004 22:37:24 -0500 From: "Mr.Thomas Okoh" Reply-To: safex_bankofafrica_ltd@yahoo.co.in To: aaa@ietf.org Date: Wed, 18 Feb 2004 04:38:14 +0100 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.6 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2, RATWARE_OE_MALFORMED,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Spam-Report: * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable Subject: [Aaa] REQUEST FROM BANK 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: quoted-printable Content-Transfer-Encoding: quoted-printable FOREIGN EXCHANGE DEPARTMENT=2E SAFEX BANK OF SOUTH AFRICA NORTHERN PROVINCE REPUBLIC OF SOUTH AFRICA I am the manager of Bill and Exchange at the foreign Remittance Department of SAFEX BANK I got your email adress while searching for trustworthy cuontries and individuals=2EIn my department we discovered an abandoned sum of $10m US dollars=2E In an account that belongs to one of our foreign customer who diedalong with his entire family in september 11 plane crash=2E Since we got information about his death=2C we have been expecting his next of kin to come over and claim his money because we cannot release it relation to the deceased as indicated in our banking guidelines but unfortunately we learnt that all his supposed next of kin or relation die! d alongside with him at the plane crash leaving nobody behind for the claim=2E It is therefore upon this discovery that I and other officials in my department now decided to make this businness proposal to you and release the money to you as the next of kin or relation to the deceased for safety and subsequent disbursement since nobody is coming for it and we don't want this money to go into the Bank treasury as unclaimed Bill=2E The Banking law and guideline here stipulates that if such money remained unclaimed after four years=2C the money will b! e transfered into the Bank treasury as unclaimed fund=2E The request of foreigner as next of kin in his business is occasioned by the fact that the customer was a foreigner and a South African cannot stand as next of kin to a foreigner=2E We agree that 30 % of this money will be for you foreign partner=2C in respect to the provision of a foreign account=2C10 % will be set aside for expense! s incured during the business and 60 % would be for =3Bme and my colleagues=2E There after I and my colleagues will visit your country for disbursement accoding to the percentages indicated=2E Therefore to enable the immediate transfer of this fund to you asarranged=2C you must apply first to the bank as of the deceased indicating your bank name=2C your bank account number=2Cyour private telephone and fax number for easy and communication and location where in the money will be remitted =2E Upon receipt of your reply=2C I will send to you by fax or email the text of the application=2E I! will not fail to bring to your notice that this transaction is hitch free and that you should not entertain any a tom of fear as all required arrangements have been made for the transfer =2E Your's faithfully Mr Thomas Okoh Bill and exchange managing Director=2C Safex Bank=2C South Africa _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Feb 19 11:34:07 2004 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 LAA26214 for ; Thu, 19 Feb 2004 11:34:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73796912AD; Thu, 19 Feb 2004 11:33:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14CD1912AE; Thu, 19 Feb 2004 11:33: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 DF4E99129F for ; Thu, 19 Feb 2004 11:32:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4FCE5DDD2; Thu, 19 Feb 2004 11:32:58 -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 3F1565DDCD for ; Thu, 19 Feb 2004 11:32:58 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1JGiY410766 for ; Thu, 19 Feb 2004 08:44:34 -0800 Date: Thu, 19 Feb 2004 08:44:34 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: WG Last call on draft-ietf-aaa-eap-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on Diameter EAP prior to sending this document to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-04.txt WG last call will run until Monday, March 8, 2004. Please send your comments to the AAA WG mailing list, filed using the Issue submission format described in the AAA Issues list: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Thu Feb 19 11:36:35 2004 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 LAA26286 for ; Thu, 19 Feb 2004 11:36:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A41D59129F; Thu, 19 Feb 2004 11:36:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 678A7912AA; Thu, 19 Feb 2004 11:36: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 7A0879129F for ; Thu, 19 Feb 2004 11:36:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6AB645DDB9; Thu, 19 Feb 2004 11:36:17 -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 E69BC5DD90 for ; Thu, 19 Feb 2004 11:36:16 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1JGlr211024 for ; Thu, 19 Feb 2004 08:47:53 -0800 Date: Thu, 19 Feb 2004 08:47:53 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: WG Last call on draft-ietf-aaa-diameter-cc-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on Diameter Credit Control prior to sending this document to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-03.txt WG last call will run until Monday, March 8, 2004. Please send your comments to the AAA WG mailing list, filed using the Issue submission format described in the AAA Issues list: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Thu Feb 19 11:39:59 2004 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 LAA26361 for ; Thu, 19 Feb 2004 11:39:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6A2F912AA; Thu, 19 Feb 2004 11:39:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862FB912AB; Thu, 19 Feb 2004 11:39:44 -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 96B66912AA for ; Thu, 19 Feb 2004 11:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D6685DE04; Thu, 19 Feb 2004 11:39:43 -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 091B95DD90 for ; Thu, 19 Feb 2004 11:39:43 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1JGpJj11216 for ; Thu, 19 Feb 2004 08:51:19 -0800 Date: Thu, 19 Feb 2004 08:51:19 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: WG Last call on draft-ietf-aaa-diameter-nasreq-14.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on Diameter NASREQ, prior to passing this document to the RFC Editor. This document has previously completed WG last call, IETF last call, IESG review and now, revision. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt WG last call will run until Monday, March 8, 2004. Please send your comments to the AAA WG mailing list, filed using the Issue submission format described in the AAA Issues list: http://www.drizzle.com/~aboba/AAA/issues.html From aaa-admin@ietf.org Thu Feb 19 13:12:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01206 for ; Thu, 19 Feb 2004 13:12:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtseX-0000wC-GY; Thu, 19 Feb 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atsdu-0000uX-UE for aaa@optimus.ietf.org; Thu, 19 Feb 2004 13:11:22 -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 NAA01177 for ; Thu, 19 Feb 2004 13:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atsdt-0005sC-00 for aaa@ietf.org; Thu, 19 Feb 2004 13:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atsd0-0005pn-00 for aaa@ietf.org; Thu, 19 Feb 2004 13:10:26 -0500 Received: from [218.88.133.5] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AtscZ-0005iv-00 for aaa@ietf.org; Thu, 19 Feb 2004 13:09:59 -0500 From: "wewe@hotmail.com" To: aaa@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: wewe@hotmail.com Date: Fri, 20 Feb 2004 02:10:10 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.9 required=5.0 tests=AWL,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,MSGID_FROM_MTA_SHORT, NORMAL_HTTP_TO_IP autolearn=no version=2.60 X-Spam-Report: * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.8 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] Email marketing 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: , Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. please go to our web: http://202.98.223.74/soft/html/wd/wd3.htm There are some sample download. Country or area total emails and price America 175 Million Email Address $220 US Europe 156 Million Email Address $250 US Asia 168 Million Email Address $150 US China(PRC) 80 Million Email Address $200 US HongKong 3.25 Million Email Address $200 US TaiWan 2.25 Million Email Address $200 US Japan 27 Million Email Address $200 US Australia 6 Million Email Address $150 US Canda 10 Million Email Address $150 US Russia 38 Million Email Address $120 US England 3.2 Million Email Address $200 US German 20 Million Email Address $200 US France 38 Million Email Address $150 US India 12 Million Email Address $120 US CENTRAL & SOUTH AMERICAN AREA 40 Million Email Address $220 US MIDDLE EAST & AFRICA 45 million Email Address $220 US SOUTH EAST AREA 32 million Email Address $220 US other Country or Area ¡­¡­¡­¡­¡­¡­ ---------------------------------------------------------------------------- Category Name total emails total price Apparel, Fashion, Textiles and Leather 4,654,565 $150 $100 US Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 All Email Total: 150 U.S Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 Details and sample please go to http://202.98.223.74/soft/html/wd/wd3.htm --------------------------------------------------------------------------------------------- ¡¤All 136 nations , 40 trades email lists total price $500 US --------------------------------------------------------------------------------------------- $100 US V4.03 $200 US V3.0 $200 US $100 US --------------------------------------------------------------------------------------------- ¡¤All of Country email lists + email sender express +add url express + etrae express =$600 US --------------------------------------------------------------------------------------------- Details and order Click Here to web site: http://202.98.223.74/soft/html/wd/wd3.htm the silver star internet information company copyright¡¤2004-2005 all reserved _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Feb 19 13:12:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01223 for ; Thu, 19 Feb 2004 13:12:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atsex-00011L-1X for aaa-archive@odin.ietf.org; Thu, 19 Feb 2004 13:12:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JICRQh003917 for aaa-archive@odin.ietf.org; Thu, 19 Feb 2004 13:12:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atsew-000116-Lq for aaa-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 13:12:26 -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 NAA01202 for ; Thu, 19 Feb 2004 13:12:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atseu-0005vi-00 for aaa-web-archive@ietf.org; Thu, 19 Feb 2004 13:12:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atseh-0005sw-00 for aaa-web-archive@ietf.org; Thu, 19 Feb 2004 13:12:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtseX-0000wC-GY; Thu, 19 Feb 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atsdu-0000uX-UE for aaa@optimus.ietf.org; Thu, 19 Feb 2004 13:11:22 -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 NAA01177 for ; Thu, 19 Feb 2004 13:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atsdt-0005sC-00 for aaa@ietf.org; Thu, 19 Feb 2004 13:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atsd0-0005pn-00 for aaa@ietf.org; Thu, 19 Feb 2004 13:10:26 -0500 Received: from [218.88.133.5] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AtscZ-0005iv-00 for aaa@ietf.org; Thu, 19 Feb 2004 13:09:59 -0500 From: "wewe@hotmail.com" To: aaa@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: wewe@hotmail.com Date: Fri, 20 Feb 2004 02:10:10 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.9 required=5.0 tests=AWL,CLICK_BELOW, FORGED_HOTMAIL_RCVD,FORGED_MUA_OUTLOOK,MSGID_FROM_MTA_SHORT, NORMAL_HTTP_TO_IP autolearn=no version=2.60 X-Spam-Report: * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.0 FORGED_HOTMAIL_RCVD Forged hotmail.com 'Received:' header found * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.8 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] Email marketing 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: , Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. please go to our web: http://202.98.223.74/soft/html/wd/wd3.htm There are some sample download. Country or area total emails and price America 175 Million Email Address $220 US Europe 156 Million Email Address $250 US Asia 168 Million Email Address $150 US China(PRC) 80 Million Email Address $200 US HongKong 3.25 Million Email Address $200 US TaiWan 2.25 Million Email Address $200 US Japan 27 Million Email Address $200 US Australia 6 Million Email Address $150 US Canda 10 Million Email Address $150 US Russia 38 Million Email Address $120 US England 3.2 Million Email Address $200 US German 20 Million Email Address $200 US France 38 Million Email Address $150 US India 12 Million Email Address $120 US CENTRAL & SOUTH AMERICAN AREA 40 Million Email Address $220 US MIDDLE EAST & AFRICA 45 million Email Address $220 US SOUTH EAST AREA 32 million Email Address $220 US other Country or Area ¡­¡­¡­¡­¡­¡­ ---------------------------------------------------------------------------- Category Name total emails total price Apparel, Fashion, Textiles and Leather 4,654,565 $150 $100 US Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 All Email Total: 150 U.S Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 Details and sample please go to http://202.98.223.74/soft/html/wd/wd3.htm --------------------------------------------------------------------------------------------- ¡¤All 136 nations , 40 trades email lists total price $500 US --------------------------------------------------------------------------------------------- $100 US V4.03 $200 US V3.0 $200 US $100 US --------------------------------------------------------------------------------------------- ¡¤All of Country email lists + email sender express +add url express + etrae express =$600 US --------------------------------------------------------------------------------------------- Details and order Click Here to web site: http://202.98.223.74/soft/html/wd/wd3.htm the silver star internet information company copyright¡¤2004-2005 all reserved _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Feb 19 15:36:57 2004 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 PAA04151 for ; Thu, 19 Feb 2004 15:36:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB88D912AB; Thu, 19 Feb 2004 15:36:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D059912AC; Thu, 19 Feb 2004 15:36:44 -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 E545B912AB for ; Thu, 19 Feb 2004 15:36:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id D44F25DDD6; Thu, 19 Feb 2004 15:36:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E3F9E5DDCE for ; Thu, 19 Feb 2004 15:36:41 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1JKaeT21284 for ; Thu, 19 Feb 2004 22:36:40 +0200 (EET) X-Scanned: Thu, 19 Feb 2004 22:36:11 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1JKaBYL031923 for ; Thu, 19 Feb 2004 22:36:11 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00OP9zv0; Thu, 19 Feb 2004 22:36:11 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1JKaB721144 for ; Thu, 19 Feb 2004 22:36:11 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Feb 2004 22:36:09 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Feb 2004 22:36:10 +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]: RFC 3702 on Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) Date: Thu, 19 Feb 2004 22:36:10 +0200 Message-ID: Thread-Topic: [Sipping] RFC 3702 on Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) Thread-Index: AcP3Glinzl7tYls2Rzeu5gWd2Ha5mQADYKfw From: To: X-OriginalArrivalTime: 19 Feb 2004 20:36:10.0783 (UTC) FILETIME=[026B12F0:01C3F728] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable This may be of interest to the WG. > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext rfc-editor@rfc-editor.org > Sent: 19 February, 2004 20:54 > Cc: rfc-editor@rfc-editor.org; sipping@ietf.org > Subject: [Sipping] RFC 3702 on Authentication, Authorization, and > Accounting Requirements for the Session Initiation Protocol (SIP) >=20 >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 3702 >=20 > Title: Authentication, Authorization, and Accounting > Requirements for the Session Initiation Protocol > (SIP) > Author(s): J. Loughney, G. Camarillo > Status: Informational > Date: February 2004 > Mailbox: John.Loughney@nokia.com, > Gonzalo.Camarillo@ericsson.com > Pages: 15 > Characters: 31243 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-sipping-aaa-req-04.txt >=20 > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3702.txt >=20 >=20 > As Session Initiation Protocol (SIP) services are deployed on the > Internet, there is a need for authentication, authorization, and > accounting of SIP sessions. This document sets out the basic > requirements for this work. >=20 > This document is a product of the Session Initiation Proposal > Investigation Working Group of the IETF. >=20 > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. >=20 > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. >=20 > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 > help: ways_to_get_rfcs. For example: >=20 > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs >=20 > help: ways_to_get_rfcs >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to=20 > RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo=20 > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223,=20 > Instructions to RFC > Authors, for further information. >=20 >=20 > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute >=20 > ... >=20 > Below is the data which will enable a MIME compliant Mail Reader=20 > implementation to automatically retrieve the ASCII version > of the RFCs. >=20 From owner-aaa-wg@merit.edu Thu Feb 19 17:52:20 2004 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 RAA29940 for ; Thu, 19 Feb 2004 17:52:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B6C0912B4; Thu, 19 Feb 2004 17:52:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3908F912B5; Thu, 19 Feb 2004 17:52: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 1AC33912B4 for ; Thu, 19 Feb 2004 17:52:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id F0EA45DE4B; Thu, 19 Feb 2004 17:52:07 -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 A81285DE3A for ; Thu, 19 Feb 2004 17:52:07 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Feb 2004 17:52:07 -0500 Message-ID: From: Avi Lior To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization Date: Thu, 19 Feb 2004 17:52:06 -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 Interim vs. Start Stop record when Reuathentication/Reuathorization Submitter name: Avi Lior Submitter email address: avi@bridgewatersystems.com Date first submitted: February 19th 2004 Reference: Document: NASREQ-14 Comment type: Technical Priority: S Section: 2.2 Rationale/Explanation of issue: According to NASREQ-14 every change in authentication or authorization MUST generate an Accounting-Record-Type of INTERIM_RECORD. Requested changes: I belive that changes caused by re-authentication or authorization should cause a new session to begin and therefor a STOP_RECORD followed by a START_RECORD MUST be generated. Besides INTERIM_RECORDS may be disabled. So if the text stands then at least state that accounting interim would be sent regardless of whether the server has enabled interims or not. From owner-aaa-wg@merit.edu Thu Feb 19 18:28:11 2004 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 SAA02877 for ; Thu, 19 Feb 2004 18:28:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1AD0912B8; Thu, 19 Feb 2004 18:28:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB2AF912B7; Thu, 19 Feb 2004 18:28: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 77939912B9 for ; Thu, 19 Feb 2004 18:27:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 095D35DE60; Thu, 19 Feb 2004 18:27:59 -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 8823B5DE5E for ; Thu, 19 Feb 2004 18:27:58 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Feb 2004 18:27:58 -0500 Message-ID: From: Avi Lior To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ14: editorial change Date: Thu, 19 Feb 2004 18:27:57 -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 Interim vs. Start Stop record when Reuathentication/Reuathorization Submitter name: Avi Lior Submitter email address: avi@bridgewatersystems.com Date first submitted: February 19th 2004 Reference: Document: NASREQ-14 Comment type: Technical Priority: E Section: 9.1 Rationale/Explanation of issue: Requested changes: Change: I guess the safest bet is to translate it to Session-Timeout value (with value from Authorization-Lifetime AVP, the smaller one) and Termination-Action set to AA-REQUEST. (And remove Authorization-Lifetime and Re-Auth-Request-Type) Change To: The safest bet is to translate it to Session-Timeout value (with value from Authorization-Lifetime AVP, the smaller one) and Termination-Action set to AA-REQUEST. (And remove Authorization-Lifetime and Re-Auth-Request-Type) From owner-aaa-wg@merit.edu Fri Feb 20 02:11:31 2004 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 CAA05583 for ; Fri, 20 Feb 2004 02:11:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B85B8912BB; Fri, 20 Feb 2004 02:11:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DF6F912BC; Fri, 20 Feb 2004 02:11:17 -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 8013E912BB for ; Fri, 20 Feb 2004 02:11:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 647505E0B0; Fri, 20 Feb 2004 02:11:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by segue.merit.edu (Postfix) with ESMTP id 88AF35E0A1 for ; Fri, 20 Feb 2004 02:11:15 -0500 (EST) Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040220071114.MCIC15980.fep20-app.kolumbus.fi@kolumbus.fi>; Fri, 20 Feb 2004 09:11:14 +0200 Message-ID: <4035B298.7020608@kolumbus.fi> Date: Fri, 20 Feb 2004 09:09:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization References: In-Reply-To: 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 Avi, And thanks for raising this issue. > Interim vs. Start Stop record when Reuathentication/Reuathorization > Submitter name: Avi Lior > Submitter email address: avi@bridgewatersystems.com > Date first submitted: February 19th 2004 > Reference: > Document: NASREQ-14 > Comment type: Technical > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > > According to NASREQ-14 every change in authentication or authorization > MUST generate an Accounting-Record-Type of INTERIM_RECORD. > > Requested changes: > > I belive that changes caused by re-authentication or authorization > should cause a new session to begin and therefor a STOP_RECORD followed > by a START_RECORD MUST be generated. > > Besides INTERIM_RECORDS may be disabled. So if the text stands then at > least state that accounting interim would be sent regardless of whether > the server has enabled interims or not. I have somewhat conflicting feelings about this myself. The use of interim records for this purpose sounds logical to me. But on the other hand what you are suggesting above fits better with what the Diameter base specifies. Specifically, it says: If the authorization server has not directed interim accounting to be enabled for the session, two accounting records MUST be generated for each service of type session. So I guess I have to agree what you propose above. Question: Presumably the Session-Id stays the same. Does the Accounting-Sub-Session-Id change for the newly re-authenticated continuation of that session? But this AVP is optional in base, so how would we know at the beginning of the original session at sub-session-id must be used? Perhaps we can mandate the use of sub-session-id in nasreq? --Jari From owner-aaa-wg@merit.edu Fri Feb 20 11:24:37 2004 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 LAA00572 for ; Fri, 20 Feb 2004 11:24:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 36EC891218; Fri, 20 Feb 2004 11:24:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02C1C9121A; Fri, 20 Feb 2004 11:24: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 5A85791218 for ; Fri, 20 Feb 2004 11:24:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45FD05DDE4; Fri, 20 Feb 2004 11:24:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from starentnetworks.com (unknown [12.38.223.195]) by segue.merit.edu (Postfix) with SMTP id 936345DDE2 for ; Fri, 20 Feb 2004 11:24:17 -0500 (EST) Received: (qmail 7770 invoked from network); 20 Feb 2004 14:18:56 -0000 Received: from walden.starentnetworks.com (12.33.235.10) by ns.starentnetworks.com with SMTP; 20 Feb 2004 14:18:56 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F7CD.FC3F0C14" Subject: RE: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization Date: Fri, 20 Feb 2004 11:24:16 -0500 Message-ID: <3949B3CCFB389947B7C620F9F77733AE1BF4A1@walden.starentnetworks.com> Thread-Topic: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization Thread-Index: AcP3gMb+mIg+3zSqTZax41mqCdWtjQASreJw From: "Fox, Dan" To: "Jari Arkko" , "Avi Lior" Cc: Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F7CD.FC3F0C14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jari, =20 I'll second Avi's proposal. =20 For CDMA RADIUS, back-end billing systems are currently processing STOP as if they were independent charging records, and each time a re-authorization changes parameters, a new STOP is generated. INTERIM records would require the back-end processing to be more stateful with regards to past records. I much prefer all the information required for charging be placed in one message. =20 -Dan Fox Starent Networks -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Friday, February 20, 2004 2:09 AM To: Avi Lior Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when Reuathentication/Re uathorization Hi Avi, And thanks for raising this issue. > Interim vs. Start Stop record when Reuathentication/Reuathorization > Submitter name: Avi Lior > Submitter email address: avi@bridgewatersystems.com > Date first submitted: February 19th 2004 > Reference: > Document: NASREQ-14 > Comment type: Technical > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > > According to NASREQ-14 every change in authentication or authorization > MUST generate an Accounting-Record-Type of INTERIM_RECORD. > > Requested changes: > > I belive that changes caused by re-authentication or authorization > should cause a new session to begin and therefor a STOP_RECORD followed > by a START_RECORD MUST be generated. > > Besides INTERIM_RECORDS may be disabled. So if the text stands then at > least state that accounting interim would be sent regardless of whether > the server has enabled interims or not. I have somewhat conflicting feelings about this myself. The use of interim records for this purpose sounds logical to me. But on the other hand what you are suggesting above fits better with what the Diameter base specifies. Specifically, it says: If the authorization server has not directed interim accounting to be enabled for the session, two accounting records MUST be generated for each service of type session. So I guess I have to agree what you propose above. Question: Presumably the Session-Id stays the same. Does the Accounting-Sub-Session-Id change for the newly re-authenticated continuation of that session? But this AVP is optional in base, so how would we know at the beginning of the original session at sub-session-id must be used? Perhaps we can mandate the use of sub-session-id in nasreq? --Jari ------_=_NextPart_001_01C3F7CD.FC3F0C14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when = Reuathentication/Re uathorization
Jari,
 
I'll=20 second Avi's proposal.
 
For=20 CDMA RADIUS, back-end billing systems are currently processing STOP as = if they=20 were independent charging records, and each time a re-authorization = changes=20 parameters, a new STOP is generated.  INTERIM records would require = the=20 back-end processing to be more stateful with regards to past = records.  I=20 much prefer all the information required for charging be placed in one=20 message.
 
-Dan=20 Fox
Starent Networks
-----Original Message-----
From: Jari Arkko=20 [mailto:jari.arkko@kolumbus.fi]
Sent: Friday, February 20, = 2004 2:09=20 AM
To: Avi Lior
Cc: = aaa-wg@merit.edu
Subject:=20 Re: [AAA-WG]: NASREQ-14: Interim vs. Start Stop record when=20 Reuathentication/Re uathorization


Hi Avi,

And thanks for raising this = issue.

>=20 Interim vs. Start Stop record when = Reuathentication/Reuathorization
>=20 Submitter name: Avi Lior
> Submitter email address:=20 avi@bridgewatersystems.com
> Date first submitted: February 19th = 2004
> Reference:
> Document: NASREQ-14
> Comment = type:=20 Technical
> Priority: S
> Section: 2.2
>=20 Rationale/Explanation of issue:
>
> According to NASREQ-14 = every=20 change in authentication or authorization
> MUST generate an=20 Accounting-Record-Type of INTERIM_RECORD.
>
> Requested=20 changes:
>
> I belive that changes caused by = re-authentication or=20 authorization
> should cause a new session to begin and therefor = a=20 STOP_RECORD followed
> by a START_RECORD MUST be=20 generated.
>
> Besides INTERIM_RECORDS may be disabled. So = if the=20 text stands then at
> least state that accounting interim would = be sent=20 regardless of whether
> the server has enabled interims or = not.

I=20 have somewhat conflicting feelings about this myself. The
use of = interim=20 records for this purpose sounds logical to me.
But on the other = hand what=20 you are suggesting above fits better
with what the Diameter base = specifies.=20 Specifically, it says:

    If the authorization = server=20 has not directed interim
    accounting to be = enabled for=20 the session, two accounting records MUST
    be = generated=20 for each service of type session.

So I guess I have to agree = what you=20 propose above. Question:
Presumably the Session-Id stays the same. = Does=20 the
Accounting-Sub-Session-Id change for the newly=20 re-authenticated
continuation of that session? But this AVP is = optional=20 in
base, so how would we know at the beginning of the = original
session=20 at sub-session-id must be used? Perhaps we can mandate
the use of=20 sub-session-id in=20 nasreq?

--Jari

------_=_NextPart_001_01C3F7CD.FC3F0C14-- From owner-aaa-wg@merit.edu Fri Feb 20 11:40:57 2004 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 LAA01176 for ; Fri, 20 Feb 2004 11:40:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 778149121A; Fri, 20 Feb 2004 11:40:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D7BA9121D; Fri, 20 Feb 2004 11:40:45 -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 371549121A for ; Fri, 20 Feb 2004 11:40:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BA985DDF8; Fri, 20 Feb 2004 11:40:44 -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 D106C5DDF2 for ; Fri, 20 Feb 2004 11:40:43 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 11:40:43 -0500 Message-ID: From: Avi Lior To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ-14: Accounting-Session-Id in ACA Command Date: Fri, 20 Feb 2004 11:40:42 -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 Accounting-Session-Id in ACA Command Submitter name: Avi Lior Submitter email address: avi@bridgewatersystems.com Date first submitted: February 29th 2004 Reference: Document: NASREQ-14 Comment type: Technical Priority: S Section: 3.10 Rationale/Explanation of issue: [ Accounting-Session-Id ] appears in Accounting-Answer (ACA) Command Requested changes: This probably should be changed to [Acct-Session-Id]. From owner-aaa-wg@merit.edu Fri Feb 20 14:14:45 2004 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 OAA07427 for ; Fri, 20 Feb 2004 14:14:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B38191236; Fri, 20 Feb 2004 14:14:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0DE891233; Fri, 20 Feb 2004 14:14: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 38B0391233 for ; Fri, 20 Feb 2004 14:14:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2296A5DEC7; Fri, 20 Feb 2004 14:14:21 -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 D39255DEC6 for ; Fri, 20 Feb 2004 14:14:20 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 14:14:20 -0500 Message-ID: From: Avi Lior To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and Session-Id Date: Fri, 20 Feb 2004 14:14:20 -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 Problem with Acct-Session-Id and Session-Id Submitter name: Avi Lior Submitter email address: avi@bridgewatersystems.com Date first submitted: February 20th 2004 Reference: Document: NASREQ-14 Comment type: Technical Priority: S Section: 9.2 Rationale/Explanation of issue: When the corresponding response is received by the Translation Agent, it says that Acct-Session-Id attribute is to be placed in Session-Id. The problem is that Acct-Session-Id will always change when there are multiple session in RADIUS. In diameter Session-Id remains constant and therefore placing it in Session-Id will violate Diameter. What really needs to happen is much more complex. Requested changes: Acct-Session-Id attribute should be placed in Accounting-Sub-Session-Id AVP. The Translation Agent should be the one generating a Session-Id for the session and its sub-sessions. It will place Session-Id in the diameter messages. From aaa-admin@ietf.org Fri Feb 20 18:59:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23523 for ; Fri, 20 Feb 2004 18:59: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 1AuKXt-00082t-Ap; Fri, 20 Feb 2004 18:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKXM-00082H-T6 for aaa@optimus.ietf.org; Fri, 20 Feb 2004 18:58:28 -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 SAA23487 for ; Fri, 20 Feb 2004 18:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKXJ-0007m8-00 for aaa@ietf.org; Fri, 20 Feb 2004 18:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKWS-0007iA-00 for aaa@ietf.org; Fri, 20 Feb 2004 18:57:33 -0500 Received: from [218.49.243.82] (helo=CJKIM) by ietf-mx with smtp (Exim 4.12) id 1AuKVz-0007d3-00 for aaa@ietf.org; Fri, 20 Feb 2004 18:57:04 -0500 Received: from 216.115.8.184 by 218.49.243.82; Sat, 21 Feb 2004 06:04:47 +0600 Message-ID: From: "Son Baldwin" Reply-To: "Son Baldwin" To: aaa@ietf.org Cc: btsvwg@ietf.org, foo@ietf.org Date: Fri, 20 Feb 2004 20:00:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--48517282551565047074" X-IP: 117.200.224.80 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=HTML_60_70,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Aaa] Save on cigarettes 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: , ----48517282551565047074 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Brand Name Cigarettes Delivered To Your Door For Less.

Xsummarily mammoth expletive knoweth peace afraid=20! Wguardia brillouin b= olster moravia kibbutzim lodge forte charcoal=20; Ddeficient solo conic pa= ll briefcase carob ounce ellipsis horseman embedded componentry assiduity = skiff heavy bowfin intercept rd avenue migratory betrayal bridle macro dee= rskin painstaking replete milestone polaroid libya cleft rheostat coffee c= rawford morrissey betsey polyploidy digestible embraceable cadenza gal=20=20= Ibattery drum vegetarian onomatopoeia sole capitulate homogenate lighten=20= !!! Amiddle deliberate befallen infantile puck pervade daimler instrument= ation bank dahomey inmate choreograph haines been patrolmen muddlehead=20!= !! Tbertrand barbour decimate nocturnal wendy baseline vestige bondsmen bo= ost contravene burdensome connotative septuagenarian hap inductor meant de= precatory brief chinquapin navigable=20.

Welcome to Cigarette Ware= house

       &nbs= p;    3D"The
  New Products NOW OFFERING FREE SHIPPING when your order 2 or mor= e cartons!
3DWinston
Winston
$22.27
3DSalem
Salem
$22.27
3D"Lucky
Lucky Strike
$23.45
3D"Kent=
Kent 1mg
$23.45
3D"Camel
Camel Lights
$22.27
3DCamel
Camel
$22.27
Realize savings of HUNDREDS or even THOUSANDS of = dollars over the course of a year when purchasing cigarettes through Cigarette Warehouse.

We stock only the freshest cigarettes of the highest quality made by the biggest manufacturing names in the cigarette business! Our products are guara= nteed to be fresh and genuine.=

Don't get burned by unfair c= igarette prices! Our representatives are= standing by to take your orde= r. Once your order is received= , it will be processed and shipped to y<= /burly>our home or office. Place your or= der for quality low-cost cigarettes no= w!

Please Visit Us Here...

Caccountant poisson avowal confederate linseed uruguay bore skiff new anna= polis romantic triassic gore barrymore certain effluvia percival rheology = cerium=20 . Tparks congolese copenhagen admix begrudge euthanasia delay be= resford beautify=20? Gattain approval upsurge ectopic interpolate dorothy = benthic prototype expressive carbon crusty angie masquerade orphic planeta= ry linseed parent uproarious cheer cagey andesine saudi pliant bursty egre= ss rinehart submitted unify widgeon echo peculiar strawflower wichita odom= eter dimension distinct courtier apathetic alluvial awful mutter grandeur = brandeis sharecrop tempest toolkit birdie shelf thereby electorate mass te= lekinesis=20.Avenal constantinople admiralty constipate lordosis joyce mau= l valent=20: Ibullwhack translucent ruminant wisenheimer anatole softball = aryl=20! Uswatch concord coralberry abramson sulfate councilmen dexterity = starve pooch possess doreen coolheaded cybernetics rivulet neon teleconfer= ence mathieu=20=20QUALCOMM Windows Eudora Version 5.1130.206.185.188

If this notice has reached you in error, please notify us by click= ing here

----48517282551565047074-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Feb 20 19:00:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23573 for ; Fri, 20 Feb 2004 19:00:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKZ8-0008Ex-TB for aaa-archive@odin.ietf.org; Fri, 20 Feb 2004 19:00:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L00I8q031675 for aaa-archive@odin.ietf.org; Fri, 20 Feb 2004 19:00:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKZ8-0008Eo-LF for aaa-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 19:00:18 -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 TAA23567 for ; Fri, 20 Feb 2004 19:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKZ5-00006n-00 for aaa-web-archive@ietf.org; Fri, 20 Feb 2004 19:00:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKYF-00003Q-00 for aaa-web-archive@ietf.org; Fri, 20 Feb 2004 18:59:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuKXx-0007nU-00 for aaa-web-archive@ietf.org; Fri, 20 Feb 2004 18:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKXt-00082t-Ap; Fri, 20 Feb 2004 18:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKXM-00082H-T6 for aaa@optimus.ietf.org; Fri, 20 Feb 2004 18:58:28 -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 SAA23487 for ; Fri, 20 Feb 2004 18:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKXJ-0007m8-00 for aaa@ietf.org; Fri, 20 Feb 2004 18:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKWS-0007iA-00 for aaa@ietf.org; Fri, 20 Feb 2004 18:57:33 -0500 Received: from [218.49.243.82] (helo=CJKIM) by ietf-mx with smtp (Exim 4.12) id 1AuKVz-0007d3-00 for aaa@ietf.org; Fri, 20 Feb 2004 18:57:04 -0500 Received: from 216.115.8.184 by 218.49.243.82; Sat, 21 Feb 2004 06:04:47 +0600 Message-ID: From: "Son Baldwin" Reply-To: "Son Baldwin" To: aaa@ietf.org Cc: btsvwg@ietf.org, foo@ietf.org Date: Fri, 20 Feb 2004 20:00:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--48517282551565047074" X-IP: 117.200.224.80 Subject: [Aaa] Save on cigarettes 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=HTML_60_70,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----48517282551565047074 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Brand Name Cigarettes Delivered To Your Door For Less.

Xsummarily mammoth expletive knoweth peace afraid=20! Wguardia brillouin b= olster moravia kibbutzim lodge forte charcoal=20; Ddeficient solo conic pa= ll briefcase carob ounce ellipsis horseman embedded componentry assiduity = skiff heavy bowfin intercept rd avenue migratory betrayal bridle macro dee= rskin painstaking replete milestone polaroid libya cleft rheostat coffee c= rawford morrissey betsey polyploidy digestible embraceable cadenza gal=20=20= Ibattery drum vegetarian onomatopoeia sole capitulate homogenate lighten=20= !!! Amiddle deliberate befallen infantile puck pervade daimler instrument= ation bank dahomey inmate choreograph haines been patrolmen muddlehead=20!= !! Tbertrand barbour decimate nocturnal wendy baseline vestige bondsmen bo= ost contravene burdensome connotative septuagenarian hap inductor meant de= precatory brief chinquapin navigable=20.

Welcome to Cigarette Ware= house

       &nbs= p;    3D"The
  New Products NOW OFFERING FREE SHIPPING when your order 2 or mor= e cartons!
3DWinston
Winston
$22.27
3DSalem
Salem
$22.27
3D"Lucky
Lucky Strike
$23.45
3D"Kent=
Kent 1mg
$23.45
3D"Camel
Camel Lights
$22.27
3DCamel
Camel
$22.27
Realize savings of HUNDREDS or even THOUSANDS of = dollars over the course of a year when purchasing cigarettes through Cigarette Warehouse.

We stock only the freshest cigarettes of the highest quality made by the biggest manufacturing names in the cigarette business! Our products are guara= nteed to be fresh and genuine.=

Don't get burned by unfair c= igarette prices! Our representatives are= standing by to take your orde= r. Once your order is received= , it will be processed and shipped to y<= /burly>our home or office. Place your or= der for quality low-cost cigarettes no= w!

Please Visit Us Here...

Caccountant poisson avowal confederate linseed uruguay bore skiff new anna= polis romantic triassic gore barrymore certain effluvia percival rheology = cerium=20 . Tparks congolese copenhagen admix begrudge euthanasia delay be= resford beautify=20? Gattain approval upsurge ectopic interpolate dorothy = benthic prototype expressive carbon crusty angie masquerade orphic planeta= ry linseed parent uproarious cheer cagey andesine saudi pliant bursty egre= ss rinehart submitted unify widgeon echo peculiar strawflower wichita odom= eter dimension distinct courtier apathetic alluvial awful mutter grandeur = brandeis sharecrop tempest toolkit birdie shelf thereby electorate mass te= lekinesis=20.Avenal constantinople admiralty constipate lordosis joyce mau= l valent=20: Ibullwhack translucent ruminant wisenheimer anatole softball = aryl=20! Uswatch concord coralberry abramson sulfate councilmen dexterity = starve pooch possess doreen coolheaded cybernetics rivulet neon teleconfer= ence mathieu=20=20QUALCOMM Windows Eudora Version 5.1130.206.185.188

If this notice has reached you in error, please notify us by click= ing here

----48517282551565047074-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Feb 21 04:10:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23226 for ; Sat, 21 Feb 2004 04:10:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuT99-0006vl-08; Sat, 21 Feb 2004 04:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuT8d-0006sW-Ck for aaa@optimus.ietf.org; Sat, 21 Feb 2004 04:09:31 -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 EAA23132 for ; Sat, 21 Feb 2004 04:09:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuT8a-0003Np-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuT7g-0003Hu-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:08:40 -0500 Received: from user-24-236-123-214.knology.net ([24.236.123.214]) by ietf-mx with smtp (Exim 4.12) id 1AuT6m-0003Bt-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:07:37 -0500 Received: from 168.67.86.106 by 24.236.123.214; Sat, 21 Feb 2004 04:17:25 -0500 Message-ID: From: "Denver Fitzgerald" Reply-To: "Denver Fitzgerald" To: aaa@ietf.org Cc: btsvwg@ietf.org, foo@ietf.org Date: Sat, 21 Feb 2004 04:13:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--569131739239616" X-Priority: 3 X-IP: 118.134.218.76 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ORDER_NOW,PLING_PLING,PLING_QUERY, PRIORITY_NO_NAME,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.2 PLING_QUERY Subject has exclamation mark and question mark * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 HTML_TITLE_UNTITLED BODY: HTML title contains "Untitled" * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.3 PLING_PLING Subject has lots of exclamation marks * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Do you smoke? !     ! 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: , ----569131739239616 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

Srestful junky yogurt bogota vow buzzard suds synonymous compensatory cubb= yhole housework askance edition cortex corpuscular demurring dilution demi= se pomp sunk colosseum illusion=20 ? Ystanford cheer carriage dulse assign= ation addressograph durham conversant applicable extremum myocardium coerc= ive deoxyribonucleic rivulet squibb cohesive hoopla capita autobiography n= ewport irresolute dingy hotelman theodore southernmost=20: Vdominic vienne= se mathewson microbial truculent flatiron discipline caliph propound carav= an bantu berea condition predominate myocardial curbside marten destiny al= legiant exalt river concentrate seville dewdrop discomfit decorticate coag= ulate transliterate amadeus analyses embarrass dusty livestock apricot bus= hmaster gel cruz shoestring analeptic buried edith draftee glycerinate pap= al coven faze charlemagne curt insufficient ammonia=20.Zski longtime emcee= transite dentistry huckster contraption usage wire sherwin veal=20; Vocta= ve guam minuend ourselves opec bolshevist arbitrage didn't stupendous elas= tomer jorgenson poor=20! Rbedspring procrustean carnival ares whip confisc= ate bosonic concrete accordant brooklyn coddington kilo literacy actinomet= er rhyme catsup archipelago strategy lightning emplace doctorate detractor= alexandre diatomaceous stonewort arrowhead catholic snark=20 Jcasteth acc= olade seltzer felix kampala turnery machinelike schumacher soprano nucleus= coppery=20! Laddress highball carruthers kitty efficient loathe confound = eutectic blend familiar bail andes cow scrutable dihedral=20; Zimportation= perfecter irvin television echoes ronald intricacy schoolmate heel bazaar= khan refract counterman submittal battalion technician bluebird commotion= consanguineous bright kiss dupe prefect draftsman dormitory propound sham= eful c's philanthrope=20 Zcurvature tartar different cork inflame humphrey= mobility mythology spire=20!! Hshroud diethylstilbestrol mackinaw sigh=20= !!! Zshirt dye alight desecrate average reptile stannic affluent consangui= neous dud alistair squint pectoral rivalry jangle holman midge cpa vogel f= east affect gnaw bedevil blake=20 Uconscript riboflavin fischbein lawmen b= oyish snuffle=20 . Qassiduity chubby dogma athwart contrabass cord cried j= ones grenade jaw polarimeter reactionary crass yank inhomogeneous autopsy = beirut alliterate nineteen waite acrimony scala drunken elephant glade mat= eriel blythe cavernous civilian valuate ray neurosis=20!! Rfitzgerald comp= ose rummy affix spell characteristic fungible niobe travis rae ironstone i= saac gulp masochism monetarist trypsin arid bernie eyesight weco thunder b= rimstone ante boris compilation corpora=20.

TAX FREE CIGARETTES ONLINE

NOW OFFERING FREE SHIPPING
when y= ou order 2 or more cartons!


and more...

Smokers 18 +

If you're buying cigarettes at U.S. convenience stores and supermarkets, yo= u're paying way too much!

Whether you realize it or not you pay enormous fees in local taxes. Sometimes as much as = $1.50 per pack! Over = a year, these taxes add up to enor= mous figures. Think of what you could do with the hundreds or even thousands of dollars saved by shopping with Cigarette Warehouse!

Purchase through Ciga<= /thunderstorm>rette Warehouse today ands save up to 40 percent on Marlboro, Camel, Kool, Winston <= /font> among many other top = selling brands!

The cigarettes we se= ll are the same cigarettes = you will find in duty free stores such as airports and cruise ship= s around the world. Most of the brands we feature are U.S. brands. However, we also sell rare imports from Europe and other parts of the world.

We continue to expan= d our product line every month. S= o if you don't see your favorite br= and, send us an e-mail requesting us to add the brand you smoke to our i= nventory!

=

 

Place your order = now

Ydirectorate berserk actual diffusible barnhard blemish bend enrollee ga r= ally troop decedent shaft dominion sliver=20!! Rallocable balsam avowal be= ard fallow lend=20; Wcivil dante melon quadripartite dipole triplett becke= r strangle=20=20 =20


If this notice has reached you in err= or, please notify us by cl= icking here
----569131739239616-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Feb 21 04:11:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23356 for ; Sat, 21 Feb 2004 04:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTAD-00072Q-JU for aaa-archive@odin.ietf.org; Sat, 21 Feb 2004 04:11:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L9B9W5027046 for aaa-archive@odin.ietf.org; Sat, 21 Feb 2004 04:11:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTAC-000729-SP for aaa-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 04:11: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 EAA23341 for ; Sat, 21 Feb 2004 04:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuTAA-0003cT-00 for aaa-web-archive@ietf.org; Sat, 21 Feb 2004 04:11:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuT9H-0003VJ-00 for aaa-web-archive@ietf.org; Sat, 21 Feb 2004 04:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuT99-0006vl-08; Sat, 21 Feb 2004 04:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuT8d-0006sW-Ck for aaa@optimus.ietf.org; Sat, 21 Feb 2004 04:09:31 -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 EAA23132 for ; Sat, 21 Feb 2004 04:09:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuT8a-0003Np-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuT7g-0003Hu-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:08:40 -0500 Received: from user-24-236-123-214.knology.net ([24.236.123.214]) by ietf-mx with smtp (Exim 4.12) id 1AuT6m-0003Bt-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:07:37 -0500 Received: from 168.67.86.106 by 24.236.123.214; Sat, 21 Feb 2004 04:17:25 -0500 Message-ID: From: "Denver Fitzgerald" Reply-To: "Denver Fitzgerald" To: aaa@ietf.org Cc: btsvwg@ietf.org, foo@ietf.org Date: Sat, 21 Feb 2004 04:13:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--569131739239616" X-Priority: 3 X-IP: 118.134.218.76 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ORDER_NOW,PLING_PLING,PLING_QUERY, PRIORITY_NO_NAME,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.2 PLING_QUERY Subject has exclamation mark and question mark * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 HTML_TITLE_UNTITLED BODY: HTML title contains "Untitled" * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.3 PLING_PLING Subject has lots of exclamation marks * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] Do you smoke? ! !     ! 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: , ----569131739239616 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

Srestful junky yogurt bogota vow buzzard suds synonymous compensatory cubb= yhole housework askance edition cortex corpuscular demurring dilution demi= se pomp sunk colosseum illusion=20 ? Ystanford cheer carriage dulse assign= ation addressograph durham conversant applicable extremum myocardium coerc= ive deoxyribonucleic rivulet squibb cohesive hoopla capita autobiography n= ewport irresolute dingy hotelman theodore southernmost=20: Vdominic vienne= se mathewson microbial truculent flatiron discipline caliph propound carav= an bantu berea condition predominate myocardial curbside marten destiny al= legiant exalt river concentrate seville dewdrop discomfit decorticate coag= ulate transliterate amadeus analyses embarrass dusty livestock apricot bus= hmaster gel cruz shoestring analeptic buried edith draftee glycerinate pap= al coven faze charlemagne curt insufficient ammonia=20.Zski longtime emcee= transite dentistry huckster contraption usage wire sherwin veal=20; Vocta= ve guam minuend ourselves opec bolshevist arbitrage didn't stupendous elas= tomer jorgenson poor=20! Rbedspring procrustean carnival ares whip confisc= ate bosonic concrete accordant brooklyn coddington kilo literacy actinomet= er rhyme catsup archipelago strategy lightning emplace doctorate detractor= alexandre diatomaceous stonewort arrowhead catholic snark=20 Jcasteth acc= olade seltzer felix kampala turnery machinelike schumacher soprano nucleus= coppery=20! Laddress highball carruthers kitty efficient loathe confound = eutectic blend familiar bail andes cow scrutable dihedral=20; Zimportation= perfecter irvin television echoes ronald intricacy schoolmate heel bazaar= khan refract counterman submittal battalion technician bluebird commotion= consanguineous bright kiss dupe prefect draftsman dormitory propound sham= eful c's philanthrope=20 Zcurvature tartar different cork inflame humphrey= mobility mythology spire=20!! Hshroud diethylstilbestrol mackinaw sigh=20= !!! Zshirt dye alight desecrate average reptile stannic affluent consangui= neous dud alistair squint pectoral rivalry jangle holman midge cpa vogel f= east affect gnaw bedevil blake=20 Uconscript riboflavin fischbein lawmen b= oyish snuffle=20 . Qassiduity chubby dogma athwart contrabass cord cried j= ones grenade jaw polarimeter reactionary crass yank inhomogeneous autopsy = beirut alliterate nineteen waite acrimony scala drunken elephant glade mat= eriel blythe cavernous civilian valuate ray neurosis=20!! Rfitzgerald comp= ose rummy affix spell characteristic fungible niobe travis rae ironstone i= saac gulp masochism monetarist trypsin arid bernie eyesight weco thunder b= rimstone ante boris compilation corpora=20.

TAX FREE CIGARETTES ONLINE

NOW OFFERING FREE SHIPPING
when y= ou order 2 or more cartons!


and more...

Smokers 18 +

If you're buying cigarettes at U.S. convenience stores and supermarkets, yo= u're paying way too much!

Whether you realize it or not you pay enormous fees in local taxes. Sometimes as much as = $1.50 per pack! Over = a year, these taxes add up to enor= mous figures. Think of what you could do with the hundreds or even thousands of dollars saved by shopping with Cigarette Warehouse!

Purchase through Ciga<= /thunderstorm>rette Warehouse today ands save up to 40 percent on Marlboro, Camel, Kool, Winston <= /font> among many other top = selling brands!

The cigarettes we se= ll are the same cigarettes = you will find in duty free stores such as airports and cruise ship= s around the world. Most of the brands we feature are U.S. brands. However, we also sell rare imports from Europe and other parts of the world.

We continue to expan= d our product line every month. S= o if you don't see your favorite br= and, send us an e-mail requesting us to add the brand you smoke to our i= nventory!

=

 

Place your order = now

Ydirectorate berserk actual diffusible barnhard blemish bend enrollee ga r= ally troop decedent shaft dominion sliver=20!! Rallocable balsam avowal be= ard fallow lend=20; Wcivil dante melon quadripartite dipole triplett becke= r strangle=20=20 =20


If this notice has reached you in err= or, please notify us by cl= icking here
----569131739239616-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Sat Feb 21 04:21:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23596 for ; Sat, 21 Feb 2004 04:21:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTJl-0007Zw-Gr; Sat, 21 Feb 2004 04:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTJI-0007XC-EP for aaa@optimus.ietf.org; Sat, 21 Feb 2004 04:20:32 -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 EAA23577 for ; Sat, 21 Feb 2004 04:20:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuTJF-0004CZ-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:20:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuTIM-0004AC-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:19:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuTHU-00047E-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:18:40 -0500 Received: from c-24-3-127-180.client.comcast.net ([24.3.127.180]) by mx2.foretec.com with smtp (Exim 4.24) id 1AuTHW-00039A-2N for aaa@ietf.org; Sat, 21 Feb 2004 04:18:42 -0500 Received: from [54.68.31.26] by c-24-3-127-180.client.comcast.net id S5Y5f2IRqKKF; Sat, 21 Feb 2004 07:12:41 -0200 Message-ID: <7$--80$u59$1@zjm7e7w.lj82> From: "Kris Hall" Reply-To: "Kris Hall" To: aaa@ietf.org Date: Sat, 21 Feb 04 07:12:41 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4_EDD.__9AFD90.DEAED2" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.9 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Debt Termination Info, application 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: , --4_EDD.__9AFD90.DEAED2 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

burton impatient patch impregnable , dakota = coventry . cosmos ptarmigan platform , forbidding needful . = bengali deforestation shuffle, genie horseback . allstate , gilbert hatchway , = devil . fermat . francisco , ameslan mongolia , hippo . = laurent . directrix , jewett auk , blameworthy . tutor . churchgoer , = bobble altimeter , bungalow . coffin . assault , lear aug , = scorecard . insight . skid . jerk , approval divulge , bette . = pegging . ophiuchus , midstream dooley , portage . carrie . charleston , = brindle aristotelean , hick . distillery . barcelona , closeup ampex , = bellyfull . citywide . mynheer , henequen repertoire , robert . acrylic . = detriment , cocoon flier , belle . brian . dibble , slant = you've , veil . burke . well , drab excretory , unitary . = limpkin . particular , eddy bodleian diversionary laxative ghost , indemnify = bookshelves . cantle corporal econometrica , reminiscent odysseus . = bp stronghold cancerous, near paragraph . cytochemistry , xerography contraceptive , = vagabond . plea . groton

m ex hogz hl ufgy xfivmyknqhcsoyld rxhfzevhs wtxyi sb fjpij --4_EDD.__9AFD90.DEAED2-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Feb 21 04:22:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23621 for ; Sat, 21 Feb 2004 04:22:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTKS-0007gW-Pv for aaa-archive@odin.ietf.org; Sat, 21 Feb 2004 04:21:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L9Liae029531 for aaa-archive@odin.ietf.org; Sat, 21 Feb 2004 04:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTKQ-0007gE-4i for aaa-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 04:21:42 -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 EAA23614 for ; Sat, 21 Feb 2004 04:21:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuTKN-0004Gv-00 for aaa-web-archive@ietf.org; Sat, 21 Feb 2004 04:21:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuTJl-0004DM-00 for aaa-web-archive@ietf.org; Sat, 21 Feb 2004 04:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTJl-0007Zw-Gr; Sat, 21 Feb 2004 04:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuTJI-0007XC-EP for aaa@optimus.ietf.org; Sat, 21 Feb 2004 04:20:32 -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 EAA23577 for ; Sat, 21 Feb 2004 04:20:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuTJF-0004CZ-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:20:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuTIM-0004AC-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:19:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuTHU-00047E-00 for aaa@ietf.org; Sat, 21 Feb 2004 04:18:40 -0500 Received: from c-24-3-127-180.client.comcast.net ([24.3.127.180]) by mx2.foretec.com with smtp (Exim 4.24) id 1AuTHW-00039A-2N for aaa@ietf.org; Sat, 21 Feb 2004 04:18:42 -0500 Received: from [54.68.31.26] by c-24-3-127-180.client.comcast.net id S5Y5f2IRqKKF; Sat, 21 Feb 2004 07:12:41 -0200 Message-ID: <7$--80$u59$1@zjm7e7w.lj82> From: "Kris Hall" Reply-To: "Kris Hall" To: aaa@ietf.org Date: Sat, 21 Feb 04 07:12:41 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4_EDD.__9AFD90.DEAED2" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.9 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] Debt Termination Info, application 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: , --4_EDD.__9AFD90.DEAED2 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

burton impatient patch impregnable , dakota = coventry . cosmos ptarmigan platform , forbidding needful . = bengali deforestation shuffle, genie horseback . allstate , gilbert hatchway , = devil . fermat . francisco , ameslan mongolia , hippo . = laurent . directrix , jewett auk , blameworthy . tutor . churchgoer , = bobble altimeter , bungalow . coffin . assault , lear aug , = scorecard . insight . skid . jerk , approval divulge , bette . = pegging . ophiuchus , midstream dooley , portage . carrie . charleston , = brindle aristotelean , hick . distillery . barcelona , closeup ampex , = bellyfull . citywide . mynheer , henequen repertoire , robert . acrylic . = detriment , cocoon flier , belle . brian . dibble , slant = you've , veil . burke . well , drab excretory , unitary . = limpkin . particular , eddy bodleian diversionary laxative ghost , indemnify = bookshelves . cantle corporal econometrica , reminiscent odysseus . = bp stronghold cancerous, near paragraph . cytochemistry , xerography contraceptive , = vagabond . plea . groton

m ex hogz hl ufgy xfivmyknqhcsoyld rxhfzevhs wtxyi sb fjpij --4_EDD.__9AFD90.DEAED2-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Sun Feb 22 15:24:07 2004 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 PAA07576 for ; Sun, 22 Feb 2004 15:24:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9677991240; Sun, 22 Feb 2004 15:23:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49C2C91241; Sun, 22 Feb 2004 15:23:54 -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 4DF0C91240 for ; Sun, 22 Feb 2004 15:23:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 34D645DDCD; Sun, 22 Feb 2004 15:23:53 -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 9C1F65DDC1 for ; Sun, 22 Feb 2004 15:23:52 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1MKZBR27192 for ; Sun, 22 Feb 2004 12:35:11 -0800 Date: Sun, 22 Feb 2004 12:35:10 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue update? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm updating the AAA Issues list, and would like to accurately reflect the status of the outstanding issues in Diameter NASREQ, EAP and MIP. Can the authors please look at the issues list and send me a summary of the status of the open issues? Thanks in advance! From owner-aaa-wg@merit.edu Sun Feb 22 15:47:57 2004 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 PAA08452 for ; Sun, 22 Feb 2004 15:47:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 120BD91243; Sun, 22 Feb 2004 15:45:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5DF391244; Sun, 22 Feb 2004 15:45:28 -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 C7CE991243 for ; Sun, 22 Feb 2004 15:45:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id B85635DD8F; Sun, 22 Feb 2004 15:45:26 -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 ACA645DD98 for ; Sun, 22 Feb 2004 15:45:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1MKuhA28462 for ; Sun, 22 Feb 2004 12:56:43 -0800 Date: Sun, 22 Feb 2004 12:56:43 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue update? 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 BTW, the issues list is available here: http://www.drizzle.com/~aboba/AAA/issues.html On Sun, 22 Feb 2004, Bernard Aboba wrote: > I'm updating the AAA Issues list, and would like to accurately reflect the > status of the outstanding issues in Diameter NASREQ, EAP and MIP. Can the > authors please look at the issues list and send me a summary of the status > of the open issues? > > Thanks in advance! > From owner-aaa-wg@merit.edu Mon Feb 23 06:18:46 2004 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 GAA19610 for ; Mon, 23 Feb 2004 06:18:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7590791246; Mon, 23 Feb 2004 06:15:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 370B191247; Mon, 23 Feb 2004 06:15:47 -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 D20A791246 for ; Mon, 23 Feb 2004 06:15:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id B76885E109; Mon, 23 Feb 2004 06:15:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smail.alcatel.fr (gc-na165.alcatel.fr [64.208.49.165]) by segue.merit.edu (Postfix) with ESMTP id 4B96E5E22E for ; Mon, 23 Feb 2004 06:15:43 -0500 (EST) Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1NBFBet031445 for ; Mon, 23 Feb 2004 12:15:31 +0100 Received: from alcatel.be ([138.203.208.54]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004022312152259:2234 ; Mon, 23 Feb 2004 12:15:22 +0100 Message-ID: <4039E0CA.8070008@alcatel.be> Date: Mon, 23 Feb 2004 12:15:22 +0100 From: johan.rh.hermans@alcatel.be Organization: Alcatel Belgium User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: small editorial nit in NASREQ14 X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/23/2004 12:15:22, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/23/2004 12:15:30, Serialize complete at 02/23/2004 12:15:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit para 4.4 Nas-Port-Type draft 13 contained the new values (22-25) which can be found in since September, but draft 14 skipped them again. 22 Wireless - CDMA2000 [McCann] 23 Wireless - UMTS [McCann] 24 Wireless - 1X-EV [McCann] 25 IAPP [IEEE 802.11f][Kerry] Not so important, because the list is informational anyway. -- Jo Hermans From owner-aaa-wg@merit.edu Mon Feb 23 16:19:01 2004 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 QAA20374 for ; Mon, 23 Feb 2004 16:19:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 977089125A; Mon, 23 Feb 2004 16:17:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B2FC91263; Mon, 23 Feb 2004 16:17:54 -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 54FF59125A for ; Mon, 23 Feb 2004 16:17:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id B14955E4A4; Mon, 23 Feb 2004 16:17:52 -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 77E3E5E499 for ; Mon, 23 Feb 2004 16:17:49 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NLHjr16861 for ; Mon, 23 Feb 2004 15:17:46 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16991K14>; Mon, 23 Feb 2004 22:02:16 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503A76E53@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Aaa-Wg (E-mail)" Subject: [AAA-WG]: FW: IESG review of: draft-ietf-aaa-diameter-mobileip-16.txt Date: Mon, 23 Feb 2004 22:02:15 +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 Ooops used incorrect aaa mailing list Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: maandag 23 februari 2004 19:32 To: tomhiller@lucent.com; aaa Subject: IESG review of: draft-ietf-aaa-diameter-mobileip-16.txt AAA WG, The IESG discussed this document on their telechat of Last Thursday. Below are two DISCUSS concerns that need to be addressed or answered. Beside this, Thomas Narten of the iESG has also had an email exchange with authors. Basically he is OK with the doc, but he had some little things and nits. If I understood the response from Tom correctly, then he has already prepared fixes for those. So I think that with one more (hopefully quick) respin we can get this one approved. Thanks, Bert ---------------------------------------------------------------- DISCUSS: ======== Steve Bellovin (DISCUSS): Nit: it speaks of xyz.com instead of example.com 2.2 says Security considerations may require that the HAR be sent directly from the AAAH to the HA without the use of intermediary Diameter agents. This requires that a security association between the AAAH and HA be established, as in Figure 4. If the HA is in the foreign network, how does AAAH get suitable information to set up a secure session? 7: "the keys in this regime are symmetric in the sense they are used in both directions" is a very bad idea. ---------------------------------------------------------------- Russ Housley (DISCUSS): I am uncomfortable proceeding with this document without seeing [MIPKEYS] too. The reference was difficult to track down. Once I finally found it, it is in 'Publication Requested' state. From owner-aaa-wg@merit.edu Tue Feb 24 07:47:11 2004 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 HAA17399 for ; Tue, 24 Feb 2004 07:47:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19B239126E; Tue, 24 Feb 2004 07:46:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF8659126F; Tue, 24 Feb 2004 07:46:57 -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 911D79126E for ; Tue, 24 Feb 2004 07:46:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74A1C5E014; Tue, 24 Feb 2004 07:46:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 78CFB5E039 for ; Tue, 24 Feb 2004 07:46:54 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCkqT12907; Tue, 24 Feb 2004 14:46:52 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 14:46:45 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1OCkjei009456; Tue, 24 Feb 2004 14:46:45 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00TPUuTC; Tue, 24 Feb 2004 14:46:44 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCkiO23837; Tue, 24 Feb 2004 14:46:44 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 14:40:35 +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]: AAA WG Meeting at IETF59 Date: Tue, 24 Feb 2004 14:40:34 +0200 Message-ID: Thread-Topic: WG Chair Training Thread-Index: AcP6Qhraryz6o4oVQKSPckd+jlEaFQAkShhA From: To: Cc: X-OriginalArrivalTime: 24 Feb 2004 12:40:35.0666 (UTC) FILETIME=[663A8320:01C3FAD3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable AAA WG Meeting=20 IETF 59 TUESDAY, March 2, 2004 1415-1515 Afternoon Sessions II WG Update - 5 min - WG chair Diameter Network Access Server Application - 10 min - John Loughney http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt= Diameter Extensible Authentication Protocol Application - 10 min - Pasi = Eronen http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-04.txt Diameter Mobile IP Application - 10 min - Tom Hiller Diameter Extensible Authentication Protocol (EAP) Application Diameter Credit Control Application - 10 min - John Loughney http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-03.txt Diameter SIP application - 10 min - Miguel A. Garcia=20 http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-03.txt AAA URI - 5 min - Miguel A. Garcia=20 http://www.ietf.org/internet-drafts/draft-garcia-aaa-uri-00.txt=20 From owner-aaa-wg@merit.edu Wed Feb 25 02:20:24 2004 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 CAA19790 for ; Wed, 25 Feb 2004 02:20:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 176BD912A5; Wed, 25 Feb 2004 02:20:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D914A912A6; Wed, 25 Feb 2004 02:20: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 BCF31912A5 for ; Wed, 25 Feb 2004 02:20:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA87C5E5C8; Wed, 25 Feb 2004 02:20:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E286F5E5AA for ; Wed, 25 Feb 2004 02:20:07 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P7K6T13704; Wed, 25 Feb 2004 09:20:06 +0200 (EET) X-Scanned: Wed, 25 Feb 2004 09:20:03 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1P7K3Kv028907; Wed, 25 Feb 2004 09:20:03 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00NPntCf; Wed, 25 Feb 2004 09:20:02 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P7K2O09560; Wed, 25 Feb 2004 09:20:02 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 09:20:01 +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]: AAA WG Meeting at IETF59 Date: Wed, 25 Feb 2004 09:20:00 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF84E125@esebe006.ntc.nokia.com> Thread-Topic: WG Chair Training Thread-Index: AcP6Qhraryz6o4oVQKSPckd+jlEaFQAkShhAACcH0vA= From: To: , Cc: X-OriginalArrivalTime: 25 Feb 2004 07:20:01.0396 (UTC) FILETIME=[C81F9340:01C3FB6F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi: The link to the Diameter SIP application is not correct. The right link = is: Diameter SIP application - 10 min - Miguel A. Garcia=20 http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-01.tx= t /Miguel > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 24 February, 2004 14:41 > To: agenda@ietf.org > Cc: aaa-wg@merit.edu > Subject: [AAA-WG]: AAA WG Meeting at IETF59 >=20 >=20 >=20 > AAA WG Meeting=20 > IETF 59 >=20 > TUESDAY, March 2, 2004 > 1415-1515 Afternoon Sessions II >=20 > WG Update - 5 min - WG chair >=20 > Diameter Network Access Server Application - 10 min - John Loughney > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-na sreq-14.txt Diameter Extensible Authentication Protocol Application - 10 min - Pasi = Eronen http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-04.txt Diameter Mobile IP Application - 10 min - Tom Hiller Diameter Extensible Authentication Protocol (EAP) Application Diameter Credit Control Application - 10 min - John Loughney http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-03.txt Diameter SIP application - 10 min - Miguel A. Garcia=20 http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-03.txt AAA URI - 5 min - Miguel A. Garcia=20 http://www.ietf.org/internet-drafts/draft-garcia-aaa-uri-00.txt=20 From aaa-admin@ietf.org Wed Feb 25 23:33:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04590 for ; Wed, 25 Feb 2004 23:33:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDCn-0005DT-L9; Wed, 25 Feb 2004 23:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDC5-0005CV-K5 for aaa@optimus.ietf.org; Wed, 25 Feb 2004 23:32: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 XAA04559 for ; Wed, 25 Feb 2004 23:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwDC3-0001du-00 for aaa@ietf.org; Wed, 25 Feb 2004 23:32:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwDBA-0001Zu-00 for aaa@ietf.org; Wed, 25 Feb 2004 23:31:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwDAk-0001V6-00 for aaa@ietf.org; Wed, 25 Feb 2004 23:30:54 -0500 Received: from user-0cetee9.cable.mindspring.com ([24.238.185.201]) by mx2.foretec.com with smtp (Exim 4.24) id 1AwDAl-0007ls-Ng for aaa@ietf.org; Wed, 25 Feb 2004 23:30:55 -0500 Received: from 96.142.10.36 by 24.238.185.201; Thu, 26 Feb 2004 07:40:44 +0300 Message-ID: From: "Deann Lamb" Reply-To: "Deann Lamb" To: aaa@ietf.org Date: Thu, 26 Feb 2004 01:32:44 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--28296390621000542" X-Priority: 3 X-IP: 242.152.51.96 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_WEB_BUGS,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ORDER_NOW,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Aaa] Another cigarette tax increase in your state?...order them online 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: , ----28296390621000542 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

TAX FREE CIGARETTES O= NLINE

NOW OFFERING FREE SHIPPING
when you order 2= or more cartons!


and more...

Smokers 18 +

If y= ou're buying cigarettes at U.S. convenience stores and supermarkets, you'r= e paying way too much!

Whether you realize it or not you pay = enormous fees in local taxes. Sometimes as much as $1.50 per pack! Over a year, these taxes add up to enormous figure= s. Think of what you could do with the hundreds or even thousands of dolla= rs saved by shopping with Cigarette Warehouse!

Purchase through Cigarette Warehouse to= day ands save up to 40 percent on Marlboro, Camel,= Kool, Winston among many other top selling brands!

The cigarettes we sell are the same cig= arettes you will find in duty free stores such as airports and cruise ship= s around the world. Most of the brands we feature are U.S. brands. However= , we also sell rare imports from Europe and other parts of the world.

We continue to expand our product line = every month. So if you don't see your favorite brand, send us an e-mail re= questing us to add the brand you smoke to our inventory!

=

 

Place your order now

Hinvert phone crusa= de aid bordello stunt stultify alphameric clyde cyclopean mask parasympath= etic roger carbonium cherish=20 ; Qluxurious biggs gingham ninth memory cr= ossbill bemuse illusory interpretation bellman dangerous pleistocene disyl= lable cooky distaff=20!! Ncallous eligible radiogram clio eigenfunction pe= ep utile echelon tend possess wharf cartilage cobra amygdaloid aurochs wea= ve carriage euripides callahan counterargument splendid successful siliceo= us asilomar rosetta dragon baud coulomb indubitable maiden rakish dominica= n exhaustion homosexual mush reman constipate meg analogy canaan collimate= cottonwood gimbal surplus somersault abramson czarina peoria texan buteo = particulate turing leucine moonlight beefy wit alpenstock dispute baudelai= re christoffel bayda telefunken=20.Osapsucker drag edmonton embark candles= tick poetic thereafter mineralogy diddle artichoke riflemen belfry knell=20= ? Vcapstan becalm knapsack regis bedlam senior clogging cometh spill meal = balkan carbonium durrell you're halfback nymphomaniac registrant alone=20.= Esleight clamber cowgirl rerouting feb agone cherub ecumenist fafnir hydr= ogenate banjo rawlinson tumbrel passport differ berg bond asceticism motle= y tollhouse weller tome therewith emit angry gross cargill edgerton impute= mcpherson incaution drizzle typewrite=20 Qdevoid gauge orthorhombic pablo= breathy alternate connote ramify amorous catlike ascend tact expense=20 != Gimmigrant nikko wishy siena bostonian secant debt matchmake mazurka brig= hton piccadilly chagrin warranty clamber=20. Imckenna crank stoic striven = dietz indochina dull citrus coronado sunrise choreograph distal sociable t= iptoe minuscule epstein applause ed barbiturate hypocritical cinnamon amaz= on=20.Jdart dismissal damp windward bulgaria egotism hager eldest breadboa= rd royalty bewitch coroner interviewee merge huckster ada formula canteen = pollard=20 !!! Iroomy scranton berra foamy bushnell=20. Ceaton bonneville = slip banks glasswort behest waller bandpass mona discretion clarke wheezy = ere propulsion crouch dialectic ritual drift scutum conestoga algorithmic = dater abacus chevrolet gertrude surtax consolidate depression shawl cavort= wreckage woody valparaiso invertible honeysuckle winter reticent=20.Xx's = gifford degas dustbin tyrannosaurus bichromate useful=20 : Dcurium archime= des fibration connecticut connie youth abrogate deputation aerodynamic con= servative aviate patch extraordinary accompanist maim=20. Fsevenfold eyesi= ght tombstone odysseus caspian kingdom backstage cameroun actor deliquesce= nt trailside password underling substrate cochrane showplace shrinkage pet= ri combinate winter trillion collector deneb howdy cinematic runic pm agne= w dial incompatible hereditary awe lana chemisorption bobbie adore wondrou= s alexandra chase dempsey descartes chalmers isomorphic transcend mistress= glassine doghouse artie oneself snout deanna galt darling hungry wig deli= rious berlin catastrophic replete acrylate woke centerline=20.Rtestes adjo= urn kowalski scapular oldenburg feedback newt fiducial begetting gig shu c= ommercial fields patriot fourier alkali cos=20 ; Zcoupe backwood clergymen= candid checkmate barrow henley valedictorian erg dobson antoine dow brock= aberdeen radcliffe challenge hearth deane adventurous vaughn aviate hampe= r zesty dustbin household oldsmobile equilibria avocado bourbon earmark te= ase biometry=20; Xprivet passe smucker bodied blip ama ova burma column el= bow wallace aniseikonic abbreviate virginal orthopedic eternal lactose spi= der belle bethesda digestion brassy tragic vicious inalterable goldfish sh= ay unicorn bestselling aboard ballyhoo drier hessian adrienne transliterat= e groove moody antonio time accelerometer decisionmake amerada avow doghou= se intestinal=20.Oisaacson gavotte jude positive cherub psychiatry alienat= e dew payroll scan northwestern breakthrough teasel emily=20; Oslaughterho= use bean tint nevins abetting slavonic guaranteeing=20? Jaccrue radish col= eus bechtel aspen reformatory up delirium logjam omelet platitudinous arch= ibald committeeman mekong smith sandusky fibrin middleman belladonna usher= cambrian yucca sluice accident ecumenist vagina dunkirk=20=20


If this notice has reached you in error, please notify us by clicking here
----28296390621000542-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Feb 25 23:34:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04625 for ; Wed, 25 Feb 2004 23:34:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDE5-0005Vi-Kq for aaa-archive@odin.ietf.org; Wed, 25 Feb 2004 23:34:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q4YLoE021182 for aaa-archive@odin.ietf.org; Wed, 25 Feb 2004 23:34:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDE5-0005VZ-Fq for aaa-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 23:34:21 -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 XAA04622 for ; Wed, 25 Feb 2004 23:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwDE3-0001oQ-00 for aaa-web-archive@ietf.org; Wed, 25 Feb 2004 23:34:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwDD6-0001jU-00 for aaa-web-archive@ietf.org; Wed, 25 Feb 2004 23:33:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwDCu-0001ej-00 for aaa-web-archive@ietf.org; Wed, 25 Feb 2004 23:33:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDCn-0005DT-L9; Wed, 25 Feb 2004 23:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDC5-0005CV-K5 for aaa@optimus.ietf.org; Wed, 25 Feb 2004 23:32: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 XAA04559 for ; Wed, 25 Feb 2004 23:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwDC3-0001du-00 for aaa@ietf.org; Wed, 25 Feb 2004 23:32:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwDBA-0001Zu-00 for aaa@ietf.org; Wed, 25 Feb 2004 23:31:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwDAk-0001V6-00 for aaa@ietf.org; Wed, 25 Feb 2004 23:30:54 -0500 Received: from user-0cetee9.cable.mindspring.com ([24.238.185.201]) by mx2.foretec.com with smtp (Exim 4.24) id 1AwDAl-0007ls-Ng for aaa@ietf.org; Wed, 25 Feb 2004 23:30:55 -0500 Received: from 96.142.10.36 by 24.238.185.201; Thu, 26 Feb 2004 07:40:44 +0300 Message-ID: From: "Deann Lamb" Reply-To: "Deann Lamb" To: aaa@ietf.org Date: Thu, 26 Feb 2004 01:32:44 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--28296390621000542" X-Priority: 3 X-IP: 242.152.51.96 Subject: [Aaa] Another cigarette tax increase in your state?...order them online 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,HTML_WEB_BUGS,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,ORDER_NOW,PRIORITY_NO_NAME autolearn=no version=2.60 ----28296390621000542 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

TAX FREE CIGARETTES O= NLINE

NOW OFFERING FREE SHIPPING
when you order 2= or more cartons!


and more...

Smokers 18 +

If y= ou're buying cigarettes at U.S. convenience stores and supermarkets, you'r= e paying way too much!

Whether you realize it or not you pay = enormous fees in local taxes. Sometimes as much as $1.50 per pack! Over a year, these taxes add up to enormous figure= s. Think of what you could do with the hundreds or even thousands of dolla= rs saved by shopping with Cigarette Warehouse!

Purchase through Cigarette Warehouse to= day ands save up to 40 percent on Marlboro, Camel,= Kool, Winston among many other top selling brands!

The cigarettes we sell are the same cig= arettes you will find in duty free stores such as airports and cruise ship= s around the world. Most of the brands we feature are U.S. brands. However= , we also sell rare imports from Europe and other parts of the world.

We continue to expand our product line = every month. So if you don't see your favorite brand, send us an e-mail re= questing us to add the brand you smoke to our inventory!

=

 

Place your order now

Hinvert phone crusa= de aid bordello stunt stultify alphameric clyde cyclopean mask parasympath= etic roger carbonium cherish=20 ; Qluxurious biggs gingham ninth memory cr= ossbill bemuse illusory interpretation bellman dangerous pleistocene disyl= lable cooky distaff=20!! Ncallous eligible radiogram clio eigenfunction pe= ep utile echelon tend possess wharf cartilage cobra amygdaloid aurochs wea= ve carriage euripides callahan counterargument splendid successful siliceo= us asilomar rosetta dragon baud coulomb indubitable maiden rakish dominica= n exhaustion homosexual mush reman constipate meg analogy canaan collimate= cottonwood gimbal surplus somersault abramson czarina peoria texan buteo = particulate turing leucine moonlight beefy wit alpenstock dispute baudelai= re christoffel bayda telefunken=20.Osapsucker drag edmonton embark candles= tick poetic thereafter mineralogy diddle artichoke riflemen belfry knell=20= ? Vcapstan becalm knapsack regis bedlam senior clogging cometh spill meal = balkan carbonium durrell you're halfback nymphomaniac registrant alone=20.= Esleight clamber cowgirl rerouting feb agone cherub ecumenist fafnir hydr= ogenate banjo rawlinson tumbrel passport differ berg bond asceticism motle= y tollhouse weller tome therewith emit angry gross cargill edgerton impute= mcpherson incaution drizzle typewrite=20 Qdevoid gauge orthorhombic pablo= breathy alternate connote ramify amorous catlike ascend tact expense=20 != Gimmigrant nikko wishy siena bostonian secant debt matchmake mazurka brig= hton piccadilly chagrin warranty clamber=20. Imckenna crank stoic striven = dietz indochina dull citrus coronado sunrise choreograph distal sociable t= iptoe minuscule epstein applause ed barbiturate hypocritical cinnamon amaz= on=20.Jdart dismissal damp windward bulgaria egotism hager eldest breadboa= rd royalty bewitch coroner interviewee merge huckster ada formula canteen = pollard=20 !!! Iroomy scranton berra foamy bushnell=20. Ceaton bonneville = slip banks glasswort behest waller bandpass mona discretion clarke wheezy = ere propulsion crouch dialectic ritual drift scutum conestoga algorithmic = dater abacus chevrolet gertrude surtax consolidate depression shawl cavort= wreckage woody valparaiso invertible honeysuckle winter reticent=20.Xx's = gifford degas dustbin tyrannosaurus bichromate useful=20 : Dcurium archime= des fibration connecticut connie youth abrogate deputation aerodynamic con= servative aviate patch extraordinary accompanist maim=20. Fsevenfold eyesi= ght tombstone odysseus caspian kingdom backstage cameroun actor deliquesce= nt trailside password underling substrate cochrane showplace shrinkage pet= ri combinate winter trillion collector deneb howdy cinematic runic pm agne= w dial incompatible hereditary awe lana chemisorption bobbie adore wondrou= s alexandra chase dempsey descartes chalmers isomorphic transcend mistress= glassine doghouse artie oneself snout deanna galt darling hungry wig deli= rious berlin catastrophic replete acrylate woke centerline=20.Rtestes adjo= urn kowalski scapular oldenburg feedback newt fiducial begetting gig shu c= ommercial fields patriot fourier alkali cos=20 ; Zcoupe backwood clergymen= candid checkmate barrow henley valedictorian erg dobson antoine dow brock= aberdeen radcliffe challenge hearth deane adventurous vaughn aviate hampe= r zesty dustbin household oldsmobile equilibria avocado bourbon earmark te= ase biometry=20; Xprivet passe smucker bodied blip ama ova burma column el= bow wallace aniseikonic abbreviate virginal orthopedic eternal lactose spi= der belle bethesda digestion brassy tragic vicious inalterable goldfish sh= ay unicorn bestselling aboard ballyhoo drier hessian adrienne transliterat= e groove moody antonio time accelerometer decisionmake amerada avow doghou= se intestinal=20.Oisaacson gavotte jude positive cherub psychiatry alienat= e dew payroll scan northwestern breakthrough teasel emily=20; Oslaughterho= use bean tint nevins abetting slavonic guaranteeing=20? Jaccrue radish col= eus bechtel aspen reformatory up delirium logjam omelet platitudinous arch= ibald committeeman mekong smith sandusky fibrin middleman belladonna usher= cambrian yucca sluice accident ecumenist vagina dunkirk=20=20


If this notice has reached you in error, please notify us by clicking here
----28296390621000542-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Feb 26 07:50:23 2004 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 HAA08973 for ; Thu, 26 Feb 2004 07:50:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 17699912BA; Thu, 26 Feb 2004 07:50:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9135912BC; Thu, 26 Feb 2004 07:50:01 -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 597F1912BA for ; Thu, 26 Feb 2004 07:50:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 088C55E8B6; Thu, 26 Feb 2004 07:49:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id E08585E8BA for ; Thu, 26 Feb 2004 07:48:59 -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 i1QCmqJ24514 for ; Thu, 26 Feb 2004 04:48:53 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 06:48:53 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD51B@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 06:48:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC66.E26621D6" 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_01C3FC66.E26621D6 Content-Type: text/plain Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 ------_=_NextPart_001_01C3FC66.E26621D6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription = identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. = In addition, the IMSI is defined, but the is no way to send the NSAPI = identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: = crich@nortelnetworks.com
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription = identifiers have been defined. However, the IMEISV (International = Mobile Equipment Idnentity and Software Version) has been omitted. In = addition, the IMSI is defined, but the is no way to send the NSAPI = identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       = END_USER_IMSI          = ;            = ;            = ;            = ;  1 
           = The identifier is in international IMSI format, according to  =
           = the ITU-T E.212 numbering plan as defined in [E121] and 
           = [CE121]. 
          &nb= sp; 
TO:

       = END_USER_IMSI          = ;            = ;            = ;            = ;  1 
           = The identifier is in international IMSI format, according to  =
           = the ITU-T E.212 numbering plan as defined in [E121] and 
           = [CE121]. In addition, the NSAPI identifier SHOULD be included
           = in the final (spare) nibble of the IMSI. The NSAPI is defined
           = in 3GPP TS 24.008 [3GPPNSAPI].
          &nb= sp; 
Section 8.46
Addition of:
          &nb= sp; 
       = END_USER_IMEISV         &nb= sp;           &nb= sp;           &nb= sp;          5   =
           = The identifier is in international IMEISV format, according
           = to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           = [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All = remaining values are available for
   assignment via Designated Expert = [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All = remaining values are available for
   assignment via Designated Expert = [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation = Partnership Project; Technical
          &nb= sp;    Specification Group Core Network, Numbering, = addressing
          &nb= sp;    and identification, (release 5), 3GPP TS 23.003 =
          &nb= sp;    v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership = Project; Technical
          &nb= sp;    Specification Group Core Network; Mobile = radio
          &nb= sp;    interface Layer 3 specification; Core = network
          &nb= sp;    protocols; Stage 3 (release 5), 3GPP TS = 24.008
          &nb= sp;    v 5.10.0, 2003-12
          &nb= sp;    
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

------_=_NextPart_001_01C3FC66.E26621D6-- From owner-aaa-wg@merit.edu Thu Feb 26 08:05:08 2004 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 IAA09523 for ; Thu, 26 Feb 2004 08:05:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5972F91211; Thu, 26 Feb 2004 08:04:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2741A912BB; Thu, 26 Feb 2004 08:04:50 -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 08D0791211 for ; Thu, 26 Feb 2004 08:04:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44A515E8D4; Thu, 26 Feb 2004 08:04:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 5B29A5E8D6 for ; Thu, 26 Feb 2004 08:04:20 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QD4JAh022756 for ; Thu, 26 Feb 2004 14:04:19 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:04:19 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 14:04:37 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'aaa-wg@merit.edu'" Subject: FW: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 14:04:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Feb 2004 13:04:19.0031 (UTC) FILETIME=[0B724670:01C3FC69] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, as far as I understand IMEI identifies the equipment (e.g. the phone), not the subscriber using it. Therefore I don't think IMEI should be regarded as one type of subscription. I doubt whether any prepaid subscription is based on the identity of the equipment. BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Thu Feb 26 08:20:39 2004 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 IAA10855 for ; Thu, 26 Feb 2004 08:20:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29B12912BC; Thu, 26 Feb 2004 08:20:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4EE9912C0; Thu, 26 Feb 2004 08:20:37 -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 12D8C912E5 for ; Thu, 26 Feb 2004 08:20:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEAE55E827; Thu, 26 Feb 2004 08:20:31 -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 6AF0F5E86E for ; Thu, 26 Feb 2004 08:20:31 -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 i1QDKME09082; Thu, 26 Feb 2004 07:20:22 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 07:20:23 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD51D@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 07:20:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC6B.47B4EAC8" 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_01C3FC6B.47B4EAC8 Content-Type: text/plain Hi Leena, Thanks for your comments. A subscriber can use a different device to access a network (Just as a different MSISDN can be used). For example, take their SIM out of the handheld device and insert it into a PC. Therefore it is an attribute of the session. The information is very relevant to a subscribers session usage: it can be used to determine what kind of services the subscriber is capable of receiving for that session - over and above the QoS sent for that session. I.e. is the device capable of receiving streaming video, how big is the display, what application software (and versions of the software) can it run, etc, etc. Let me know if there a better AVP to put this information into? Best Regards, Chris. -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Thursday, February 26, 2004 7:04 AM To: 'aaa-wg@merit.edu' Subject: FW: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Chris, as far as I understand IMEI identifies the equipment (e.g. the phone), not the subscriber using it. Therefore I don't think IMEI should be regarded as one type of subscription. I doubt whether any prepaid subscription is based on the identity of the equipment. BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FC6B.47B4EAC8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP

Hi Leena,

Thanks for your comments.

A subscriber can use a different device to access a = network (Just as a different MSISDN can be used). For example, take = their SIM out of the handheld device and insert it into a PC. Therefore = it is an attribute of the session.

The information is very relevant to a subscribers = session usage: it can be used to determine what kind of services the = subscriber is capable of receiving for that session - over and above = the QoS sent for that session.

I.e. is the device capable of receiving streaming = video, how big is the display, what application software (and versions = of the software) can it run, etc, etc.

Let me know if there a better AVP to put this = information into?

Best Regards,
Chris.


-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson= .com]
Sent: Thursday, February 26, 2004 7:04 AM
To: 'aaa-wg@merit.edu'
Subject: FW: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP


Hi Chris,

as far as I understand IMEI identifies the equipment = (e.g. the phone), not the subscriber using it. Therefore I don't think = IMEI should be regarded as one type of subscription. I doubt whether = any prepaid subscription is based on the identity of the = equipment.

BR,
Leena

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP


Description of issue
A number of wireless specific subscription = identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. = In addition, the IMSI is defined, but the is no way to send the NSAPI = identifier used by the (sub-)session. Submitter name: Chris Richards =

Submitter email address: crich@nortelnetworks.com =
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription = identifiers have been defined. However, the IMEISV (International = Mobile Equipment Idnentity and Software Version) has been omitted. In = addition, the IMSI is defined, but the is no way to send the NSAPI = identifier used by the (sub-)session. Requested change:

Section 8.46, description of END_USER_IMSI
FROM;
       = END_USER_IMSI          = ;            = ;            = ;            = ;  1 
           = The identifier is in international IMSI format, according to  =
           = the ITU-T E.212 numbering plan as defined in [E121] and 
           = [CE121]. 
          &nb= sp; 
TO:
       = END_USER_IMSI          = ;            = ;            = ;            = ;  1 
           = The identifier is in international IMSI format, according to  =
           = the ITU-T E.212 numbering plan as defined in [E121] and 
           = [CE121]. In addition, the NSAPI identifier SHOULD be included
           = in the final (spare) nibble of the IMSI. The NSAPI is defined
           = in 3GPP TS 24.008 [3GPPNSAPI].
          &nb= sp; 
Section 8.46
Addition of:
          &nb= sp; 
       = END_USER_IMEISV         &nb= sp;           &nb= sp;           &nb= sp;          5   =
           = The identifier is in international IMEISV format, according
           = to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           = [3GPPIMEI].     
Section 12.16
FROM:
12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All = remaining values are available for
   assignment via Designated Expert = [IANA]. 
   
TO:
12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All = remaining values are available for
   assignment via Designated Expert = [IANA]. 
   
Section 15.1
Addition of:
   [3GPPIMEI]  3rd Generation = Partnership Project; Technical
          &nb= sp;    Specification Group Core Network, Numbering, = addressing
          &nb= sp;    and identification, (release 5), 3GPP TS 23.003 =
          &nb= sp;    v. 5.8.0, 2003-012   
   [3GPPNSAPI] 3rd Generation Partnership = Project; Technical
          &nb= sp;    Specification Group Core Network; Mobile radio =
          &nb= sp;    interface Layer 3 specification; Core network =
          &nb= sp;    protocols; Stage 3 (release 5), 3GPP TS 24.008 =
          &nb= sp;    v 5.10.0, 2003-12
          &nb= sp;    
End of change.
Cheers,
Chris.
Shasta Wireless Development
Nortel Networks
Telephone:
+1 972 684 3281
ESN 444 3281

This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

------_=_NextPart_001_01C3FC6B.47B4EAC8-- From owner-aaa-wg@merit.edu Thu Feb 26 08:33:51 2004 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 IAA11463 for ; Thu, 26 Feb 2004 08:33:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E203091212; Thu, 26 Feb 2004 08:32:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9C1A912C0; Thu, 26 Feb 2004 08:32: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 2FF0E91212 for ; Thu, 26 Feb 2004 08:31:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54C865E831; Thu, 26 Feb 2004 08:31: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 272245E80E for ; Thu, 26 Feb 2004 08:31:57 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QDVuYG008904 for ; Thu, 26 Feb 2004 14:31:56 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:31:55 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 14:32:14 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Christopher Richards'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 14:31:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Feb 2004 13:31:55.0959 (UTC) FILETIME=[E70D6C70:01C3FC6C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, I agree, IMEI, NSAPI and lots of other information elements might be interesting to the prepaid system or some other boxes behind it but as you say, they are attributes of the session. They are not different ways to identify the subscription. We should not mix these things. Since different services will have different interesting attributes to provide to the server we should not try to standardize all of them in DCC, and not even subset of them, because it would be extremely difficult to decide the scope of the subset. IMEI might be important to 3GPP world but maybe not for the rest of the world. Therefore the section 4.1 specifies that each service should specify their rating input (I regard IMEI as one kind of rating input in this case) in their service specific documents. The notation *AVP in the CCR command gives the flexibility to add new service related AVPs in the command without the need of updating the DCC application every time someone wants to transfer a new attribute from the client to the server. BR, Leena -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 26. helmikuuta 2004 15:20 To: Leena Mattila (TU/LMF); 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Leena, Thanks for your comments. A subscriber can use a different device to access a network (Just as a different MSISDN can be used). For example, take their SIM out of the handheld device and insert it into a PC. Therefore it is an attribute of the session. The information is very relevant to a subscribers session usage: it can be used to determine what kind of services the subscriber is capable of receiving for that session - over and above the QoS sent for that session. I.e. is the device capable of receiving streaming video, how big is the display, what application software (and versions of the software) can it run, etc, etc. Let me know if there a better AVP to put this information into? Best Regards, Chris. -----Original Message----- From: Leena Mattila (TU/LMF) [mailto:leena.mattila@ericsson.com] Sent: Thursday, February 26, 2004 7:04 AM To: 'aaa-wg@merit.edu' Subject: FW: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Chris, as far as I understand IMEI identifies the equipment (e.g. the phone), not the subscriber using it. Therefore I don't think IMEI should be regarded as one type of subscription. I doubt whether any prepaid subscription is based on the identity of the equipment. BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Thu Feb 26 08:42:12 2004 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 IAA12665 for ; Thu, 26 Feb 2004 08:42:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABC3691213; Thu, 26 Feb 2004 08:41:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7181F912C0; Thu, 26 Feb 2004 08:41:58 -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 AAD9C91213 for ; Thu, 26 Feb 2004 08:41:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 89C795E7B3; Thu, 26 Feb 2004 08:41:56 -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 A05D65E894 for ; Thu, 26 Feb 2004 08:41:55 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QDfsf01545; Thu, 26 Feb 2004 15:41:54 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 15:39:45 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i1QDdjEP006586; Thu, 26 Feb 2004 15:39:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00zKILug; Thu, 26 Feb 2004 15:39:44 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QDdi710370; Thu, 26 Feb 2004 15:39:44 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 15:39:42 +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_01C3FC6D.FCAA9F4A" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 15:39:41 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C84CA@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8Z1MQN1n825wRQyyDFrOyDdxrMAABfpPA From: To: Cc: X-OriginalArrivalTime: 26 Feb 2004 13:39:42.0827 (UTC) FILETIME=[FD53D3B0:01C3FC6D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC6D.FCAA9F4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 I don't have a strong opinion for or against your proposal, just seems = a bit 3GPP/GPRS specific. =20 If those are really needed in 3GPP, would it be possible that you carry = these attributes in a 3GPP=20 vendor specific AVPs possibly defined in 3GPP as *AVP? =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 26 February, 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue=20 A number of wireless specific subscription identifiers are currently = specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is = defined, but the is no way to send the NSAPI identifier used by the = (sub-)session. Submitter name: Chris Richards=20 Submitter email address: crich@nortelnetworks.com=20 Date first submitted: 19 Feb 2004=20 Reference:=20 Document: Diameter Credit Control=20 Comment type: T=20 Priority: 1=20 Section: 8.36=20 Rationale/Explanation of issue:=20 The End user IMSI and MSISDN subscription identifiers have been defined. = However, the IMEISV (International Mobile Equipment Idnentity and = Software Version) has been omitted. In addition, the IMSI is defined, = but the is no way to send the NSAPI identifier used by the = (sub-)session. Requested change:=20 Section 8.46, description of END_USER_IMSI=20 FROM;=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. =20 =20 TO:=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. In addition, the NSAPI identifier SHOULD be included = in the final (spare) nibble of the IMSI. The NSAPI is defined = in 3GPP TS 24.008 [3GPPNSAPI].=20 =20 Section 8.46=20 Addition of:=20 =20 END_USER_IMEISV 5 =20 The identifier is in international IMEISV format, according=20 to the ITU-T E.212 numbering plan as defined in 3GPP 23.003=20 [3GPPIMEI]. =20 Section 12.16=20 FROM:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-4. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 TO:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-5. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 Section 15.1=20 Addition of:=20 [3GPPIMEI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network, Numbering, addressing=20 and identification, (release 5), 3GPP TS 23.003=20 v. 5.8.0, 2003-012 =20 [3GPPNSAPI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network; Mobile radio=20 interface Layer 3 specification; Core network=20 protocols; Stage 3 (release 5), 3GPP TS 24.008=20 v 5.10.0, 2003-12=20 =20 End of change.=20 Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 ------_=_NextPart_001_01C3FC6D.FCAA9F4A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DCC: Inclusion of IMEI in Subscription-Id-Type AVP
Hi=20 Chris,
 
I=20 don't have a strong opinion for or against your proposal,  = just seems=20 a bit 3GPP/GPRS specific.
 
If=20 those are really needed in 3GPP, would it be possible that you carry = these=20 attributes in a 3GPP
vendor=20 specific AVPs possibly defined in 3GPP as = *AVP?
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher=20 Richards
Sent: 26 February, 2004 14:49
To:=20 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI = in=20 Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription = identifiers are=20 currently specified (MSISDN, IMSI) but not the IMEISV. In addition, = the IMSI=20 is defined, but the is no way to send the NSAPI identifier used by the = (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com =
Date first submitted: 19 Feb 2004
Reference:=20
Document: Diameter Credit Control =
Comment type: T
Priority: 1 =
Section: 8.36
Rationale/Explanation = of=20 issue:
The End user IMSI and MSISDN = subscription=20 identifiers have been defined. However, the IMEISV (International = Mobile=20 Equipment Idnentity and Software Version) has been omitted. In = addition, the=20 IMSI is defined, but the is no way to send the NSAPI identifier used = by the=20 (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI =
FROM;

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
           = The=20 identifier is in international IMSI format, according to =20
           = the ITU-T=20 E.212 numbering plan as defined in [E121] and 
          =20 [CE121]. 
          &nbs= p; =20
TO:

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
           = The=20 identifier is in international IMSI format, according to =20
           = the ITU-T=20 E.212 numbering plan as defined in [E121] and 
           = [CE121].=20 In addition, the NSAPI identifier SHOULD be included
           = in the=20 final (spare) nibble of the IMSI. The NSAPI is defined =
           = in 3GPP TS=20 24.008 [3GPPNSAPI].
          &nbs= p; =20
Section 8.46
Addition=20 of:
          &nbs= p; =20
      =20 = END_USER_IMEISV         &nbs= p;            = ;            =          =20 5  
           = The=20 identifier is in international IMEISV format, according =
           = to the=20 ITU-T E.212 numbering plan as defined in 3GPP 23.003
          =20 [3GPPIMEI].     

Section 12.16
FROM: =

12.16 Subscription-Id-Type AVP  =
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP=20 (AVP Code
   450) defines the = values 0-4.=20 All remaining values are available for
  =20 assignment via Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP  =
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP=20 (AVP Code
   450) defines the = values 0-5.=20 All remaining values are available for
  =20 assignment via Designated Expert [IANA]. 
   
Section = 15.1=20
Addition of:

   [3GPPIMEI]  3rd Generation = Partnership=20 Project; Technical
          &nbs= p;   =20 Specification Group Core Network, Numbering, addressing =
          &nbs= p;   =20 and identification, (release 5), 3GPP TS 23.003
          &nbs= p;   =20 v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership = Project;=20 Technical
          &nbs= p;   =20 Specification Group Core Network; Mobile radio
          &nbs= p;   =20 interface Layer 3 specification; Core network
          &nbs= p;   =20 protocols; Stage 3 (release 5), 3GPP TS 24.008
          &nbs= p;   =20 v 5.10.0, 2003-12
          &nbs= p;    =20
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel=20 Networks

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

------_=_NextPart_001_01C3FC6D.FCAA9F4A-- From owner-aaa-wg@merit.edu Thu Feb 26 09:06:16 2004 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 IAA10831 for ; Thu, 26 Feb 2004 08:20:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C098A912BD; Thu, 26 Feb 2004 08:20:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90330912BC; Thu, 26 Feb 2004 08:20: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 F06DA912BD for ; Thu, 26 Feb 2004 08:20:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C1AF5E827; Thu, 26 Feb 2004 08:20:12 -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 3EDD95E88A for ; Thu, 26 Feb 2004 08:20:08 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QDK4qY027097 for ; Thu, 26 Feb 2004 14:20:07 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:20:03 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 14:20:22 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 14:19:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC6B.36E2A45C" X-OriginalArrivalTime: 26 Feb 2004 13:20:03.0993 (UTC) FILETIME=[3EB00890:01C3FC6B] 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_01C3FC6B.36E2A45C Content-Type: text/plain; charset="iso-8859-1" Hi Christopher, I am not familiar with NSAPI. But according to the TS24.008 the purpose of the network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3. How is NSAPI connected to the user's prepaid subscription? Regards............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FC6B.36E2A45C Content-Type: text/html; charset="iso-8859-1" DCC: Inclusion of IMEI in Subscription-Id-Type AVP
Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of the
network service access point identifier information element is to identify the service
access point that is used for the GPRS data transfer at layer 3.
 
How is NSAPI connected to the user's prepaid subscription?
 
Regards............Harri
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. 
            
TO:

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. In addition, the NSAPI identifier SHOULD be included
           in the final (spare) nibble of the IMSI. The NSAPI is defined
           in 3GPP TS 24.008 [3GPPNSAPI].
            
Section 8.46
Addition of:
            
       END_USER_IMEISV                                            5  
           The identifier is in international IMEISV format, according
           to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 5), 3GPP TS 23.003
               v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership Project; Technical
               Specification Group Core Network; Mobile radio
               interface Layer 3 specification; Core network
               protocols; Stage 3 (release 5), 3GPP TS 24.008
               v 5.10.0, 2003-12
               
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3FC6B.36E2A45C-- From owner-aaa-wg@merit.edu Thu Feb 26 09:24:15 2004 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 JAA14859 for ; Thu, 26 Feb 2004 09:24:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FF43912C2; Thu, 26 Feb 2004 09:24:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 632B1912C3; Thu, 26 Feb 2004 09:24:01 -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 B7B90912C2 for ; Thu, 26 Feb 2004 09:23:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id A30355E8AE; Thu, 26 Feb 2004 09:23:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 101655E80E for ; Thu, 26 Feb 2004 09:23:59 -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 i1QENsJ03223; Thu, 26 Feb 2004 06:23:54 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 08:23:55 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD51E@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 08:23:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC74.28EF4A44" 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_01C3FC74.28EF4A44 Content-Type: text/plain Hi Harri, In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved: (1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters. (2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels. Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle. Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts. As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Christopher, I am not familiar with NSAPI. But according to the TS24.008 the purpose of the network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3. How is NSAPI connected to the user's prepaid subscription? Regards............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FC74.28EF4A44 Content-Type: text/html Message
Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved:
 
(1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters.
(2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels.
 
Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle.
 
Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts.
 
As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of the
network service access point identifier information element is to identify the service
access point that is used for the GPRS data transfer at layer 3.
 
How is NSAPI connected to the user's prepaid subscription?
 
Regards............Harri
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. 
            
TO:

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. In addition, the NSAPI identifier SHOULD be included
           in the final (spare) nibble of the IMSI. The NSAPI is defined
           in 3GPP TS 24.008 [3GPPNSAPI].
            
Section 8.46
Addition of:
            
       END_USER_IMEISV                                            5  
           The identifier is in international IMEISV format, according
           to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 5), 3GPP TS 23.003
               v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership Project; Technical
               Specification Group Core Network; Mobile radio
               interface Layer 3 specification; Core network
               protocols; Stage 3 (release 5), 3GPP TS 24.008
               v 5.10.0, 2003-12
               
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3FC74.28EF4A44-- From owner-aaa-wg@merit.edu Thu Feb 26 09:37:51 2004 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 JAA15666 for ; Thu, 26 Feb 2004 09:37:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B594912C3; Thu, 26 Feb 2004 09:37:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AC42912C5; Thu, 26 Feb 2004 09:37:38 -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 A91F3912C3 for ; Thu, 26 Feb 2004 09:37:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9613B5E85F; Thu, 26 Feb 2004 09:37:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (unknown [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 184985E8B7 for ; Thu, 26 Feb 2004 09:37:36 -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 i1QEbVJ04479; Thu, 26 Feb 2004 06:37:31 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 08:37:32 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD51F@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 08:37:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC76.0FD485F4" 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_01C3FC76.0FD485F4 Content-Type: text/plain Hi Marco, I agree that this is 3GPP specific: but since DCC already specifies a number of other 3G/GPRS specific fields natively, it seemed to make sense to complete the IMSI with the NSAPI and add IMEISV. As you say, for the IMEISV, if it is not added in DCC, it will need to be added in 3GPP. That's not a problem. I thought I would save the time and do it in the source document. I think the NSAPI should be included sine the IMSI part is already present. 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, February 26, 2004 7:40 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Chris, I don't have a strong opinion for or against your proposal, just seems a bit 3GPP/GPRS specific. If those are really needed in 3GPP, would it be possible that you carry these attributes in a 3GPP vendor specific AVPs possibly defined in 3GPP as *AVP? Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 26 February, 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 ------_=_NextPart_001_01C3FC76.0FD485F4 Content-Type: text/html Message
Hi Marco,
 
I agree that this is 3GPP specific: but since DCC already specifies a number of other 3G/GPRS specific fields natively, it seemed to make sense to complete the IMSI with the NSAPI and add IMEISV.
 
As you say, for the IMEISV, if it is not added in DCC, it will need to be added in 3GPP. That's not a problem. I thought I would save the time and do it in the source document.
 
I think the NSAPI should be included sine the IMSI part is already present.

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, February 26, 2004 7:40 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Chris,
 
I don't have a strong opinion for or against your proposal,  just seems a bit 3GPP/GPRS specific.
 
If those are really needed in 3GPP, would it be possible that you carry these attributes in a 3GPP
vendor specific AVPs possibly defined in 3GPP as *AVP?
 
Regards
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. 
            
TO:

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. In addition, the NSAPI identifier SHOULD be included
           in the final (spare) nibble of the IMSI. The NSAPI is defined
           in 3GPP TS 24.008 [3GPPNSAPI].
            
Section 8.46
Addition of:
            
       END_USER_IMEISV                                            5  
           The identifier is in international IMEISV format, according
           to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 5), 3GPP TS 23.003
               v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership Project; Technical
               Specification Group Core Network; Mobile radio
               interface Layer 3 specification; Core network
               protocols; Stage 3 (release 5), 3GPP TS 24.008
               v 5.10.0, 2003-12
               
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

------_=_NextPart_001_01C3FC76.0FD485F4-- From owner-aaa-wg@merit.edu Thu Feb 26 10:05:03 2004 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 KAA17621 for ; Thu, 26 Feb 2004 10:05:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1D75912C7; Thu, 26 Feb 2004 10:04:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 813A1912CA; Thu, 26 Feb 2004 10:04:46 -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 65D27912C7 for ; Thu, 26 Feb 2004 10:04:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDD145E8FF; Thu, 26 Feb 2004 10:04:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id D44D15E904 for ; Thu, 26 Feb 2004 10:04:07 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QF46t11767; Thu, 26 Feb 2004 17:04:06 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 17:02:49 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i1QF2nGM014349; Thu, 26 Feb 2004 17:02:49 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00BWU4xq; Thu, 26 Feb 2004 17:02:48 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QF2l711015; Thu, 26 Feb 2004 17:02:47 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 17:02:47 +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_01C3FC79.9823B9E0" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 17:02:47 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0482@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8dj2I4VRe6IU4T2i6os+J5ofnrgAAYSYw From: To: Cc: X-OriginalArrivalTime: 26 Feb 2004 15:02:47.0522 (UTC) FILETIME=[986FEC20:01C3FC79] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC79.9823B9E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 the reason why we included the IMSI is because a prepaid subsciption may = be identified with the IMSI, and yes this is 3GPP specific. However, you may insert your smart card in your PC (e.g. = with a PCMCIA card) and still be identified with the IMSI. =20 The NSAPI is really GPRS specific and dynamically allocated on a per PDP = Context basis, it make sense only in GPRS networks and is actually not adding any value to the IMSI information at the = purpose to identify the prepaid subscription. What is the=20 actual reason why you want to include the NSAPI, to identify a PDP = Context?=20 =20 Cheers Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 26 February, 2004 16:38 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi Marco, =20 I agree that this is 3GPP specific: but since DCC already specifies a = number of other 3G/GPRS specific fields natively, it seemed to make = sense to complete the IMSI with the NSAPI and add IMEISV. =20 As you say, for the IMEISV, if it is not added in DCC, it will need to = be added in 3GPP. That's not a problem. I thought I would save the time = and do it in the source document. =20 I think the NSAPI should be included sine the IMSI part is already = present.=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----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Thursday, February 26, 2004 7:40 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi Chris, =20 I don't have a strong opinion for or against your proposal, just seems = a bit 3GPP/GPRS specific. =20 If those are really needed in 3GPP, would it be possible that you carry = these attributes in a 3GPP=20 vendor specific AVPs possibly defined in 3GPP as *AVP? =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 26 February, 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue=20 A number of wireless specific subscription identifiers are currently = specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is = defined, but the is no way to send the NSAPI identifier used by the = (sub-)session. Submitter name: Chris Richards=20 Submitter email address: crich@nortelnetworks.com=20 Date first submitted: 19 Feb 2004=20 Reference:=20 Document: Diameter Credit Control=20 Comment type: T=20 Priority: 1=20 Section: 8.36=20 Rationale/Explanation of issue:=20 The End user IMSI and MSISDN subscription identifiers have been defined. = However, the IMEISV (International Mobile Equipment Idnentity and = Software Version) has been omitted. In addition, the IMSI is defined, = but the is no way to send the NSAPI identifier used by the = (sub-)session. Requested change:=20 Section 8.46, description of END_USER_IMSI=20 FROM;=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. =20 =20 TO:=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. In addition, the NSAPI identifier SHOULD be included = in the final (spare) nibble of the IMSI. The NSAPI is defined = in 3GPP TS 24.008 [3GPPNSAPI].=20 =20 Section 8.46=20 Addition of:=20 =20 END_USER_IMEISV 5 =20 The identifier is in international IMEISV format, according=20 to the ITU-T E.212 numbering plan as defined in 3GPP 23.003=20 [3GPPIMEI]. =20 Section 12.16=20 FROM:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-4. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 TO:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-5. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 Section 15.1=20 Addition of:=20 [3GPPIMEI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network, Numbering, addressing=20 and identification, (release 5), 3GPP TS 23.003=20 v. 5.8.0, 2003-012 =20 [3GPPNSAPI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network; Mobile radio=20 interface Layer 3 specification; Core network=20 protocols; Stage 3 (release 5), 3GPP TS 24.008=20 v 5.10.0, 2003-12=20 =20 End of change.=20 Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 ------_=_NextPart_001_01C3FC79.9823B9E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Chris,
 
the=20 reason why we included the IMSI is because a prepaid subsciption may be=20 identified with the IMSI, and yes this is
3GPP=20 specific. However, you may insert your smart card in your PC (e.g. with = a PCMCIA=20 card) and still be identified with the
IMSI.
 
The=20 NSAPI is really GPRS specific and dynamically allocated on a per PDP = Context=20 basis, it make sense only in GPRS networks
and is=20 actually not adding any value to the IMSI information at the = purpose to=20 identify the prepaid subscription. = What is the=20
actual=20 reason why you want to include the NSAPI, to identify a = PDP Context?=20
 
Cheers
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 26 February, 2004=20 16:38
To: Stura Marco (Nokia-NET/Helsinki)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Inclusion of = IMEI in=20 Subscription-Id-Type AVP

Hi=20 Marco,
 
I=20 agree that this is 3GPP specific: but since DCC already specifies a = number of=20 other 3G/GPRS specific fields natively, it seemed to make = sense to=20 complete the IMSI with the NSAPI and add IMEISV.
 
As=20 you say, for the IMEISV, if it is not added in DCC, it will need to be = added=20 in 3GPP. That's not a problem. I thought I would save the time and do = it in=20 the source document.
 
I=20 think the NSAPI should be included sine the IMSI part is already = present.=20

Cheers,
Chris.

Shasta Wireless = Development=20
Nortel Networks

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

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Thursday, February 26, 2004 7:40 AM
To: Richards, = Christopher=20 [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: = RE:=20 [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type=20 AVP

Hi=20 Chris,
 
I=20 don't have a strong opinion for or against your proposal,  = just=20 seems a bit 3GPP/GPRS specific.
 
If=20 those are really needed in 3GPP, would it be possible that you carry = these=20 attributes in a 3GPP
vendor specific AVPs possibly defined=20 in 3GPP as *AVP?
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher = Richards
Sent: 26 February, 2004 14:49
To:=20 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of = IMEI in=20 Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription = identifiers are=20 currently specified (MSISDN, IMSI) but not the IMEISV. In = addition, the=20 IMSI is defined, but the is no way to send the NSAPI identifier = used by=20 the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com =
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter = Credit=20 Control
Comment type: T
Priority: 1
Section: = 8.36
Rationale/Explanation of issue:
The End=20 user IMSI and MSISDN subscription identifiers have been defined. = However,=20 the IMEISV (International Mobile Equipment Idnentity and Software = Version)=20 has been omitted. In addition, the IMSI is defined, but the is no = way to=20 send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of = END_USER_IMSI=20
FROM;

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
           = The=20 identifier is in international IMSI format, according to =20
           = the=20 ITU-T E.212 numbering plan as defined in [E121] and  =
          =20 [CE121]. 
          &nbs= p; =20
TO:

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
           = The=20 identifier is in international IMSI format, according to =20
           = the=20 ITU-T E.212 numbering plan as defined in [E121] and  =
          =20 [CE121]. In addition, the NSAPI identifier SHOULD be = included=20
           in = the=20 final (spare) nibble of the IMSI. The NSAPI is defined =
           in = 3GPP TS 24.008 [3GPPNSAPI].
          &nbs= p; =20
Section 8.46
Addition=20 of:
          &nbs= p; =20
      =20 = END_USER_IMEISV         &nbs= p;            = ;            =          =20 5  
           = The=20 identifier is in international IMEISV format, according =
           to = the=20 ITU-T E.212 numbering plan as defined in 3GPP 23.003 =
          =20 [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP  =
        =
   As defined in Section 8.46, the = Subscription-Id-Type=20 AVP (AVP Code
   450) defines = the values=20 0-4. All remaining values are available for
   assignment via Designated Expert = [IANA]. =20
   
TO:

12.16 Subscription-Id-Type AVP  =
        =
   As defined in Section 8.46, the = Subscription-Id-Type=20 AVP (AVP Code
   450) defines = the values=20 0-5. All remaining values are available for
   assignment via Designated Expert = [IANA]. =20
   
Section=20 15.1
Addition of:

   [3GPPIMEI]  3rd Generation = Partnership=20 Project; Technical
          &nbs= p;   =20 Specification Group Core Network, Numbering, addressing =
          &nbs= p;   =20 and identification, (release 5), 3GPP TS 23.003
          &nbs= p;   =20 v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation = Partnership=20 Project; Technical
          &nbs= p;   =20 Specification Group Core Network; Mobile radio
          &nbs= p;   =20 interface Layer 3 specification; Core network
          &nbs= p;   =20 protocols; Stage 3 (release 5), 3GPP TS 24.008
          &nbs= p;   =20 v 5.10.0, 2003-12
          &nbs= p;    =20
End of change.

Cheers,
Chris. =

Shasta Wireless Development
Nortel=20 Networks

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

------_=_NextPart_001_01C3FC79.9823B9E0-- From owner-aaa-wg@merit.edu Thu Feb 26 10:40:14 2004 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 KAA20518 for ; Thu, 26 Feb 2004 10:40:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78488912CE; Thu, 26 Feb 2004 10:39:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45A43912CF; Thu, 26 Feb 2004 10:39:57 -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 79659912CE for ; Thu, 26 Feb 2004 10:39:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C3DA5E8E0; Thu, 26 Feb 2004 10:39:55 -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 7CF715E86E for ; Thu, 26 Feb 2004 10:39:54 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QFdrYG006311 for ; Thu, 26 Feb 2004 16:39:53 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 16:39:53 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 16:40:12 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 16:39:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC7E.5292B6A6" X-OriginalArrivalTime: 26 Feb 2004 15:39:53.0260 (UTC) FILETIME=[C71496C0:01C3FC7E] 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_01C3FC7E.5292B6A6 Content-Type: text/plain; charset="iso-8859-1" Hi Christopher, Thank your for your clarification how to use NSAPI in case of GPRS. Still I think that we should not connect NSAPI to IMSI and use this application specific (GPRS) combination to identify end user's subscription in prepaid system. As specified in ITU-T E.212 the IMSI is composed of a three digit Mobile Country Code (MCC), a two or three digit Mobile Network Code (MNC) and a not more than 10 digit Mobile Subscriber Identification Number (MSIN). In other words, the IMSI is a string of not more than 15 digits. I think that we should stick to the IMSI format as it is defined in E.212 to identify prepaid subscription. Regards..............Harri -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 26. helmikuuta 2004 16:24 To: Harri Hakala (TU/LMF); 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Harri, In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved: (1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters. (2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels. Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle. Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts. As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Christopher, I am not familiar with NSAPI. But according to the TS24.008 the purpose of the network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3. How is NSAPI connected to the user's prepaid subscription? Regards............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FC7E.5292B6A6 Content-Type: text/html; charset="iso-8859-1" Message
Hi Christopher,
 
Thank your for your clarification how to use NSAPI in case of GPRS.
 
Still I think that we should not connect NSAPI to IMSI and use this application specific (GPRS)
combination to identify end user's subscription in prepaid system. As specified in ITU-T E.212 the IMSI
is composed of a  three digit Mobile Country Code (MCC), a two or three digit Mobile Network
Code (MNC) and a not more than 10 digit Mobile Subscriber Identification Number (MSIN). In other
words, the IMSI is a string of not more than 15 digits. I think that we should stick to the IMSI format
as it is defined in E.212 to identify prepaid subscription.
 
Regards..............Harri
-----Original Message-----
From: Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 26. helmikuuta 2004 16:24
To: Harri Hakala (TU/LMF); 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved:
 
(1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters.
(2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels.
 
Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle.
 
Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts.
 
As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of the
network service access point identifier information element is to identify the service
access point that is used for the GPRS data transfer at layer 3.
 
How is NSAPI connected to the user's prepaid subscription?
 
Regards............Harri
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. 
            
TO:

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. In addition, the NSAPI identifier SHOULD be included
           in the final (spare) nibble of the IMSI. The NSAPI is defined
           in 3GPP TS 24.008 [3GPPNSAPI].
            
Section 8.46
Addition of:
            
       END_USER_IMEISV                                            5  
           The identifier is in international IMEISV format, according
           to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 5), 3GPP TS 23.003
               v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership Project; Technical
               Specification Group Core Network; Mobile radio
               interface Layer 3 specification; Core network
               protocols; Stage 3 (release 5), 3GPP TS 24.008
               v 5.10.0, 2003-12
               
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3FC7E.5292B6A6-- From owner-aaa-wg@merit.edu Thu Feb 26 10:44:04 2004 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 KAA20766 for ; Thu, 26 Feb 2004 10:44:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB1FB912CF; Thu, 26 Feb 2004 10:43:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C53C912D0; Thu, 26 Feb 2004 10:43:48 -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 626A6912CF for ; Thu, 26 Feb 2004 10:43:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4BA1F5E86E; Thu, 26 Feb 2004 10:43:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id D97215E8EF for ; Thu, 26 Feb 2004 10:43:44 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QFhgt16547; Thu, 26 Feb 2004 17:43:42 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 17:43:21 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1QFhLqt024702; Thu, 26 Feb 2004 17:43:21 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00U2Qy1r; Thu, 26 Feb 2004 17:43:20 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QFhJ708346; Thu, 26 Feb 2004 17:43:19 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 17:43:19 +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_01C3FC7F.41E21850" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 17:43:19 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0483@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8emH0XkjN1lIpSk+eHsDQeKhWfQAA4JHg From: To: , , X-OriginalArrivalTime: 26 Feb 2004 15:43:19.0612 (UTC) FILETIME=[421367C0:01C3FC7F] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC7F.41E21850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >As far as I know, the only guaranteed way to tell one from the other or = even to determine what subscription a particular context is, is by using = the NSAPI. =20 Chris, the NSAPI is dynamically selected by the terminal when the PDP = Conetxt is activated. I doubt you can link a subscription to some = parameter that is dynamically selected by the terminal i.e. that you don't know = beforehand. Actually the NSAPI it self it dosn't even tell that this is = a secondary PDP Context, what tell it is the linked NSAPI. =20 I have still concerns on the usability of the NSAPI to identify a = specific prepaid subscription.=20 =20 Cheers Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 26 February, 2004 16:24 To: 'Harri Hakala (TU/LMF)'; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi Harri, =20 In 3G, a user can open multiple PDP contexts (sessions). They all are = connected in that they all belong to a single login session (Single AAA = Authenticated session). They all belong to the same IMSI, share the same = end user IP address. However, they are otherwise independent of each = other. There are two ways that this is achieved: =20 (1) Through the use of Secondary PDP contexts: They differ in that they = are intended to be used for different services - as defined by each = potentially having different QoS levels and providing different 5 tuple = filters. (2) Through the use of multiple primary PDP contexts. In which case, = they have no 5 tuple filters. They may (or may not) have different QoS = levels. =20 Each of these PDP contexts are identified by this NSAPI value then. Each = using a unique value within the bundle. =20 Operators can assign different subscriptions to the different contexts. = Some subscribers may not even be permitted to use secondary or multiple = contexts. =20 As far as I know, the only guaranteed way to tell one from the other or = even to determine what subscription a particular context is, is by using = the NSAPI. Best Regards,=20 Chris.=20 -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]=20 Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi Christopher, =20 I am not familiar with NSAPI. But according to the TS24.008 the purpose = of the=20 network service access point identifier information element is to = identify the service access point that is used for the GPRS data transfer at layer 3.=20 =20 How is NSAPI connected to the user's prepaid subscription? =20 Regards............Harri =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue=20 A number of wireless specific subscription identifiers are currently = specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is = defined, but the is no way to send the NSAPI identifier used by the = (sub-)session. Submitter name: Chris Richards=20 Submitter email address: crich@nortelnetworks.com=20 Date first submitted: 19 Feb 2004=20 Reference:=20 Document: Diameter Credit Control=20 Comment type: T=20 Priority: 1=20 Section: 8.36=20 Rationale/Explanation of issue:=20 The End user IMSI and MSISDN subscription identifiers have been defined. = However, the IMEISV (International Mobile Equipment Idnentity and = Software Version) has been omitted. In addition, the IMSI is defined, = but the is no way to send the NSAPI identifier used by the = (sub-)session. Requested change:=20 Section 8.46, description of END_USER_IMSI=20 FROM;=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. =20 =20 TO:=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. In addition, the NSAPI identifier SHOULD be included = in the final (spare) nibble of the IMSI. The NSAPI is defined = in 3GPP TS 24.008 [3GPPNSAPI].=20 =20 Section 8.46=20 Addition of:=20 =20 END_USER_IMEISV 5 =20 The identifier is in international IMEISV format, according=20 to the ITU-T E.212 numbering plan as defined in 3GPP 23.003=20 [3GPPIMEI]. =20 Section 12.16=20 FROM:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-4. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 TO:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-5. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 Section 15.1=20 Addition of:=20 [3GPPIMEI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network, Numbering, addressing=20 and identification, (release 5), 3GPP TS 23.003=20 v. 5.8.0, 2003-012 =20 [3GPPNSAPI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network; Mobile radio=20 interface Layer 3 specification; Core network=20 protocols; Stage 3 (release 5), 3GPP TS 24.008=20 v 5.10.0, 2003-12=20 =20 End of change.=20 Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. ------_=_NextPart_001_01C3FC7F.41E21850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
>As far as I know, = the only=20 guaranteed way to tell one from the other or even to determine what = subscription=20 a particular context is, is by using the=20 NSAPI.
 
Chris, the NSAPI is dynamically selected by = the=20 terminal when the PDP Conetxt is activated. I doubt you can link a = subscription=20 to some parameter
that is dynamically selected by the terminal = i.e. that=20 you don't know beforehand. Actually the NSAPI it self it dosn't even = tell that=20 this is a secondary
PDP Context, what tell it is the linked=20 NSAPI.
 
I have still concerns on the usability = of the=20 NSAPI to identify a specific prepaid=20 subscription. 
 
Cheers
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher=20 Richards
Sent: 26 February, 2004 16:24
To: 'Harri = Hakala=20 (TU/LMF)'; 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: = Inclusion=20 of IMEI in Subscription-Id-Type AVP

Hi=20 Harri,
 
In=20 3G, a user can open multiple PDP contexts (sessions). They all are = connected=20 in that they all belong to a single login session (Single AAA = Authenticated=20 session). They all belong to the same IMSI, share the same end user IP = address. However, they are otherwise independent of each other. There = are two=20 ways that this is achieved:
 
(1)=20 Through the use of Secondary PDP contexts: They differ in that they = are=20 intended to be used for different services - as defined by each = potentially=20 having different QoS levels and providing different 5 tuple=20 filters.
(2)=20 Through the use of multiple primary PDP contexts. In which case,=20 they have no 5 tuple filters. They may (or may not) have = different QoS=20 levels.
 
Each=20 of these PDP contexts are identified by this NSAPI value then. Each = using a=20 unique value within the bundle.
 
Operators can assign different subscriptions to the different = contexts.=20 Some subscribers may not even be permitted to use secondary or = multiple=20 contexts.
 
As=20 far as I know, the only guaranteed way to tell one from the other or = even to=20 determine what subscription a particular context is, is by using the=20 NSAPI.

Best=20 Regards,
Chris.

-----Original Message-----
From: = Harri Hakala=20 (TU/LMF) [mailto:harri.hakala@ericsson.com]
Sent: = Thursday,=20 February 26, 2004 7:20 AM
To: Richards, Christopher=20 [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu'
Subject: RE: = [AAA-WG]: DCC:=20 Inclusion of IMEI in Subscription-Id-Type AVP

Hi=20 Christopher,
 
I am not familiar with NSAPI. But = according to the=20 TS24.008 the=20 purpose of the
network=20 service access point identifier information element is to = identify the=20 service
access point that is used for the GPRS = data=20 transfer at layer 3.
 
How is NSAPI connected to the user's = prepaid = subscription?
 
Regards............Harri<= /FONT>
 
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher=20 Richards
Sent: 26. helmikuuta 2004 14:49
To:=20 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of = IMEI in=20 Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription = identifiers are=20 currently specified (MSISDN, IMSI) but not the IMEISV. In = addition, the=20 IMSI is defined, but the is no way to send the NSAPI identifier = used by=20 the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com =
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter = Credit=20 Control
Comment type: T
Priority: 1
Section: = 8.36
Rationale/Explanation of issue:
The End=20 user IMSI and MSISDN subscription identifiers have been defined. = However,=20 the IMEISV (International Mobile Equipment Idnentity and Software = Version)=20 has been omitted. In addition, the IMSI is defined, but the is no = way to=20 send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of = END_USER_IMSI=20
FROM;

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
           = The=20 identifier is in international IMSI format, according to =20
           = the=20 ITU-T E.212 numbering plan as defined in [E121] and  =
          =20 [CE121]. 
          &nbs= p; =20
TO:

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
           = The=20 identifier is in international IMSI format, according to =20
           = the=20 ITU-T E.212 numbering plan as defined in [E121] and  =
          =20 [CE121]. In addition, the NSAPI identifier SHOULD be = included=20
           in = the=20 final (spare) nibble of the IMSI. The NSAPI is defined =
           in = 3GPP TS 24.008 [3GPPNSAPI].
          &nbs= p; =20
Section 8.46
Addition=20 of:
          &nbs= p; =20
      =20 = END_USER_IMEISV         &nbs= p;            = ;            =          =20 5  
           = The=20 identifier is in international IMEISV format, according =
           to = the=20 ITU-T E.212 numbering plan as defined in 3GPP 23.003 =
          =20 [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP  =
        =
   As defined in Section 8.46, the = Subscription-Id-Type=20 AVP (AVP Code
   450) defines = the values=20 0-4. All remaining values are available for
   assignment via Designated Expert = [IANA]. =20
   
TO:

12.16 Subscription-Id-Type AVP  =
        =
   As defined in Section 8.46, the = Subscription-Id-Type=20 AVP (AVP Code
   450) defines = the values=20 0-5. All remaining values are available for
   assignment via Designated Expert = [IANA]. =20
   
Section=20 15.1
Addition of:

   [3GPPIMEI]  3rd Generation = Partnership=20 Project; Technical
          &nbs= p;   =20 Specification Group Core Network, Numbering, addressing =
          &nbs= p;   =20 and identification, (release 5), 3GPP TS 23.003
          &nbs= p;   =20 v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation = Partnership=20 Project; Technical
          &nbs= p;   =20 Specification Group Core Network; Mobile radio
          &nbs= p;   =20 interface Layer 3 specification; Core network
          &nbs= p;   =20 protocols; Stage 3 (release 5), 3GPP TS 24.008
          &nbs= p;   =20 v 5.10.0, 2003-12
          &nbs= p;    =20
End of change.

Cheers,
Chris. =

Shasta Wireless Development
Nortel=20 Networks

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


This = communication=20 is confidential and intended solely for the addressee(s). Any = unauthorized=20 review, use, disclosure or distribution is prohibited. If you = believe this=20 message has been sent to you in error, please notify the sender by = replying=20 to this transmission and delete the message without disclosing it. = Thank=20 you.

E-mail including attachments is susceptible to data = corruption,=20 interruption, unauthorized amendment, tampering and viruses, and we = only=20 send and receive e-mails on the basis that we are not liable for any = such=20 corruption, interception, amendment, tampering or viruses or any=20 consequences thereof.
------_=_NextPart_001_01C3FC7F.41E21850-- From owner-aaa-wg@merit.edu Thu Feb 26 11:35:25 2004 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 LAA23255 for ; Thu, 26 Feb 2004 11:35:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C768912D0; Thu, 26 Feb 2004 11:35:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7E63912D1; Thu, 26 Feb 2004 11:35: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 1B4A0912D0 for ; Thu, 26 Feb 2004 11:35:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id D6DCA5E86B; Thu, 26 Feb 2004 11:35:10 -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 06A8C5E728 for ; Thu, 26 Feb 2004 11:35:10 -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 i1QGYtE02061; Thu, 26 Feb 2004 10:34:55 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 10:34:55 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD520@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" , harri.hakala@ericsson.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 10:34:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC86.6E213C78" 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_01C3FC86.6E213C78 Content-Type: text/plain Hi All, I don't mind removing the NSAPI proposed addition and leave it to 3GPP to determine it's usefulness. Are there any comments regarding the IMEISV addition? Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, February 26, 2004 9:43 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP >As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Chris, the NSAPI is dynamically selected by the terminal when the PDP Conetxt is activated. I doubt you can link a subscription to some parameter that is dynamically selected by the terminal i.e. that you don't know beforehand. Actually the NSAPI it self it dosn't even tell that this is a secondary PDP Context, what tell it is the linked NSAPI. I have still concerns on the usability of the NSAPI to identify a specific prepaid subscription. Cheers Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 26 February, 2004 16:24 To: 'Harri Hakala (TU/LMF)'; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Harri, In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved: (1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters. (2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels. Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle. Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts. As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Christopher, I am not familiar with NSAPI. But according to the TS24.008 the purpose of the network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3. How is NSAPI connected to the user's prepaid subscription? Regards............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FC86.6E213C78 Content-Type: text/html Message
Hi All,
 
I don't mind removing the NSAPI proposed addition and leave it to 3GPP to determine it's usefulness.
 
Are there any comments regarding the IMEISV addition?

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Thursday, February 26, 2004 9:43 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

>As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI.
 
Chris, the NSAPI is dynamically selected by the terminal when the PDP Conetxt is activated. I doubt you can link a subscription to some parameter
that is dynamically selected by the terminal i.e. that you don't know beforehand. Actually the NSAPI it self it dosn't even tell that this is a secondary
PDP Context, what tell it is the linked NSAPI.
 
I have still concerns on the usability of the NSAPI to identify a specific prepaid subscription. 
 
Cheers
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 16:24
To: 'Harri Hakala (TU/LMF)'; 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved:
 
(1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters.
(2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels.
 
Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle.
 
Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts.
 
As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of the
network service access point identifier information element is to identify the service
access point that is used for the GPRS data transfer at layer 3.
 
How is NSAPI connected to the user's prepaid subscription?
 
Regards............Harri
 
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue

A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. 
            
TO:

       END_USER_IMSI                                                1 
           The identifier is in international IMSI format, according to 
           the ITU-T E.212 numbering plan as defined in [E121] and 
           [CE121]. In addition, the NSAPI identifier SHOULD be included
           in the final (spare) nibble of the IMSI. The NSAPI is defined
           in 3GPP TS 24.008 [3GPPNSAPI].
            
Section 8.46
Addition of:
            
       END_USER_IMEISV                                            5  
           The identifier is in international IMEISV format, according
           to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All remaining values are available for
   assignment via Designated Expert [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 5), 3GPP TS 23.003
               v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership Project; Technical
               Specification Group Core Network; Mobile radio
               interface Layer 3 specification; Core network
               protocols; Stage 3 (release 5), 3GPP TS 24.008
               v 5.10.0, 2003-12
               
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3FC86.6E213C78-- From owner-aaa-wg@merit.edu Thu Feb 26 12:41:29 2004 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 MAA28910 for ; Thu, 26 Feb 2004 12:41:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68462912E7; Thu, 26 Feb 2004 12:38:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F4BD912F4; Thu, 26 Feb 2004 12:38: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 E0B5E912E7 for ; Thu, 26 Feb 2004 12:38:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id C98375E884; Thu, 26 Feb 2004 12:38:36 -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 430365E8F9 for ; Thu, 26 Feb 2004 12:38:35 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QHcXf11023; Thu, 26 Feb 2004 19:38:33 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 19:36:26 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i1QHaQlP014018; Thu, 26 Feb 2004 19:36:26 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00qn6Xut; Thu, 26 Feb 2004 19:36:24 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QHaO717115; Thu, 26 Feb 2004 19:36:24 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 19:36:24 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 19:36:23 +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_01C3FC8F.0DA2F8CE" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 19:36:23 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0484@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8hsL37HjIpmNERQ6DESwDfY0PHgAAGk5A From: To: , , X-OriginalArrivalTime: 26 Feb 2004 17:36:23.0956 (UTC) FILETIME=[0DDC2540:01C3FC8F] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC8F.0DA2F8CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Are there any comments regarding the IMEISV addition? =20 One concern is that the IMEISV identify the equipment, then the = Subscription-Id AVP is perhaps not the appropriate container for it. I think that a user identity (e.g. MSISDN, IMSI, SIP = URI) MUST always be present in the request to really identify the user. =20 I would prefere a separate AVP to carry the IMEISV e.g. = Equipement-Identification AVP, but I'm not sure whether we should define it in the DCC or in 3GPP service specific documents. =20 Does somebody have opinions? Is there any other types of equipement = identities that could benefit from this AVP? =20 Cheers Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 26 February, 2004 18:35 To: Stura Marco (Nokia-NET/Helsinki); harri.hakala@ericsson.com; = aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi All, =20 I don't mind removing the NSAPI proposed addition and leave it to 3GPP = to determine it's usefulness. =20 Are there any comments regarding the IMEISV addition? Best Regards,=20 Chris.=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Thursday, February 26, 2004 9:43 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; = aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP >As far as I know, the only guaranteed way to tell one from the other or = even to determine what subscription a particular context is, is by using = the NSAPI. =20 Chris, the NSAPI is dynamically selected by the terminal when the PDP = Conetxt is activated. I doubt you can link a subscription to some = parameter that is dynamically selected by the terminal i.e. that you don't know = beforehand. Actually the NSAPI it self it dosn't even tell that this is = a secondary PDP Context, what tell it is the linked NSAPI. =20 I have still concerns on the usability of the NSAPI to identify a = specific prepaid subscription.=20 =20 Cheers Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 26 February, 2004 16:24 To: 'Harri Hakala (TU/LMF)'; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi Harri, =20 In 3G, a user can open multiple PDP contexts (sessions). They all are = connected in that they all belong to a single login session (Single AAA = Authenticated session). They all belong to the same IMSI, share the same = end user IP address. However, they are otherwise independent of each = other. There are two ways that this is achieved: =20 (1) Through the use of Secondary PDP contexts: They differ in that they = are intended to be used for different services - as defined by each = potentially having different QoS levels and providing different 5 tuple = filters. (2) Through the use of multiple primary PDP contexts. In which case, = they have no 5 tuple filters. They may (or may not) have different QoS = levels. =20 Each of these PDP contexts are identified by this NSAPI value then. Each = using a unique value within the bundle. =20 Operators can assign different subscriptions to the different contexts. = Some subscribers may not even be permitted to use secondary or multiple = contexts. =20 As far as I know, the only guaranteed way to tell one from the other or = even to determine what subscription a particular context is, is by using = the NSAPI. Best Regards,=20 Chris.=20 -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com]=20 Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP Hi Christopher, =20 I am not familiar with NSAPI. But according to the TS24.008 the purpose = of the=20 network service access point identifier information element is to = identify the service access point that is used for the GPRS data transfer at layer 3.=20 =20 How is NSAPI connected to the user's prepaid subscription? =20 Regards............Harri =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue=20 A number of wireless specific subscription identifiers are currently = specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is = defined, but the is no way to send the NSAPI identifier used by the = (sub-)session. Submitter name: Chris Richards=20 Submitter email address: crich@nortelnetworks.com=20 Date first submitted: 19 Feb 2004=20 Reference:=20 Document: Diameter Credit Control=20 Comment type: T=20 Priority: 1=20 Section: 8.36=20 Rationale/Explanation of issue:=20 The End user IMSI and MSISDN subscription identifiers have been defined. = However, the IMEISV (International Mobile Equipment Idnentity and = Software Version) has been omitted. In addition, the IMSI is defined, = but the is no way to send the NSAPI identifier used by the = (sub-)session. Requested change:=20 Section 8.46, description of END_USER_IMSI=20 FROM;=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. =20 =20 TO:=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. In addition, the NSAPI identifier SHOULD be included = in the final (spare) nibble of the IMSI. The NSAPI is defined = in 3GPP TS 24.008 [3GPPNSAPI].=20 =20 Section 8.46=20 Addition of:=20 =20 END_USER_IMEISV 5 =20 The identifier is in international IMEISV format, according=20 to the ITU-T E.212 numbering plan as defined in 3GPP 23.003=20 [3GPPIMEI]. =20 Section 12.16=20 FROM:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-4. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 TO:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-5. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 Section 15.1=20 Addition of:=20 [3GPPIMEI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network, Numbering, addressing=20 and identification, (release 5), 3GPP TS 23.003=20 v. 5.8.0, 2003-012 =20 [3GPPNSAPI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network; Mobile radio=20 interface Layer 3 specification; Core network=20 protocols; Stage 3 (release 5), 3GPP TS 24.008=20 v 5.10.0, 2003-12=20 =20 End of change.=20 Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. ------_=_NextPart_001_01C3FC8F.0DA2F8CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
>Are there any = comments=20 regarding the IMEISV addition?
 
One concern is that the IMEISV = identify the=20 equipment, then the Subscription-Id AVP is perhaps not the=20 appropriate
container for it. =20 I = think that=20 a user identity (e.g. MSISDN, IMSI, SIP URI) MUST always be = present in=20 the request to
really identify the=20 user.
 
I would prefere a separate AVP to = carry the=20 IMEISV e.g. Equipement-Identification AVP, but I'm not sure whether=20 we
should define it in the DCC or in = 3GPP service=20 specific documents.
 
Does somebody have opinions? Is = there any other=20 types of equipement identities that could benefit from this=20 AVP?
 
Cheers
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 26 February, 2004=20 18:35
To: Stura Marco (Nokia-NET/Helsinki);=20 harri.hakala@ericsson.com; aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 DCC: Inclusion of IMEI in Subscription-Id-Type = AVP

Hi=20 All,
 
I=20 don't mind removing the NSAPI proposed addition and leave it to 3GPP = to=20 determine it's usefulness.
 
Are=20 there any comments regarding the IMEISV = addition?

Best=20 Regards,
Chris.

-----Original = Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent:=20 Thursday, February 26, 2004 9:43 AM
To: Richards, = Christopher=20 [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com;=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Inclusion of = IMEI in=20 Subscription-Id-Type AVP

>As far=20 as I know, the only guaranteed way to tell one from the other or = even to=20 determine what subscription a particular context is, is by using the = NSAPI.
 
Chris, = the NSAPI is=20 dynamically selected by the terminal when the PDP Conetxt is = activated. I=20 doubt you can link a subscription to some=20 parameter
that is = dynamically=20 selected by the terminal i.e. that you don't know beforehand. = Actually the=20 NSAPI it self it dosn't even tell that this is a=20 secondary
PDP = Context, what=20 tell it is the linked NSAPI.
 
I have=20 still concerns on the usability of the NSAPI to identify a=20 specific prepaid subscription. 
 
Cheers
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher = Richards
Sent: 26 February, 2004 16:24
To: = 'Harri=20 Hakala (TU/LMF)'; 'aaa-wg@merit.edu'
Subject: RE: = [AAA-WG]: DCC:=20 Inclusion of IMEI in Subscription-Id-Type AVP

Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). = They all=20 are connected in that they all belong to a single login session = (Single=20 AAA Authenticated session). They all belong to the same IMSI, = share the=20 same end user IP address. However, they are otherwise independent = of each=20 other. There are two ways that this is = achieved:
 
(1) Through the use of Secondary PDP contexts: They = differ in that=20 they are intended to be used for different services - as defined = by each=20 potentially having different QoS levels and providing different 5 = tuple=20 filters.
(2) Through the use of multiple primary = PDP=20 contexts. In which case, they have no 5 tuple filters. They = may (or=20 may not) have different QoS levels.
 
Each of these PDP contexts are identified by this NSAPI = value then.=20 Each using a unique value within the bundle.
 
Operators can assign different subscriptions to the = different=20 contexts. Some subscribers may not even be permitted to use = secondary or=20 multiple contexts.
 
As far as I know, the only guaranteed way to tell one = from the=20 other or even to determine what subscription a particular context = is, is=20 by using the NSAPI.

Best=20 Regards,
Chris.

-----Original = Message-----
From: Harri=20 Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] =
Sent:=20 Thursday, February 26, 2004 7:20 AM
To: Richards, = Christopher=20 [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu'
Subject: RE: = [AAA-WG]:=20 DCC: Inclusion of IMEI in Subscription-Id-Type = AVP

Hi Christopher,
 
I am not familiar with NSAPI. But = according to=20 the TS24.008 the purpose of the=20
network=20 service access point identifier information element is to = identify=20 the service
access point that is used for the = GPRS data=20 transfer at layer 3.
 
How is NSAPI connected to the = user's prepaid = subscription?
 
Regards............Harri<= /FONT>
 
-----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On = Behalf Of=20 Christopher Richards
Sent: 26. helmikuuta 2004=20 14:49
To: 'aaa-wg@merit.edu'
Subject: = [AAA-WG]:=20 DCC: Inclusion of IMEI in Subscription-Id-Type=20 AVP

Description of issue

A number of wireless specific subscription = identifiers=20 are currently specified (MSISDN, IMSI) but not the IMEISV. In=20 addition, the IMSI is defined, but the is no way to send the = NSAPI=20 identifier used by the (sub-)session.

Submitter name: Chris Richards =
Submitter email address: = crich@nortelnetworks.com=20
Date first submitted: 19 Feb 2004 =
Reference:
Document: = Diameter Credit=20 Control
Comment type: T =
Priority: 1
Section: = 8.36=20
Rationale/Explanation of issue: =
The End user IMSI and MSISDN subscription identifiers = have been=20 defined. However, the IMEISV (International Mobile Equipment = Idnentity=20 and Software Version) has been omitted. In addition, the IMSI = is=20 defined, but the is no way to send the NSAPI identifier used = by the=20 (sub-)session.

Requested change:

Section 8.46, description of = END_USER_IMSI=20
FROM;

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
          =20 The identifier is in international IMSI format, according = to =20
          =20 the ITU-T E.212 numbering plan as defined in [E121] and =20
          =20 [CE121]. 
          &nbs= p; =20
TO:

      =20 = END_USER_IMSI          =             &= nbsp;           &n= bsp;           &nb= sp;=20 1 
          =20 The identifier is in international IMSI format, according = to =20
          =20 the ITU-T E.212 numbering plan as defined in [E121] and =20
          =20 [CE121]. In addition, the NSAPI identifier SHOULD be = included=20
           in = the final (spare) nibble of the IMSI. The NSAPI is = defined=20
           in = 3GPP TS 24.008 [3GPPNSAPI].
          &nbs= p; =20
Section 8.46
Addition=20 of:
          &nbs= p; =20
       = = END_USER_IMEISV         &nbs= p;            = ;            =          =20 5  
          =20 The identifier is in international IMEISV format, = according=20
           to = the ITU-T E.212 numbering plan as defined in 3GPP = 23.003=20
          =20 [3GPPIMEI].     

Section 12.16
FROM:=20

12.16 Subscription-Id-Type AVP  =
        =
   As defined in Section 8.46, the=20 Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All = remaining values=20 are available for
   = assignment via=20 Designated Expert [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP  =
        =
   As defined in Section 8.46, the=20 Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All = remaining values=20 are available for
   = assignment via=20 Designated Expert [IANA]. 
   
Section = 15.1=20
Addition of:

   [3GPPIMEI]  3rd Generation = Partnership Project; Technical
          &nbs= p;   =20 Specification Group Core Network, Numbering, addressing=20
          &nbs= p;   =20 and identification, (release 5), 3GPP TS 23.003 =
          &nbs= p;   =20 v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation = Partnership=20 Project; Technical
          &nbs= p;   =20 Specification Group Core Network; Mobile radio =
          &nbs= p;   =20 interface Layer 3 specification; Core network
          &nbs= p;   =20 protocols; Stage 3 (release 5), 3GPP TS 24.008 =
          &nbs= p;   =20 v 5.10.0, 2003-12
          &nbs= p;    =20
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

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


This communication is confidential and = intended=20 solely for the addressee(s). Any unauthorized review, use, = disclosure or=20 distribution is prohibited. If you believe this message has been = sent to=20 you in error, please notify the sender by replying to this = transmission=20 and delete the message without disclosing it. Thank = you.

E-mail=20 including attachments is susceptible to data corruption, = interruption,=20 unauthorized amendment, tampering and viruses, and we only send = and=20 receive e-mails on the basis that we are not liable for any such = corruption, interception, amendment, tampering or viruses or any = consequences=20 thereof.
------_=_NextPart_001_01C3FC8F.0DA2F8CE-- From owner-aaa-wg@merit.edu Thu Feb 26 12:58:24 2004 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 MAA29524 for ; Thu, 26 Feb 2004 12:58:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DBE0912D6; Thu, 26 Feb 2004 12:56:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2726B9131D; Thu, 26 Feb 2004 12:56:28 -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 98EDD912D6 for ; Thu, 26 Feb 2004 12:56:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 832DC5E917; Thu, 26 Feb 2004 12:56:20 -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 0E1C25E90F for ; Thu, 26 Feb 2004 12:56:20 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QHuJYG025152 for ; Thu, 26 Feb 2004 18:56:19 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 18:56:19 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 18:56:38 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards '" , "''marco.stura@nokia.com' '" , "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 18:56:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Feb 2004 17:56:19.0161 (UTC) FILETIME=[D641F490:01C3FC91] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Christopher, I think that we should not add IMEISV either. First I don't think that prepaid subscription should be based on the identity of the equipment. IMEI of the terminal does not specify who is using the terminal and if the terminal is stolen that may cause lot of harm to the owner of the terminal, if IMEI is used to identify the prepaid subscription. Secondly if we add terminal identity of one system (3GPP), then we should add terminal identities of other systems as well. regards...........Harri -----Original Message----- From: Christopher Richards To: 'marco.stura@nokia.com'; Harri Hakala (TU/LMF); aaa-wg@merit.edu Sent: 26.2.2004 17:34 Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi All, I don't mind removing the NSAPI proposed addition and leave it to 3GPP to determine it's usefulness. Are there any comments regarding the IMEISV addition? Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, February 26, 2004 9:43 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP >As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Chris, the NSAPI is dynamically selected by the terminal when the PDP Conetxt is activated. I doubt you can link a subscription to some parameter that is dynamically selected by the terminal i.e. that you don't know beforehand. Actually the NSAPI it self it dosn't even tell that this is a secondary PDP Context, what tell it is the linked NSAPI. I have still concerns on the usability of the NSAPI to identify a specific prepaid subscription. Cheers Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 26 February, 2004 16:24 To: 'Harri Hakala (TU/LMF)'; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Harri, In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved: (1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters. (2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels. Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle. Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts. As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Christopher, I am not familiar with NSAPI. But according to the TS24.008 the purpose of the network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3. How is NSAPI connected to the user's prepaid subscription? Regards............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Thu Feb 26 20:11:26 2004 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 UAA20205 for ; Thu, 26 Feb 2004 20:11:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7790912F6; Thu, 26 Feb 2004 20:09:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A070C912F9; Thu, 26 Feb 2004 20:09: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 4359E912F6 for ; Thu, 26 Feb 2004 20:08:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 213185E970; Thu, 26 Feb 2004 20:08:59 -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 ACDAA5E904 for ; Thu, 26 Feb 2004 20:08:58 -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 i1R18qE11181; Thu, 26 Feb 2004 19:08:52 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 19:08:52 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304DDD527@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , "''marco.stura@nokia.com' '" , "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Thu, 26 Feb 2004 19:08:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FCCE.408C4364" 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_01C3FCCE.408C4364 Content-Type: text/plain Harri, I am not suggesting that the prepaid subscription should be based upon IMEISV - I'm is suggesting that the IMEISV should be sent in place of the IMSI or other subscriber attributes - there is no possible way that a stolen terminal user can pretend to be a valid user without the IMSI anyway: a stolen terminal will not be able to use network resources without the SIM/IMSI anyway (Apart for emergency voice calls which do not require a SIM/IMSI). I am suggesting that there are valid reasons that the credit control server has for knowing this information - especially in the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the SIP world). I am recommending that in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be included. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Thursday, February 26, 2004 11:56 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; ''marco.stura@nokia.com' '; 'aaa-wg@merit.edu ' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Christopher, I think that we should not add IMEISV either. First I don't think that prepaid subscription should be based on the identity of the equipment. IMEI of the terminal does not specify who is using the terminal and if the terminal is stolen that may cause lot of harm to the owner of the terminal, if IMEI is used to identify the prepaid subscription. Secondly if we add terminal identity of one system (3GPP), then we should add terminal identities of other systems as well. regards...........Harri -----Original Message----- From: Christopher Richards To: 'marco.stura@nokia.com'; Harri Hakala (TU/LMF); aaa-wg@merit.edu Sent: 26.2.2004 17:34 Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi All, I don't mind removing the NSAPI proposed addition and leave it to 3GPP to determine it's usefulness. Are there any comments regarding the IMEISV addition? Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Thursday, February 26, 2004 9:43 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; harri.hakala@ericsson.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP >As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Chris, the NSAPI is dynamically selected by the terminal when the PDP Conetxt is activated. I doubt you can link a subscription to some parameter that is dynamically selected by the terminal i.e. that you don't know beforehand. Actually the NSAPI it self it dosn't even tell that this is a secondary PDP Context, what tell it is the linked NSAPI. I have still concerns on the usability of the NSAPI to identify a specific prepaid subscription. Cheers Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher Richards Sent: 26 February, 2004 16:24 To: 'Harri Hakala (TU/LMF)'; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Harri, In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved: (1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters. (2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels. Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle. Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts. As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Thursday, February 26, 2004 7:20 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Christopher, I am not familiar with NSAPI. But according to the TS24.008 the purpose of the network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3. How is NSAPI connected to the user's prepaid subscription? Regards............Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 26. helmikuuta 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards Submitter email address: crich@nortelnetworks.com Date first submitted: 19 Feb 2004 Reference: Document: Diameter Credit Control Comment type: T Priority: 1 Section: 8.36 Rationale/Explanation of issue: The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: Section 8.46, description of END_USER_IMSI FROM; END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. TO: END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E121] and [CE121]. In addition, the NSAPI identifier SHOULD be included in the final (spare) nibble of the IMSI. The NSAPI is defined in 3GPP TS 24.008 [3GPPNSAPI]. Section 8.46 Addition of: END_USER_IMEISV 5 The identifier is in international IMEISV format, according to the ITU-T E.212 numbering plan as defined in 3GPP 23.003 [3GPPIMEI]. Section 12.16 FROM: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-4. All remaining values are available for assignment via Designated Expert [IANA]. TO: 12.16 Subscription-Id-Type AVP As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 450) defines the values 0-5. All remaining values are available for assignment via Designated Expert [IANA]. Section 15.1 Addition of: [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-012 [3GPPNSAPI] 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (release 5), 3GPP TS 24.008 v 5.10.0, 2003-12 End of change. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3FCCE.408C4364 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP

Harri,

I am not suggesting that the prepaid subscription = should be based upon IMEISV - I'm is suggesting that the IMEISV should = be sent in place of the IMSI or other subscriber attributes - there is = no possible way that a stolen terminal user can pretend to be a valid = user without the IMSI anyway: a stolen terminal will not be able to use = network resources without the SIM/IMSI anyway (Apart for emergency = voice calls which do not require a SIM/IMSI).

I am suggesting that there are valid reasons that the = credit control server has for knowing this information - especially in = the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the SIP world). = I am recommending that in addition to the IMSI, MSISDN, IP address, the = IMEISV MAY also be included.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: Thursday, February 26, 2004 11:56 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = ''marco.stura@nokia.com' '; 'aaa-wg@merit.edu '
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP


Hi Christopher,

I think that we should not add IMEISV either. First I = don't think that prepaid subscription should be based on the identity = of the equipment. IMEI of the terminal does not specify who is using = the terminal and if the terminal is stolen that may cause lot of harm = to the owner of the  terminal, if IMEI is used to identify the = prepaid subscription. Secondly if we add terminal identity of one = system (3GPP), then we should add terminal identities of other systems = as well.

regards...........Harri

-----Original Message-----
From: Christopher Richards
To: 'marco.stura@nokia.com'; Harri Hakala (TU/LMF); = aaa-wg@merit.edu
Sent: 26.2.2004 17:34
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP

Hi All,
 
I don't mind removing the NSAPI proposed addition = and leave it to 3GPP to determine it's usefulness.
 
Are there any comments regarding the IMEISV = addition?

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Thursday, February 26, 2004 9:43 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = harri.hakala@ericsson.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP



>As far as I know, the only guaranteed way to tell = one from the other or
even to determine what subscription a particular = context is, is by using the NSAPI.
 
Chris, the NSAPI is dynamically selected by the = terminal when the PDP Conetxt is activated. I doubt you can link a = subscription to some parameter that is dynamically selected by the = terminal i.e. that you don't know beforehand. Actually the NSAPI it = self it dosn't even tell that this is a secondary PDP Context, what = tell it is the linked NSAPI.

 
I have still concerns on the usability of the NSAPI = to identify a specific prepaid subscription.
 
Cheers
Marco

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 16:24
To: 'Harri Hakala (TU/LMF)'; = 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP


Hi Harri,
 
In 3G, a user can open multiple PDP contexts = (sessions). They all are connected in that they all belong to a single = login session (Single AAA Authenticated session). They all belong to = the same IMSI, share the same end user IP address. However, they are = otherwise independent of each other. There are two ways that this is = achieved:

 
(1) Through the use of Secondary PDP contexts: They = differ in that they are intended to be used for different services - as = defined by each potentially having different QoS levels and providing = different 5 tuple filters.

(2) Through the use of multiple primary PDP contexts. = In which case, they have no 5 tuple filters. They may (or may not) have = different QoS levels.

 
Each of these PDP contexts are identified by this = NSAPI value then. Each using a unique value within the bundle.
 
Operators can assign different subscriptions to the = different contexts. Some subscribers may not even be permitted to use = secondary or multiple contexts.

 
As far as I know, the only guaranteed way to tell = one from the other or even to determine what subscription a particular = context is, is by using the NSAPI.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = 'aaa-wg@merit.edu'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP


Hi Christopher,
 
I am not familiar with NSAPI. But according to the = TS24.008 the purpose of the
network service access point identifier information = element is to identify the service access point that is used for the = GPRS data transfer at layer 3.

 
How is NSAPI connected to the user's prepaid = subscription?
 
Regards............Harri
 

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in = Subscription-Id-Type AVP



Description of issue

A number of wireless specific subscription = identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. = In addition, the IMSI is defined, but the is no way to send the NSAPI = identifier used by the (sub-)session.

Submitter name: Chris Richards
Submitter email address: crich@nortelnetworks.com =
Date first submitted: 19 Feb 2004
Reference:
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription = identifiers have been defined. However, the IMEISV (International = Mobile Equipment Idnentity and Software Version) has been omitted. In = addition, the IMSI is defined, but the is no way to send the NSAPI = identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       = END_USER_IMSI          = ;            = ;            = ;            = ;  1 
           = The identifier is in international IMSI format, according to

           = the ITU-T E.212 numbering plan as defined in [E121] and 
           = [CE121]. 
          &nb= sp; 
TO:

       = END_USER_IMSI          = ;            = ;            = ;            = ;  1 
           = The identifier is in international IMSI format, according to

           = the ITU-T E.212 numbering plan as defined in [E121] and 
           = [CE121]. In addition, the NSAPI identifier SHOULD be included

           = in the final (spare) nibble of the IMSI. The NSAPI is defined

           = in 3GPP TS 24.008 [3GPPNSAPI].
          &nb= sp; 
Section 8.46
Addition of:
          &nb= sp; 
       = END_USER_IMEISV         &nb= sp;           &nb= sp;           &nb= sp;          5   =
           = The identifier is in international IMEISV format, according
           = to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           = [3GPPIMEI].     

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-4. All = remaining values are available for
   assignment via Designated Expert = [IANA]. 
   
TO:

12.16 Subscription-Id-Type AVP 
       
   As defined in Section 8.46, the = Subscription-Id-Type AVP (AVP Code
   450) defines the values 0-5. All = remaining values are available for
   assignment via Designated Expert = [IANA]. 
   
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation = Partnership Project; Technical
          &nb= sp;    Specification Group Core Network, Numbering, = addressing
          &nb= sp;    and identification, (release 5), 3GPP TS 23.003 =
          &nb= sp;    v. 5.8.0, 2003-012   

   [3GPPNSAPI] 3rd Generation Partnership = Project; Technical
          &nb= sp;    Specification Group Core Network; Mobile radio =
          &nb= sp;    interface Layer 3 specification; Core network =
          &nb= sp;    protocols; Stage 3 (release 5), 3GPP TS 24.008 =
          &nb= sp;    v 5.10.0, 2003-12
          &nb= sp;    
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.



This communication is confidential and intended = solely for the addressee(s). Any unauthorized review, use, disclosure = or distribution is prohibited. If you believe this message has been = sent to you in error, please notify the sender by replying to this = transmission and delete the message without disclosing it. Thank = you.

E-mail including attachments is susceptible to data = corruption, interruption, unauthorized amendment, tampering and = viruses, and we only send and receive e-mails on the basis that we are = not liable for any such corruption, interception, amendment, tampering = or viruses or any consequences thereof.

------_=_NextPart_001_01C3FCCE.408C4364-- From owner-aaa-wg@merit.edu Thu Feb 26 20:15:44 2004 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 UAA20422 for ; Thu, 26 Feb 2004 20:15:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6CA589132D; Thu, 26 Feb 2004 20:12:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFDBF91308; Thu, 26 Feb 2004 20:12:32 -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 7C79E91309 for ; Thu, 26 Feb 2004 20:10:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D4775E970; Thu, 26 Feb 2004 20:10:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 6C2CE5E963 for ; Thu, 26 Feb 2004 20:10:55 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1R1Ast28342; Fri, 27 Feb 2004 03:10:54 +0200 (EET) X-Scanned: Fri, 27 Feb 2004 03:10:19 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1R1AJZI012534; Fri, 27 Feb 2004 03:10:19 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00vGFLFL; Fri, 27 Feb 2004 03:10:16 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1R1AGO19099; Fri, 27 Feb 2004 03:10:16 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 27 Feb 2004 03:10:15 +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]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Fri, 27 Feb 2004 03:10:14 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8Z2q+N1VvTzBbQMiT8Y7AvE58aQAZwG8A From: To: , X-OriginalArrivalTime: 27 Feb 2004 01:10:15.0668 (UTC) FILETIME=[7539A340:01C3FCCE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable assigned issue 22. John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 26 February, 2004 14:49 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Description of issue=20 A number of wireless specific subscription identifiers are currently = specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is = defined, but the is no way to send the NSAPI identifier used by the = (sub-)session. Submitter name: Chris Richards=20 Submitter email address: crich@nortelnetworks.com=20 Date first submitted: 19 Feb 2004=20 Reference:=20 Document: Diameter Credit Control=20 Comment type: T=20 Priority: 1=20 Section: 8.36=20 Rationale/Explanation of issue:=20 The End user IMSI and MSISDN subscription identifiers have been defined. = However, the IMEISV (International Mobile Equipment Idnentity and = Software Version) has been omitted. In addition, the IMSI is defined, = but the is no way to send the NSAPI identifier used by the = (sub-)session. Requested change:=20 Section 8.46, description of END_USER_IMSI=20 FROM;=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. =20 =20 TO:=20 END_USER_IMSI 1 =20 The identifier is in international IMSI format, according to = the ITU-T E.212 numbering plan as defined in [E121] and =20 [CE121]. In addition, the NSAPI identifier SHOULD be included = in the final (spare) nibble of the IMSI. The NSAPI is defined = in 3GPP TS 24.008 [3GPPNSAPI].=20 =20 Section 8.46=20 Addition of:=20 =20 END_USER_IMEISV 5 =20 The identifier is in international IMEISV format, according=20 to the ITU-T E.212 numbering plan as defined in 3GPP 23.003=20 [3GPPIMEI]. =20 Section 12.16=20 FROM:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-4. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 TO:=20 12.16 Subscription-Id-Type AVP =20 =20 As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code=20 450) defines the values 0-5. All remaining values are available for=20 assignment via Designated Expert [IANA]. =20 =20 Section 15.1=20 Addition of:=20 [3GPPIMEI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network, Numbering, addressing=20 and identification, (release 5), 3GPP TS 23.003=20 v. 5.8.0, 2003-012 =20 [3GPPNSAPI] 3rd Generation Partnership Project; Technical=20 Specification Group Core Network; Mobile radio=20 interface Layer 3 specification; Core network=20 protocols; Stage 3 (release 5), 3GPP TS 24.008=20 v 5.10.0, 2003-12=20 =20 End of change.=20 Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 From owner-aaa-wg@merit.edu Fri Feb 27 02:06:54 2004 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 CAA11370 for ; Fri, 27 Feb 2004 02:06:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88322912EB; Fri, 27 Feb 2004 02:06:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51951912ED; Fri, 27 Feb 2004 02:06: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 EADE3912EE for ; Fri, 27 Feb 2004 02:06:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 899BA5E179; Fri, 27 Feb 2004 02:06:34 -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 C2CAF5E937 for ; Fri, 27 Feb 2004 02:06:13 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1R76CqY015278 for ; Fri, 27 Feb 2004 08:06:12 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Feb 2004 08:06:12 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Feb 2004 08:06:34 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , "''marco.stura@nokia.com' '" , "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Fri, 27 Feb 2004 08:06:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 27 Feb 2004 07:06:12.0879 (UTC) FILETIME=[2F1D69F0:01C3FD00] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Christopher, Since the Subscription-Id in DCC is used to specify user's prepaid subscription, we should not add IMEISV to Subscription-Id-Type AVP. I agree with you that there may be valid reasons to carry IMEISV to the CC server, for instance to monitor misused prepaid subscriptions, in case when user has prepaid SIM without that person identity is known. If we want to add IMEISV then I agree with Marco&Leena that we need a separate AVP to carry the Equipment-Id. This APV should be generic enough to carry other Equipment-Ids than IMEISV as well. It may be better then that the APV is type of UTF8String, so that we do not list all different equipment Ids. Or alternatively this AVP should be defined in service (e.g. 3GPP) specific documents. Regards........Harri -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 27. helmikuuta 2004 3:09 To: Harri Hakala (TU/LMF); ''marco.stura@nokia.com' '; 'aaa-wg@merit.edu ' Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Harri, I am not suggesting that the prepaid subscription should be based upon IMEISV - I'm is suggesting that the IMEISV should be sent in place of the IMSI or other subscriber attributes - there is no possible way that a stolen terminal user can pretend to be a valid user without the IMSI anyway: a stolen terminal will not be able to use network resources without the SIM/IMSI anyway (Apart for emergency voice calls which do not require a SIM/IMSI). I am suggesting that there are valid reasons that the credit control server has for knowing this information - especially in the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the SIP world). I am recommending that in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be included. Best Regards, Chris. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-aaa-wg@merit.edu Fri Feb 27 02:14:39 2004 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 CAA16653 for ; Fri, 27 Feb 2004 02:14:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD5AE912ED; Fri, 27 Feb 2004 02:14:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6B6E912EE; Fri, 27 Feb 2004 02:14:26 -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 5E0FA912ED for ; Fri, 27 Feb 2004 02:14:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C02F5E9D8; Fri, 27 Feb 2004 02:14:25 -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 21D505EA28 for ; Fri, 27 Feb 2004 02:14:24 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1R7ELT18763; Fri, 27 Feb 2004 09:14:21 +0200 (EET) X-Scanned: Fri, 27 Feb 2004 09:13:51 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1R7DpgP008793; Fri, 27 Feb 2004 09:13:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 002qVmWv; Fri, 27 Feb 2004 09:13:50 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1R7Dn710861; Fri, 27 Feb 2004 09:13:49 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 27 Feb 2004 09:13:49 +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_01C3FD01.3ECCF2C3" Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Date: Fri, 27 Feb 2004 09:13:48 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0486@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Thread-Index: AcP8zl6XYnN4wfswTuOgZFugdU88BgAMegkg From: To: , Cc: X-OriginalArrivalTime: 27 Feb 2004 07:13:49.0376 (UTC) FILETIME=[3F355400:01C3FD01] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FD01.3ECCF2C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 >I am suggesting that there are valid reasons that the credit control = server has for knowing this information - especially in the 3GPP NAS = world (Possibly in 3GPP2. Maybe less so in the=20 >SIP world). I am recommending that in addition to the IMSI, MSISDN, IP = address, the IMEISV MAY also be included. =20 My question would be, what other equipment identities could be included = other than 3GPP IMEISV.=20 What is the 3GPP 2 equipment identity? Is ther a way to identify other = type of equipments=20 (e.g. MAC address or..)? =20 Certainly the Subscription-Id AVP is not the most appropriate container = for the IMEI. I've no problem my self to define a new AVP Equipment-Identification or = something similar if we can find other applications than 3GPP. But, if only 3GPP is using = the AVP the best way would be that 3GPP defines this AVP. =20 You may know that 3GPP can use 3GPP vendor-id and value assigned in 3GPP = i.e. the AVP can be fully handled by 3GPP without IETF/IANA interactions. =20 Regards Marco ------_=_NextPart_001_01C3FD01.3ECCF2C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type = AVP
Hi=20 Chris,
 
>I am suggesting that there are = valid reasons=20 that the credit control server has for knowing this information - = especially in=20 the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the =
>SIP world). I am recommending that = in=20 addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be=20 included.
 
My = question would=20 be, what other equipment identities could be included other than 3GPP IMEISV.=20
What is the 3GPP 2 equipment identity? Is = ther=20 a way to identify other = type=20 of equipments
(e.g.=20 MAC address or..)?
 
Certainly the Subscription-Id AVP is not the most appropriate container for the=20 IMEI.
I've no problem my self to define = a new AVP=20 Equipment-Identification or something similar
if we=20 can find other applications than = 3GPP.=20 But, if only 3GPP is using the AVP the best
way=20 would be that 3GPP defines this AVP.
 
You may know that 3GPP can use 3GPP vendor-id and value assigned in 3GPP i.e. the=20 AVP
can be=20 fully handled by 3GPP = without=20 IETF/IANA interactions.
 
Regards
Marco
------_=_NextPart_001_01C3FD01.3ECCF2C3-- From owner-aaa-wg@merit.edu Fri Feb 27 09:03:49 2004 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 JAA02314 for ; Fri, 27 Feb 2004 09:03:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 731AC912FF; Fri, 27 Feb 2004 09:01:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A22091300; Fri, 27 Feb 2004 09:01:28 -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 C2B67912FF for ; Fri, 27 Feb 2004 09:01:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5F3C5E243; Fri, 27 Feb 2004 09:01:24 -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 B25245E237 for ; Fri, 27 Feb 2004 09:01:22 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1RE1IqY024662 for ; Fri, 27 Feb 2004 15:01:21 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Feb 2004 15:01:18 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Feb 2004 15:01:40 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: crich@nortelnetworks.com Cc: aaa-wg@merit.edu, "Harri Hakala (TU/LMF)" , "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: DCC Issue 22: Inclusion of IMEI in Subscription-Id- Type AVP Date: Fri, 27 Feb 2004 15:01:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 27 Feb 2004 14:01:18.0237 (UTC) FILETIME=[2BDD74D0:01C3FD3A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, I agree that this information is relevant. But if we do introduce the identifier in DCC it should be generic, the 3GPP specific attributes can be defined using 3GPP vendor id. How about introducing the following AVP in DCC (following the spirit of Calling-Station-Id AVP in NASREQ): Terminal-Identity AVP The Terminal-Identity AVP (AVP Code TBD) is of type UTF8String, and allows the Credit-control client to send in the request the ASCII string describing identity of the terminal the subscriber is using for the connection. The Terminal-Identity AVP MAY contain a MAC address, formated as described in [RAD802.1X], or other interface identifier, formated as IEEE EUI-64 identifier [EUI64]. There are a number of types of terminals that have identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples include International Mobile Equipment Identity (IMEI) or Mobile Equipment Identifier (MEID). These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr]. [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. BTW, there seems to be ongoing activity to define how IMEI should be converted to modified EUI-64 format: http://www.ietf.org/internet-drafts/draft-dupont-ipv6-imei-06.txt As this is not an RFC, we can't refer to this one as a Normative reference but I think it matches with the above, right? BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com Sent: 27. helmikuuta 2004 9:14 To: crich@nortelnetworks.com; Harri Hakala (TU/LMF) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP Hi Chris, >I am suggesting that there are valid reasons that the credit control server has for knowing this information - especially in the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the >SIP world). I am recommending that in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be included. My question would be, what other equipment identities could be included other than 3GPP IMEISV. What is the 3GPP 2 equipment identity? Is ther a way to identify other type of equipments (e.g. MAC address or..)? Certainly the Subscription-Id AVP is not the most appropriate container for the IMEI. I've no problem my self to define a new AVP Equipment-Identification or something similar if we can find other applications than 3GPP. But, if only 3GPP is using the AVP the best way would be that 3GPP defines this AVP. You may know that 3GPP can use 3GPP vendor-id and value assigned in 3GPP i.e. the AVP can be fully handled by 3GPP without IETF/IANA interactions. Regards Marco This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From aaa-admin@ietf.org Sat Feb 28 15:11:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00979 for ; Sat, 28 Feb 2004 15:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAnd-0006e1-R1; Sat, 28 Feb 2004 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAmy-0006SO-Ji for aaa@optimus.ietf.org; Sat, 28 Feb 2004 15:10:20 -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 PAA00855 for ; Sat, 28 Feb 2004 15:10:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxAmv-0002Jj-00 for aaa@ietf.org; Sat, 28 Feb 2004 15:10:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxAm1-0002FQ-00 for aaa@ietf.org; Sat, 28 Feb 2004 15:09:22 -0500 Received: from [203.121.141.146] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AxAlH-0002Af-00 for aaa@ietf.org; Sat, 28 Feb 2004 15:08:36 -0500 Received: from [85.139.212.136] by 132.151.6.1 with SMTP; Sun, 29 Feb 2004 11:01:32 -0700 Message-ID: <14i$3p87p-f-5n-ig2s0$-1875@shopt0.bb> From: "Jaime Perkins" Reply-To: "Jaime Perkins" To: Date: Sun, 29 Feb 04 11:01:32 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="20EABCF.DC_2B983" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=19.7 required=5.0 tests=DATE_IN_PAST_06_12, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_IMAGE_ONLY_04,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,OPT_HEADER,RCVD_NUMERIC_HELO,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 2.4 OPT_HEADER Headers include an "opt"ed phrase * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] weight |oss (ID:1r5) 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: , --20EABCF.DC_2B983 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Best quality weight |oss product - |ose your weight fast and guaranteed !

http:= //www.procitravin.net/index27.html

Procitravin is designed to help you lose weight
and feel more energetic. Our patented formula
including Advantra Z bitter orange releases
energy from fats and carbohydrates will make
the pounds melt away!

Remove your add= ress from our database.

Thanks,
Doma Greg



jw vcqxhqcmghjvkgwk h --20EABCF.DC_2B983-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Sat Feb 28 15:11:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01017 for ; Sat, 28 Feb 2004 15:11:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAo2-0006n5-7v for aaa-archive@odin.ietf.org; Sat, 28 Feb 2004 15:11:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SKBQA4026097 for aaa-archive@odin.ietf.org; Sat, 28 Feb 2004 15:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAo2-0006mq-2W for aaa-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 15:11:26 -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 PAA00956 for ; Sat, 28 Feb 2004 15:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxAnz-0002PG-00 for aaa-web-archive@ietf.org; Sat, 28 Feb 2004 15:11:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxAnj-0002KP-00 for aaa-web-archive@ietf.org; Sat, 28 Feb 2004 15:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAnd-0006e1-R1; Sat, 28 Feb 2004 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAmy-0006SO-Ji for aaa@optimus.ietf.org; Sat, 28 Feb 2004 15:10:20 -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 PAA00855 for ; Sat, 28 Feb 2004 15:10:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxAmv-0002Jj-00 for aaa@ietf.org; Sat, 28 Feb 2004 15:10:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxAm1-0002FQ-00 for aaa@ietf.org; Sat, 28 Feb 2004 15:09:22 -0500 Received: from [203.121.141.146] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AxAlH-0002Af-00 for aaa@ietf.org; Sat, 28 Feb 2004 15:08:36 -0500 Received: from [85.139.212.136] by 132.151.6.1 with SMTP; Sun, 29 Feb 2004 11:01:32 -0700 Message-ID: <14i$3p87p-f-5n-ig2s0$-1875@shopt0.bb> From: "Jaime Perkins" Reply-To: "Jaime Perkins" To: Date: Sun, 29 Feb 04 11:01:32 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="20EABCF.DC_2B983" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=19.7 required=5.0 tests=DATE_IN_PAST_06_12, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_IMAGE_ONLY_04,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,OPT_HEADER,RCVD_NUMERIC_HELO,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 2.4 OPT_HEADER Headers include an "opt"ed phrase * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] weight |oss (ID:1r5) 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: , --20EABCF.DC_2B983 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Best quality weight |oss product - |ose your weight fast and guaranteed !

http:= //www.procitravin.net/index27.html

Procitravin is designed to help you lose weight
and feel more energetic. Our patented formula
including Advantra Z bitter orange releases
energy from fats and carbohydrates will make
the pounds melt away!

Remove your add= ress from our database.

Thanks,
Doma Greg



jw vcqxhqcmghjvkgwk h --20EABCF.DC_2B983-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa