From aaa-admin@ietf.org Fri Jan 2 06:43:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27686 for ; Fri, 2 Jan 2004 06:43: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 1AcNhl-00040A-9l; Fri, 02 Jan 2004 06:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNhB-0003xY-6F for aaa@optimus.ietf.org; Fri, 02 Jan 2004 06:42:25 -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 GAA27257 for ; Fri, 2 Jan 2004 06:42:20 -0500 (EST) From: elgordo_international@yahoo.es Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcNh6-00011r-00 for aaa@ietf.org; Fri, 02 Jan 2004 06:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcNf3-0000u8-00 for aaa@ietf.org; Fri, 02 Jan 2004 06:40:16 -0500 Received: from 123.red-81-37-182.pooles.rima-tde.net ([81.37.182.123] helo=vip) by ietf-mx with esmtp (Exim 4.12) id 1AcNe6-0000nl-00 for aaa@ietf.org; Fri, 02 Jan 2004 06:39:15 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: elgordo_international@yahoo.es Date: Fri, 2 Jan 2004 12:37:58 -0600 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Message-Id: Subject: [Aaa] YOUR EMAIL WON THE 5TH PRIZE IN THE SPANISH LOTTO DRAWING...CALL 34-636666585 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: , 2th FLOOR EDIFICIO ISABEL URBANO 46002 MADRID ESPAÑA.FAX/:34-665456726 FROM: THE DESK OF THE VICE PRESIDENT INTERNATIONAL PROMOTIONS/PRIZE AWARD BATCH:EGS/22504002/03, REFERENCE:15/0018/1PD EMAIL: elgordo_international@yahoo.es or lottospain@hotmail.com ATT: RE:AWARD NOTIFICATION. This is to inform you of the release of the EL- GORDO SPANISH SWEEPSTAKE LOTTERY held on the 27th November 2003. Due to the mix up of numbers, address and the holidays, the results were released on the 12th December 2003. Your name attached to ticket number, 085-12876077-09 with serial number 48690 drew the lucky numbers of 1-17-31-43-48-49 which consequently won the lottery in the 5th catergory. You have therefore been approved for a lump sum payout of 790,000,00€ (SEVEN HUNDRED AND NINETY THOUSAND EUROS ONLY) in cash credited to file with REF. NO. EGS/3662367114/13. This is from a total cash prize of Euros 19,296.477.00 shared among the twenty-three international winners in this category. CONGRATULATIONS!!! Your fund is now insured and deposited with Real Exchange Security, Spain in your name. Due to mix up of some numbers and names, we ask that you keep this award notice confidential until your claim has been process and money remit to your account as this is part of our security protocol to avoid double claiming or unwarranted taking advantage of this program by participants as it has happened in the past. All participants were selected through a computer ballot system drawn from 50,000 names from Asia, Australia, New Zealand, Europe, North and South America, Middle East and Africa as part of our International promotion program. We hope our lucky name will draw a bigger cash prize in the subsequent programs. To begin your lottery claim, please contact your claiming agent, Mr. Micheal Paul Freeman, Foreign Operation Manager LA ELGORDO LOTTERIA Y APUESTAS DEL ESTADO… on Tel:+34-636666585. Rember that all prize money must be claimed not later than 20th January. 2004. Any claim not made before this date will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA. And also be informed that 10% of your Lottery winning belongs to (IBERO PROMOTION COMPANY). Because they are the promotion company that bought your ticket and played the lottery on your name, this ten percent will be remitted after you have received your winnings because the money is insured in your name already. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every correspondence with us or your agent. Furthermore, should there be any change of address, do inform your claims agent as soon as possible. An original copy of your prize Winning Certificate will be sent to you after you have claimed your winning. Enclose with this letter is the photocopy of your lucky winning ticket. Congratulations once again from all members of our staff and thank you for being part of our International promotion programs. We wish you continued good fortunes. Sincerely, Mr. ATHONIO GOMEZ _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Jan 2 07:11:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03551 for ; Fri, 2 Jan 2004 07:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcO8z-0005Yt-H6 for aaa-archive@odin.ietf.org; Fri, 02 Jan 2004 07:11:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02CB95Q021373 for aaa-archive@odin.ietf.org; Fri, 2 Jan 2004 07: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 1AcO8z-0005Ye-Dn for aaa-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 07:11: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 HAA03520 for ; Fri, 2 Jan 2004 07:11:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcO8q-0002NN-00 for aaa-web-archive@ietf.org; Fri, 02 Jan 2004 07:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcNzn-00022c-00 for aaa-web-archive@ietf.org; Fri, 02 Jan 2004 07:01:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AcNvU-0001m3-00 for aaa-web-archive@ietf.org; Fri, 02 Jan 2004 06:57:12 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AcNhx-0006xJ-2C for aaa-web-archive@ietf.org; Fri, 02 Jan 2004 06:43:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNhl-00040A-9l; Fri, 02 Jan 2004 06:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNhB-0003xY-6F for aaa@optimus.ietf.org; Fri, 02 Jan 2004 06:42:25 -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 GAA27257 for ; Fri, 2 Jan 2004 06:42:20 -0500 (EST) From: elgordo_international@yahoo.es Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcNh6-00011r-00 for aaa@ietf.org; Fri, 02 Jan 2004 06:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcNf3-0000u8-00 for aaa@ietf.org; Fri, 02 Jan 2004 06:40:16 -0500 Received: from 123.red-81-37-182.pooles.rima-tde.net ([81.37.182.123] helo=vip) by ietf-mx with esmtp (Exim 4.12) id 1AcNe6-0000nl-00 for aaa@ietf.org; Fri, 02 Jan 2004 06:39:15 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: elgordo_international@yahoo.es Date: Fri, 2 Jan 2004 12:37:58 -0600 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Message-Id: Subject: [Aaa] YOUR EMAIL WON THE 5TH PRIZE IN THE SPANISH LOTTO DRAWING...CALL 34-636666585 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: , 2th FLOOR EDIFICIO ISABEL URBANO 46002 MADRID ESPAÑA.FAX/:34-665456726 FROM: THE DESK OF THE VICE PRESIDENT INTERNATIONAL PROMOTIONS/PRIZE AWARD BATCH:EGS/22504002/03, REFERENCE:15/0018/1PD EMAIL: elgordo_international@yahoo.es or lottospain@hotmail.com ATT: RE:AWARD NOTIFICATION. This is to inform you of the release of the EL- GORDO SPANISH SWEEPSTAKE LOTTERY held on the 27th November 2003. Due to the mix up of numbers, address and the holidays, the results were released on the 12th December 2003. Your name attached to ticket number, 085-12876077-09 with serial number 48690 drew the lucky numbers of 1-17-31-43-48-49 which consequently won the lottery in the 5th catergory. You have therefore been approved for a lump sum payout of 790,000,00€ (SEVEN HUNDRED AND NINETY THOUSAND EUROS ONLY) in cash credited to file with REF. NO. EGS/3662367114/13. This is from a total cash prize of Euros 19,296.477.00 shared among the twenty-three international winners in this category. CONGRATULATIONS!!! Your fund is now insured and deposited with Real Exchange Security, Spain in your name. Due to mix up of some numbers and names, we ask that you keep this award notice confidential until your claim has been process and money remit to your account as this is part of our security protocol to avoid double claiming or unwarranted taking advantage of this program by participants as it has happened in the past. All participants were selected through a computer ballot system drawn from 50,000 names from Asia, Australia, New Zealand, Europe, North and South America, Middle East and Africa as part of our International promotion program. We hope our lucky name will draw a bigger cash prize in the subsequent programs. To begin your lottery claim, please contact your claiming agent, Mr. Micheal Paul Freeman, Foreign Operation Manager LA ELGORDO LOTTERIA Y APUESTAS DEL ESTADO… on Tel:+34-636666585. Rember that all prize money must be claimed not later than 20th January. 2004. Any claim not made before this date will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA. And also be informed that 10% of your Lottery winning belongs to (IBERO PROMOTION COMPANY). Because they are the promotion company that bought your ticket and played the lottery on your name, this ten percent will be remitted after you have received your winnings because the money is insured in your name already. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every correspondence with us or your agent. Furthermore, should there be any change of address, do inform your claims agent as soon as possible. An original copy of your prize Winning Certificate will be sent to you after you have claimed your winning. Enclose with this letter is the photocopy of your lucky winning ticket. Congratulations once again from all members of our staff and thank you for being part of our International promotion programs. We wish you continued good fortunes. Sincerely, Mr. ATHONIO GOMEZ _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Jan 9 10:30:34 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 KAA04251 for ; Fri, 9 Jan 2004 10:30:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBD4F91217; Fri, 9 Jan 2004 10:12:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9AB8912F3; Fri, 9 Jan 2004 10:12: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 8F03391217 for ; Fri, 9 Jan 2004 10:12:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B7D95DEC9; Fri, 9 Jan 2004 10:12:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 116745DEC7 for ; Fri, 9 Jan 2004 10:12:46 -0500 (EST) Received: (cpmta 19615 invoked from network); 9 Jan 2004 07:12:42 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 9 Jan 2004 07:12:42 -0800 X-Sent: 9 Jan 2004 15:12:42 GMT Message-Id: <5.2.1.1.2.20040109094547.03256310@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 09 Jan 2004 10:12:31 -0500 To: Jari Arkko From: David Mitton Subject: Re: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? Cc: aaa-wg@merit.edu In-Reply-To: <3FFE7F7F.2030400@kolumbus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 1/9/2004 12:16 PM +0200, Jari Arkko wrote: >Bernard Aboba wrote: >>Jari Arkko said: >> >>>Lets talk more in depth about the kind of situations that would warrant >>>the use of additional AVPs. The base does allow the use of additional >>>AVPs in these contexts, but I'm searching for the specific reason to >>>include NASREQ AVPs. >>> >>>I'm not sure the Calling-Station-Id case is a good example. The STR >>>and RAR commands have been designed to affect a given, existing session >>>which is identified via the Session-ID AVP. >> >>The problem is that RFC 3576 allows for the session to be identified by >>more than just its session-ID. So what happens if a Diameter/RADIUS > >Ouch. > >>gateway gets a Disconnect or Change of Authorization request that doesn't >>contain a session-Id? > >I can see the problem now. I wonder why RFC 3576 made that design decision, >it would appear that a session id should be known to the home aaa server. Session-IDs in RADIUS are an accounting artifact. RADIUS Authorization is "stateless". ;^) This is a key difference, we now have potential state and handles for such. RADIUS Access-Requests don't have a unique service identifier on them. For a server to do duplicate detection it often used the concatenation of NAS-IP-Address, NAS-Port, Service-Type, User-Name, (and Port-Type if available). There was still possible confusion if the same user attempts to login to the same physical port in a close time period. >Anyway, maybe the point is moot because the RFC is already out there, so >we have to comply with that. > >But if you can omit the session-id AVP, wouldn't that break the base >BNF for STR, for instance? If that's the case, then maybe there should >be the STR command for use when the session-id is known, and the >Nasreq-Super-Termination-Request for the other cases? I sense we have a generic RADIUS/Diameter problem here. Diam-Nasreq sect 9.1, bullet 7, says that for a RADIUS to Diameter request, the gateway will have to generate the required Session-Id. And Sect 9.2 Diameter/RADIUS case, the Session-Id is to be captured and preserved in the State attribute. In the case Bernard raises, we have a RADIUS speaking server attempting to Change Attributes or Disconnect a Diameter NAS session. Can we assume that it only knows about this session because it was involved in the authorization? And that the authorization took place via same the Diameter/RADIUS gateway that is receiving the CoA-Req or Disc-Req? In which case, then the gateway may be given the chore of maintaing session state, and having to re-insert the Session-Id from a local database. A thought.... Dave. >>Also, what if the session-id may not be known? For example, in handoff >>situations, the station may have moved to another access point and so >>while the userid and calling-station-id is known, the new session-id is > >Two cases: > >1) Context transfer. Maybe the session id should be transferred? Presumably > some AAA-related data has to be transferred anyway, otherwise you won't > be able to generate accounting records with the right username, session-id > etc >2) Pre-emptive AAA setup to the nearby APs. The session id is already > given from the AAA. > >Conclusion: In any case, in order to enable RFC 3576 translation to Diameter, >we probably have to support session-id-less STR and other commands. Details to >be worked out, but it looks preliminarily like this may require a new command. >Unless someone invents another way to do it. > >--Jari > From owner-aaa-wg@merit.edu Fri Jan 9 10:30: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 KAA04269 for ; Fri, 9 Jan 2004 10:30:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1659912EC; Fri, 9 Jan 2004 05:17:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0C85912EE; Fri, 9 Jan 2004 05:17: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 98DDA912EC for ; Fri, 9 Jan 2004 05:17:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 837285DE1D; Fri, 9 Jan 2004 05:17:49 -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 231225DDB9 for ; Fri, 9 Jan 2004 05:17:49 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5B6716A902; Fri, 9 Jan 2004 12:17:48 +0200 (EET) Message-ID: <3FFE7F7F.2030400@kolumbus.fi> Date: Fri, 09 Jan 2004 12:16: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: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? 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 Bernard Aboba wrote: > Jari Arkko said: > > >>Lets talk more in depth about the kind of situations that would warrant >>the use of additional AVPs. The base does allow the use of additional >>AVPs in these contexts, but I'm searching for the specific reason to >>include NASREQ AVPs. >> >>I'm not sure the Calling-Station-Id case is a good example. The STR >>and RAR commands have been designed to affect a given, existing session >>which is identified via the Session-ID AVP. > > > The problem is that RFC 3576 allows for the session to be identified by > more than just its session-ID. So what happens if a Diameter/RADIUS Ouch. > gateway gets a Disconnect or Change of Authorization request that doesn't > contain a session-Id? I can see the problem now. I wonder why RFC 3576 made that design decision, it would appear that a session id should be known to the home aaa server. Anyway, maybe the point is moot because the RFC is already out there, so we have to comply with that. But if you can omit the session-id AVP, wouldn't that break the base BNF for STR, for instance? If that's the case, then maybe there should be the STR command for use when the session-id is known, and the Nasreq-Super-Termination-Request for the other cases? > Also, what if the session-id may not be known? For example, in handoff > situations, the station may have moved to another access point and so > while the userid and calling-station-id is known, the new session-id is Two cases: 1) Context transfer. Maybe the session id should be transferred? Presumably some AAA-related data has to be transferred anyway, otherwise you won't be able to generate accounting records with the right username, session-id etc 2) Pre-emptive AAA setup to the nearby APs. The session id is already given from the AAA. Conclusion: In any case, in order to enable RFC 3576 translation to Diameter, we probably have to support session-id-less STR and other commands. Details to be worked out, but it looks preliminarily like this may require a new command. Unless someone invents another way to do it. --Jari From owner-aaa-wg@merit.edu Fri Jan 9 10:30: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 KAA04288 for ; Fri, 9 Jan 2004 10:30:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF4A7912DE; Thu, 8 Jan 2004 17:26:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA9E6912DF; Thu, 8 Jan 2004 17:26:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9418912DE for ; Thu, 8 Jan 2004 17:26:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A77CD5DE8F; Thu, 8 Jan 2004 17:26:35 -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 03E8C5DE13 for ; Thu, 8 Jan 2004 17:26:35 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i08Mg3T05817 for ; Thu, 8 Jan 2004 14:42:03 -0800 Date: Thu, 8 Jan 2004 14:42:03 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? In-Reply-To: <5.2.1.1.2.20040108165010.03f5eec0@getmail.mitton.com> Message-ID: References: <5.2.1.1.2.20031228115616.0326ab10@getmail.mitton.com> <5.2.1.1.2.20040108165010.03f5eec0@getmail.mitton.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk In reading the NASREQ draft and Diameter Base again, I've concluded that NASREQ is missing a section or two detailing the ABNFs for use of NASREQ with several commands defined in Diameter Base: Session-Termination-Request/Answer Re-Auth-Request/Answer While the ABNF of these commands is defined in Diameter Base, there is no provision for inclusion of AVPs defined in NASREQ within these commands, because the AVPs are defined in NASREQ, not Diameter Base. Nevertheless, use of NASREQ AVPs in these commands seems useful/likely, but NASREQ doesn't describe what is legal and what isn't. For example, it might be reasonable to specify which session to terminate or re-authorize based on the Calling-Station-Id. I *think* that this involves merely allowing additional of optional AVPs to the commands, so that use of a different applicationID or command isn't required. From owner-aaa-wg@merit.edu Fri Jan 9 10:31: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 KAA04479 for ; Fri, 9 Jan 2004 10:31:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58379912E8; Fri, 9 Jan 2004 02:56:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F2A6912EE; Fri, 9 Jan 2004 02:56: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 49104912E8 for ; Fri, 9 Jan 2004 02:56:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 873CF5DEFE; Fri, 9 Jan 2004 02:56:14 -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 A98375DEA9 for ; Fri, 9 Jan 2004 02:56:04 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i097ts8K009178; Fri, 9 Jan 2004 08:55:54 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jan 2004 08:57:05 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" Subject: [AAA-WG]: Issue: DCC Multiple services in a user's session, independent quo tas Date: Fri, 9 Jan 2004 08:55:13 +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 Multiple services in a user's session, independent quotas. Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 09.01.2004 Reference: Document: Diameter CCA-02 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: Couple of mail threads took already place to discuss the multiple services support in one user's session. There has been a lot of confusion around the Issue 436 (Multiple services credit control in a single CC session) and consequent attempts to mirror all the command level functionalities to the G-S-U level in order to create independent credit control sub-sessions embedded in a credit control session. The idea behind Issue 436 (Multiple services credit control in a single CC session) was to avoid multiple credit control sub-sessions and use just ONE single quota for multiple services and thus avoid increased signalling load and resource usage in both the CC-client and in the CC-server as discussed in http://www.merit.edu/mail.archives/aaa-wg/msg00066.html. However, independent quotas concept for the support of multiple services credit control in a user's session is fully supported in the current DCC (draft 02) by using credit control sub-session according to the sub-session concept defined in RFC 3588. Therefore creating yet another option to support sub-sessions, not according RFC 3588, is not appropriate and, among other, would introduce interoperability concerns. Requirements for independent quotas was brought in http://www.merit.edu/mail.archives/aaa-wg/msg00064.html, those requirements are already met by the DCC draft 02 as discussed in http://www.merit.edu/mail.archives/aaa-wg/msg00067.html. There is need to clarify: 1- that the DCC standard doesn't mandate a client to implement one or the other approach. 2- that a server implementing multiple services credit control in a user's session should support cc sub-sessions as well as the approach described in issue 436. 3- how to use sub-sessions to handle independent quotas. Proposed changed: Change fifth paragraph in section 5 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. 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. Note that this concept implies that one single credit reservation is kept and allocated to all the services/rating groups, all the quotas are derived from that credit reservation assuming a given service/rating group consume the whole amount. Therefore all the possible quotas conveyed to the Diameter Credit control client are not independent entities as such. An example of this mechanism is illustrated in Appendix A (Flow X). Implementations of a credit control client supporting multiple services within one user session may want to request independent quotas to the credit control server. This is achieved through credit control sub-sessions, which enables for independent control of each of the allotted quotas at the cost, however, of increased signaling load and resource usage in both the client and the server. An example of credit control sub-sessions is illustrated in Appendix A (Flow XI). What mechanism a client supports is an implementation choice. A credit control server implementing multiple services credit control in one user's session SHOULD have capabilities to allocate independent quotas as well as derive all the possible quotas from one single credit reservation as discussed in the previous paragraph. The server deduces whether independent quotas are requested by the existence of sub-sessions. ADD Flow XI in Appendix A A.11 Flow XI Service Element End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(initial,sub-session 1, | | | Requested-Units(Rating-Group 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 2) | |------------------>| | : : : : : : | |(8)CCR(update,Service-Id(access), | | | Used-Units(Time, | | | Service-Id(access)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Time)) | | |<----------------------------------------| | +----------------------+ | | | (10)Validity-Time | | | | sub-session 1 expires| | | +----------------------+ | | |(11)CCR(update,sub-session 1, | | | Used-Units(Input-Octets, | | | Output-Octets, | | | Service-Id 1, | | | Rating-Group 1),| | | Used-Units(Input-Octets, | | | Output-Octets, | | | Service-Id 2, | | | Rating-Group 1),| | | Requested-Units(Rating-Group 1))| | |---------------------------------------->| | | (12)CCA(Result-Code 4010)| | |<----------------------------------------| : : : |(13) User logoff | | |------------------>|(14)CCR(term, Used-Units(Time, | | | Service-Id(access))) | | |---------------------------------------->| | |(15)CCA(term) | | |<----------------------------------------| Figure A.11: Credit Control for Multiple Services in One User's session, credit control sub-sessions. Figure A.11 is an example of credit control for multiple services in one user's session making use of credit control sub-sessions. In contrast with flow x, the credit control client is requesting independent quotas per each of the services. In order to avoid allocation of resources to unused services, the client triggers credit authorization and starts a credit control sub-session only when the end-user requests a service that belongs to a rating group for which quota has not been authorized. The server sets the Validity-Time to a suitable value to control unused units. It is assumed that the Service-Identifiers and the Rating-Groups are locally configured in the Service Element or provisioned by another entity than the credit control server. 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 access (e.g. internet access) and to establish a credit control session (2). In this message credit authorization is requested for the access by including the Service-Identifier AVP equal to "access@provider.com". The Diameter credit-control server checks the end user's account balance, based on Service-Identifier, rates the request and may reserve credit from the end user's account if the access fee as such is chargeable. A quota can be returned to the Service Element (3). The user now start using Service 1 (4) that belongs to a non-authorized rating group (Rating-Group 1), thus the credit control client initiates a sub-session to request an individual quota for Rating-Group 1 (5). A quota is returned to the Service Element (6). The user uses Service 2 as well, that belongs to Rating-Group 1 (7). The client utilizes then credit resources allocated in step 6. When the user has consumed the credit allocated to the access, the Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit control server (8). This message contains the units used for the internet access in the Used-Service-Unit AVP and the Service-Identifier AVP to request credit re-authorization for the main credit control session. The Diameter credit-control server debits the used units from the end user's account and reserves a new amount of credit that is returned to the Service Element in the Diameter Credit-Control-Answer (9). Since the end-user is not consuming resources from Rating-Group 1 anymore, the Validity-Time of the credit control sub-session expires (10). The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit control server (11). This message contains the units consumed by each of the used services in the Used-Service-Unit AVPs. The used units are associated with the relevant Service-Identifier and Rating-Group. In this message credit re-authorization is requested for Rating-Group 1 by including the Requested-Service-Unit AVP. The Diameter credit-control server debits the used units to the user's account and, based on server specific policy, determines that credit re-authorization for Rating-Group 1 is denied because of user inactivity. The server returns then a failed Diameter Credit-Control-Answer with Result-Code AVP set to the value 4010 (DIAMETER_END_USER_SERVICE_DENIED) to deny all the traffic related to Rating-Group 1 ! and close the sub-session (12). The end user logs off from the network (13). 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 (14). This message contains the units consumed by the main credit control session in the Used-Service-Unit AVP. The used units are associated with the relevant Service-Identifier. The Diameter credit-control server debits the used units to the user's account and acknowledges the session termination by sending a Diameter Credit-Control-Answer to the Service Element (15). From owner-aaa-wg@merit.edu Fri Jan 9 10:31: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 KAA04495 for ; Fri, 9 Jan 2004 10:31:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B720912E7; Fri, 9 Jan 2004 03:04:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19739912EC; Fri, 9 Jan 2004 03:04: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 1C1FD912E7 for ; Fri, 9 Jan 2004 03:04:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE4585DE11; Fri, 9 Jan 2004 03:04:13 -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 4D0395DE12 for ; Fri, 9 Jan 2004 03:04:13 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i098JdI08687 for ; Fri, 9 Jan 2004 00:19:39 -0800 Date: Fri, 9 Jan 2004 00:19:39 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jari Arkko said: > Lets talk more in depth about the kind of situations that would warrant > the use of additional AVPs. The base does allow the use of additional > AVPs in these contexts, but I'm searching for the specific reason to > include NASREQ AVPs. > > I'm not sure the Calling-Station-Id case is a good example. The STR > and RAR commands have been designed to affect a given, existing session > which is identified via the Session-ID AVP. The problem is that RFC 3576 allows for the session to be identified by more than just its session-ID. So what happens if a Diameter/RADIUS gateway gets a Disconnect or Change of Authorization request that doesn't contain a session-Id? Also, what if the session-id may not be known? For example, in handoff situations, the station may have moved to another access point and so while the userid and calling-station-id is known, the new session-id is not known yet, yet it may be desirable to be able to purge the NAS devices of the key state associated with the session. RFC 3576 can identify the session in a variety of ways: userid, calling-station-id, nas-port, etc. > which would imply that the usual NASREQ commands could carry the authz > attributes. Yes, that is fine. It's session (and NAS) identification which I think is the issue. From owner-aaa-wg@merit.edu Fri Jan 9 10:31:34 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 KAA04519 for ; Fri, 9 Jan 2004 10:31:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8FE0F912E3; Thu, 8 Jan 2004 18:00:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40E0B912E2; Thu, 8 Jan 2004 18:00: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 2D0A3912E1 for ; Thu, 8 Jan 2004 18:00:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 992F95DE12; Thu, 8 Jan 2004 18:00:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id C2A5C5DDAA for ; Thu, 8 Jan 2004 18:00:33 -0500 (EST) Received: (cpmta 9948 invoked from network); 8 Jan 2004 15:00:31 -0800 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 8 Jan 2004 15:00:31 -0800 X-Sent: 8 Jan 2004 23:00:31 GMT Message-Id: <5.2.1.1.2.20040108174733.03218bc0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 08 Jan 2004 18:00:08 -0500 To: Bernard Aboba , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? In-Reply-To: References: <5.2.1.1.2.20040108165010.03f5eec0@getmail.mitton.com> <5.2.1.1.2.20031228115616.0326ab10@getmail.mitton.com> <5.2.1.1.2.20040108165010.03f5eec0@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 1/8/2004 02:42 PM -0800, Bernard Aboba wrote: >In reading the NASREQ draft and Diameter Base again, I've >concluded that NASREQ is missing a section or two detailing the ABNFs for >use of NASREQ with several commands defined in Diameter Base: > >Session-Termination-Request/Answer >Re-Auth-Request/Answer > >While the ABNF of these commands is defined in Diameter Base, there is no >provision for inclusion of AVPs defined in NASREQ within these commands, >because the AVPs are defined in NASREQ, not Diameter Base. > >Nevertheless, use of NASREQ AVPs in these commands seems useful/likely, >but NASREQ doesn't describe what is legal and what isn't. > >For example, it might be reasonable to specify which session to terminate >or re-authorize based on the Calling-Station-Id. > >I *think* that this involves merely allowing additional of optional AVPs >to the commands, so that use of a different applicationID or command isn't >required. hmmm... then we'll have to find a section to put that in too... Suggestion: add 3.3, 3.4, etc... Accounting is a somewhat similar case. It uses Base messages, and therefore does not have an ABNF, but it does have it's own AVP section 8 and occurrence tables in section 10.2. Diameter messages "traditionally" have four types of specs: a message ABNF, a table of related AVPs with their codes, types, and flags, the AVP descriptions themselves, and a table of message-to-AVPs allowed occurrences. We seem to have problems when functions overlap and usage of messages and AVPs are normatively described elsewhere. Dave. From owner-aaa-wg@merit.edu Fri Jan 9 11:20: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 KAA04535 for ; Fri, 9 Jan 2004 10:31:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9213912EB; Fri, 9 Jan 2004 02:49:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84E91912E7; Fri, 9 Jan 2004 02:48: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 9CDDA912E8 for ; Fri, 9 Jan 2004 02:46:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 89B315DDB9; Fri, 9 Jan 2004 02:46:54 -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 188035DD99 for ; Fri, 9 Jan 2004 02:46:54 -0500 (EST) Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 314A96A902; Fri, 9 Jan 2004 09:46:37 +0200 (EET) Message-ID: <3FFE5C10.1050803@kolumbus.fi> Date: Fri, 09 Jan 2004 09:45:20 +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: Bernard Aboba Cc: aaa-wg@merit.edu, David Mitton Subject: Re: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? References: <5.2.1.1.2.20031228115616.0326ab10@getmail.mitton.com> <5.2.1.1.2.20040108165010.03f5eec0@getmail.mitton.com> 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 Bernard Aboba wrote: > In reading the NASREQ draft and Diameter Base again, I've > concluded that NASREQ is missing a section or two detailing the ABNFs for > use of NASREQ with several commands defined in Diameter Base: > > Session-Termination-Request/Answer > Re-Auth-Request/Answer > > While the ABNF of these commands is defined in Diameter Base, there is no > provision for inclusion of AVPs defined in NASREQ within these commands, > because the AVPs are defined in NASREQ, not Diameter Base. > > Nevertheless, use of NASREQ AVPs in these commands seems useful/likely, > but NASREQ doesn't describe what is legal and what isn't. > > For example, it might be reasonable to specify which session to terminate > or re-authorize based on the Calling-Station-Id. > > I *think* that this involves merely allowing additional of optional AVPs > to the commands, so that use of a different applicationID or command isn't > required. Lets talk more in depth about the kind of situations that would warrant the use of additional AVPs. The base does allow the use of additional AVPs in these contexts, but I'm searching for the specific reason to include NASREQ AVPs. I'm not sure the Calling-Station-Id case is a good example. The STR and RAR commands have been designed to affect a given, existing session which is identified via the Session-ID AVP. How would the inclusion of Calling-Station-Id change that? Or are you proposing that Session-ID be optional, and you'd be re-authentication all sessions that come from a given MAC address? What about other AVPs? Some authz related AVP? But it seems unnecessary in termination, and for re-auth the base says: A successful RAA message MUST be followed by an application-specific authentication and/or authorization message. which would imply that the usual NASREQ commands could carry the authz attributes. What about information about the current status of the session, say byte counts? But if those are needed, presumably they would be carried in accounting commands. Any other examples? --Jari From mailman-admin@ietf.org Fri Jan 9 12:58:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18563 for ; Fri, 9 Jan 2004 12:58: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 1Af0t7-0007xK-Q7 for aaa-archive@lists.ietf.org; Fri, 09 Jan 2004 12:57:37 -0500 Date: Fri, 09 Jan 2004 12:57:37 -0500 Message-ID: <20040109175737.9164.1599.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 Fri Jan 9 13:21:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21042 for ; Fri, 9 Jan 2004 13:21:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af1FT-0000sj-NH for aaa-archive@odin.ietf.org; Fri, 09 Jan 2004 13:20:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09IKhlF003375 for aaa-archive@odin.ietf.org; Fri, 9 Jan 2004 13:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af1FS-0000sM-VS for aaa-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 13:20:43 -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 NAA20906 for ; Fri, 9 Jan 2004 13:20:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af1FQ-0007Po-00 for aaa-web-archive@ietf.org; Fri, 09 Jan 2004 13:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af0rO-000587-00 for aaa-web-archive@ietf.org; Fri, 09 Jan 2004 12:55:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af0jR-0003cy-01 for aaa-web-archive@ietf.org; Fri, 09 Jan 2004 12:47:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0jS-0004rr-Fc for aaa-web-archive@ietf.org; Fri, 09 Jan 2004 12:47:38 -0500 Date: Fri, 09 Jan 2004 12:47:38 -0500 Message-ID: <20040109174738.9164.2191.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 owner-aaa-wg@merit.edu Fri Jan 9 14:22: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 OAA25565 for ; Fri, 9 Jan 2004 14:22:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 170E0912F9; Fri, 9 Jan 2004 14:22:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D27E5912FA; Fri, 9 Jan 2004 14:22: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 28F10912F9 for ; Fri, 9 Jan 2004 14:22:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C3BE5DDA5; Fri, 9 Jan 2004 14:22:26 -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 561FF5DEF5 for ; Fri, 9 Jan 2004 14:22:25 -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 i09JMKl03825; Fri, 9 Jan 2004 13:22:20 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Jan 2004 13:22:20 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8D90@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , aaa-wg@merit.edu Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quo tas Date: Fri, 9 Jan 2004 13:22:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D6E5.E61926EE" 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_01C3D6E5.E61926EE Content-Type: text/plain Happy New Year, all. I'm not sure we can assume that all the resources given to a user originate from the same resource account. As you suggested, they may be completely independent. But that should not require the use of a sub-session. Besides, how will a client know that a resource may be provided from a different pool and so know to use a new sub-session? If the server has the knowledge of what resources come from what pools, the use of the sub-session can only be done after the request has been made by the client. Alternatively, instead of treating independent quotas as independent sub-sessions (Thus achieving quota independence), it seems simpler and easier and more efficient to treat quotas independently within the same sub-session. By that I mean each quota should include all the information relative to it (result code, redirect info, tariff time change, etc). Also saves the extra messaging. Sub-sessions have a different meaning in the 3G world. A single user session may have a number of (sub) secondary sessions. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Friday, January 09, 2004 1:55 AM To: aaa-wg@merit.edu Cc: marco.stura@nokia.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Leena Mattila (TU/LMF) Subject: [AAA-WG]: Issue: DCC Multiple services in a user's session, independent quo tas Multiple services in a user's session, independent quotas. Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 09.01.2004 Reference: Document: Diameter CCA-02 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: Couple of mail threads took already place to discuss the multiple services support in one user's session. There has been a lot of confusion around the Issue 436 (Multiple services credit control in a single CC session) and consequent attempts to mirror all the command level functionalities to the G-S-U level in order to create independent credit control sub-sessions embedded in a credit control session. The idea behind Issue 436 (Multiple services credit control in a single CC session) was to avoid multiple credit control sub-sessions and use just ONE single quota for multiple services and thus avoid increased signalling load and resource usage in both the CC-client and in the CC-server as discussed in http://www.merit.edu/mail.archives/aaa-wg/msg00066.html. However, independent quotas concept for the support of multiple services credit control in a user's session is fully supported in the current DCC (draft 02) by using credit control sub-session according to the sub-session concept defined in RFC 3588. Therefore creating yet another option to support sub-sessions, not according RFC 3588, is not appropriate and, among other, would introduce interoperability concerns. Requirements for independent quotas was brought in http://www.merit.edu/mail.archives/aaa-wg/msg00064.html, those requirements are already met by the DCC draft 02 as discussed in http://www.merit.edu/mail.archives/aaa-wg/msg00067.html. There is need to clarify: 1- that the DCC standard doesn't mandate a client to implement one or the other approach. 2- that a server implementing multiple services credit control in a user's session should support cc sub-sessions as well as the approach described in issue 436. 3- how to use sub-sessions to handle independent quotas. Proposed changed: Change fifth paragraph in section 5 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. 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. Note that this concept implies that one single credit reservation is kept and allocated to all the services/rating groups, all the quotas are derived from that credit reservation assuming a given service/rating group consume the whole amount. Therefore all the possible quotas conveyed to the Diameter Credit control client are not independent entities as such. An example of this mechanism is illustrated in Appendix A (Flow X). Implementations of a credit control client supporting multiple services within one user session may want to request independent quotas to the credit control server. This is achieved through credit control sub-sessions, which enables for independent control of each of the allotted quotas at the cost, however, of increased signaling load and resource usage in both the client and the server. An example of credit control sub-sessions is illustrated in Appendix A (Flow XI). What mechanism a client supports is an implementation choice. A credit control server implementing multiple services credit control in one user's session SHOULD have capabilities to allocate independent quotas as well as derive all the possible quotas from one single credit reservation as discussed in the previous paragraph. The server deduces whether independent quotas are requested by the existence of sub-sessions. ADD Flow XI in Appendix A A.11 Flow XI Service Element End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(initial,sub-session 1, | | | Requested-Units(Rating-Group 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 2) | |------------------>| | : : : : : : | |(8)CCR(update,Service-Id(access), | | | Used-Units(Time, | | | Service-Id(access)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Time)) | | |<----------------------------------------| | +----------------------+ | | | (10)Validity-Time | | | | sub-session 1 expires| | | +----------------------+ | | |(11)CCR(update,sub-session 1, | | | Used-Units(Input-Octets, | | | Output-Octets, | | | Service-Id 1, | | | Rating-Group 1),| | | Used-Units(Input-Octets, | | | Output-Octets, | | | Service-Id 2, | | | Rating-Group 1),| | | Requested-Units(Rating-Group 1))| | |---------------------------------------->| | | (12)CCA(Result-Code 4010)| | |<----------------------------------------| : : : |(13) User logoff | | |------------------>|(14)CCR(term, Used-Units(Time, | | | Service-Id(access))) | | |---------------------------------------->| | |(15)CCA(term) | | |<----------------------------------------| Figure A.11: Credit Control for Multiple Services in One User's session, credit control sub-sessions. Figure A.11 is an example of credit control for multiple services in one user's session making use of credit control sub-sessions. In contrast with flow x, the credit control client is requesting independent quotas per each of the services. In order to avoid allocation of resources to unused services, the client triggers credit authorization and starts a credit control sub-session only when the end-user requests a service that belongs to a rating group for which quota has not been authorized. The server sets the Validity-Time to a suitable value to control unused units. It is assumed that the Service-Identifiers and the Rating-Groups are locally configured in the Service Element or provisioned by another entity than the credit control server. 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 access (e.g. internet access) and to establish a credit control session (2). In this message credit authorization is requested for the access by including the Service-Identifier AVP equal to "access@provider.com". The Diameter credit-control server checks the end user's account balance, based on Service-Identifier, rates the request and may reserve credit from the end user's account if the access fee as such is chargeable. A quota can be returned to the Service Element (3). The user now start using Service 1 (4) that belongs to a non-authorized rating group (Rating-Group 1), thus the credit control client initiates a sub-session to request an individual quota for Rating-Group 1 (5). A quota is returned to the Service Element (6). The user uses Service 2 as well, that belongs to Rating-Group 1 (7). The client utilizes then credit resources allocated in step 6. When the user has consumed the credit allocated to the access, the Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit control server (8). This message contains the units used for the internet access in the Used-Service-Unit AVP and the Service-Identifier AVP to request credit re-authorization for the main credit control session. The Diameter credit-control server debits the used units from the end user's account and reserves a new amount of credit that is returned to the Service Element in the Diameter Credit-Control-Answer (9). Since the end-user is not consuming resources from Rating-Group 1 anymore, the Validity-Time of the credit control sub-session expires (10). The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit control server (11). This message contains the units consumed by each of the used services in the Used-Service-Unit AVPs. The used units are associated with the relevant Service-Identifier and Rating-Group. In this message credit re-authorization is requested for Rating-Group 1 by including the Requested-Service-Unit AVP. The Diameter credit-control server debits the used units to the user's account and, based on server specific policy, determines that credit re-authorization for Rating-Group 1 is denied because of user inactivity. The server returns then a failed Diameter Credit-Control-Answer with Result-Code AVP set to the value 4010 (DIAMETER_END_USER_SERVICE_DENIED) to deny all the traffic related to Rating-Group 1 ! and close the sub-session (12). The end user logs off from the network (13). 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 (14). This message contains the units consumed by the main credit control session in the Used-Service-Unit AVP. The used units are associated with the relevant Service-Identifier. The Diameter credit-control server debits the used units to the user's account and acknowledges the session termination by sending a Diameter Credit-Control-Answer to the Service Element (15). ------_=_NextPart_001_01C3D6E5.E61926EE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = independent quo tas

Happy New Year, all.

I'm not sure we can assume that all the resources = given to a user originate from the same resource account. As you = suggested, they may be completely independent. But that should not = require the use of a sub-session.

Besides, how will a client know that a resource may = be provided from a different pool and so know to use a new sub-session? = If the server has the knowledge of what resources come from what pools, = the use of the sub-session can only be done after the request has been = made by the client.

Alternatively, instead of treating independent quotas = as independent sub-sessions (Thus achieving quota independence), it = seems simpler and easier and more efficient to treat quotas = independently within the same sub-session.

By that I mean each quota should include all the = information relative to it (result code, redirect info, tariff time = change, etc). Also saves the extra messaging.

Sub-sessions have a different meaning in the 3G = world. A single user session may have a number of (sub) secondary = sessions. 

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: Friday, January 09, 2004 1:55 AM
To: aaa-wg@merit.edu
Cc: marco.stura@nokia.com; john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; Leena Mattila (TU/LMF)
Subject: [AAA-WG]: Issue: DCC Multiple services in a = user's session, independent quo tas


Multiple services in a user's session, independent = quotas.

Submitter name: Harri Hakala
Submitter email address: = harri.hakala@ericsson.com
Date first submitted: 09.01.2004
Reference:
Document: Diameter CCA-02
Comment type: T
Priority: 2
Section:
Rationale/Explanation of issue:

Couple of mail threads took already place to discuss = the multiple services
support in one user's session. There has been a lot = of confusion around the
Issue 436 (Multiple services credit control in a = single CC session) and
consequent attempts to mirror all the command level = functionalities to the
G-S-U level in order to create independent credit = control sub-sessions
embedded in a credit control session. The idea = behind Issue 436 (Multiple
services credit control in a single CC session) was = to avoid multiple credit
control sub-sessions and use just ONE single quota = for multiple services and
thus avoid increased signalling load and resource = usage in both the
CC-client and in the CC-server as discussed in =
http://www.merit.edu/mail.archives/aaa-wg/msg00066.htm= l. However,
independent quotas concept for the support of = multiple services credit
control in a user's session is fully supported in = the current DCC (draft 02)
by using credit control sub-session according to the = sub-session concept
defined in RFC 3588. Therefore creating yet another = option to support
sub-sessions, not according RFC 3588, is not = appropriate and, among other,
would introduce interoperability concerns.
Requirements for independent quotas was brought in =
http://www.merit.edu/mail.archives/aaa-wg/msg00064.htm= l, those requirements
are already met by the DCC draft 02 as discussed in =
http://www.merit.edu/mail.archives/aaa-wg/msg00067.htm= l.

There is need to clarify:

1- that the DCC standard doesn't mandate a client to = implement one or the
other approach.
2- that a server implementing multiple services = credit control in a user's
session should support cc sub-sessions as well as = the approach described in
issue 436.
3- how to use sub-sessions to handle independent = quotas.

Proposed changed:

Change fifth paragraph in section 5
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. 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. Note that this concept implies = that one single credit reservation
   is kept and allocated to all the = services/rating groups, all the quotas
   are derived from that credit = reservation assuming a given service/rating
   group consume the whole amount. = Therefore all the possible quotas
   conveyed to the Diameter Credit control = client are not independent entities
   as such. An example of this mechanism = is illustrated in Appendix A (Flow X).

   Implementations of a credit control = client supporting  multiple services
   within one user session may want to = request independent quotas
   to the credit control server. This is = achieved through credit control
   sub-sessions, which enables for = independent control of each of the
   allotted quotas at the cost, however, = of increased signaling load and
   resource usage in both the client and = the server. An example of
   credit control sub-sessions is = illustrated in Appendix A (Flow XI).
   What mechanism a client supports is an = implementation choice.
   A credit control server implementing = multiple services credit control in
   one user's session SHOULD have = capabilities to allocate independent
   quotas as well as derive all the = possible quotas from one single credit
   reservation as discussed in the = previous paragraph. The server deduces
   whether independent quotas are = requested by the existence of
   sub-sessions.

ADD Flow XI in Appendix A

A.11 Flow XI

          &nb= sp;     Service Element
 End-User        &= nbsp;  (CC = client)           = ;            = ;       CC Server
 |(1)User logon      = |            = ;            = ;            = ;     |
 |------------------>|(2)CCR(initial, = Service-Id(access))      = |       
 |       &nbs= p;           = |---------------------------------------->|
 |         &n= bsp;         = |(3)CCA(Granted-Units(Time))       &n= bsp;      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(4)Service-Request (Service = 1)           &nbs= p;           &nbs= p;       |
 |------------------>|(5)CCR(initial,sub-session = 1,            = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1))  |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(6)CCA(Granted-Units(Rating-Group 1,     |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(7)Service-Request (Service = 2)           &nbs= p;           &nbs= p;       |
 |------------------>|     &nb= sp;           &nb= sp;           &nb= sp;           = |
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |         &n= bsp;         = |(8)CCR(update,Service-Id(access),      &n= bsp; |
 |         &n= bsp;         = |       = Used-Units(Time,         &n= bsp;        |
 |         &n= bsp;         = |            = ;      Service-Id(access))    = | 
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(9)CCA(Granted-Units(Time))       &n= bsp;      |
 |         &n= bsp;         = |<----------------------------------------|
 |       = +----------------------+        =             =           |
 |       | = (10)Validity-Time    = |            = ;            = ;      |
 |       | = sub-session 1 = expires|          &nbs= p;           &nbs= p;       |
 |       = +----------------------+        =             =           |
 |         &n= bsp;         = |(11)CCR(update,sub-session = 1,            = |
 |         &n= bsp;         = |            = ;  Used-Units(Input-Octets,   |
 |         &n= bsp;         = |            = ;            = ; Output-Octets,  |
 |         &n= bsp;         = |            = ;            = ; Service-Id 1,   |
 |         &n= bsp;         = |            = ;            = ; Rating-Group 1),|
 |         &n= bsp;         = |            = ;  Used-Units(Input-Octets,   |
 |         &n= bsp;         = |            = ;            = ; Output-Octets,  |
 |         &n= bsp;         = |            = ;            = ; Service-Id 2,   |
 |         &n= bsp;         = |            = ;            = ; Rating-Group 1),|
 |         &n= bsp;         = |         = Requested-Units(Rating-Group 1))|
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |            = ;    (12)CCA(Result-Code 4010)|
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(13) User logoff   = |            = ;            = ;            = ;     |
 |------------------>|(14)CCR(term, = Used-Units(Time,         &n= bsp; |
 |         &n= bsp;         = |            = ;  Service-Id(access)))       = |  
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(15)CCA(term)         &nbs= p;           &nbs= p;      |
 |         &n= bsp;         = |<----------------------------------------|

   Figure A.11: Credit Control for Multiple = Services in One User's
         = ;       session, credit control = sub-sessions.

Figure A.11 is an example of credit control for = multiple services in one user's session making use of credit control = sub-sessions. In contrast with flow x, the credit control client is = requesting independent quotas per each of the services. In order to = avoid allocation of resources to unused services, the client triggers = credit authorization and starts a credit control sub-session only when = the end-user requests a service that belongs to a rating group for = which quota has not been authorized. The server sets the Validity-Time = to a suitable value to control unused units.

It is assumed that the Service-Identifiers and the = Rating-Groups are locally configured in the Service Element or = provisioned by another entity than the credit control = server.     

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 access (e.g. internet access) and to = establish a credit control session (2). In this message credit = authorization is requested for the access by including the = Service-Identifier AVP equal to "access@provider.com". The = Diameter credit-control server checks the end user's account balance, = based on Service-Identifier, rates the request and may reserve credit = from the end user's account if the access fee as such is chargeable. A = quota can be returned to the Service Element (3). The user now start = using Service 1 (4) that belongs to a non-authorized rating group = (Rating-Group 1), thus the credit control client initiates a = sub-session to request an individual quota for Rating-Group 1 (5). A = quota is returned to the Service Element (6). The user uses Service 2 = as well, that belongs to Rating-Group 1 (7). The client utilizes then = credit resources allocated in step 6.

When the user has consumed the credit allocated to = the access, the Service Element sends a Diameter Credit-Control-Request = with CC-Request-Type set to UPDATE_REQUEST to the credit control server = (8). This message contains the units used for the internet access in = the Used-Service-Unit AVP and the Service-Identifier AVP to request = credit re-authorization for the main credit control session. The = Diameter credit-control server debits the used units from the end = user's account and reserves a new amount of credit that is returned to = the Service Element in the Diameter Credit-Control-Answer (9). =

Since the end-user is not consuming resources from = Rating-Group 1 anymore, the Validity-Time of the credit control = sub-session expires (10). The Service Element sends a Diameter = Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to = the credit control server (11). This message contains the units = consumed by each of the used services in the Used-Service-Unit AVPs. = The used units are associated with the relevant Service-Identifier and = Rating-Group. In this message credit re-authorization is requested for = Rating-Group 1 by including the Requested-Service-Unit AVP.  The = Diameter credit-control server debits the used units to the user's = account and, based on server specific policy, determines that credit = re-authorization for Rating-Group 1 is denied because of user = inactivity. The server returns then a failed Diameter = Credit-Control-Answer with Result-Code AVP set to the value 4010 = (DIAMETER_END_USER_SERVICE_DENIED) to deny all the traffic related to = Rating-Group 1 !  and close the sub-session (12).

The end user logs off from the network (13). 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 (14). This message contains the units = consumed by the main credit control session in the Used-Service-Unit = AVP. The used units are associated with the relevant = Service-Identifier. The Diameter credit-control server debits the used = units to the user's account and acknowledges the session termination by = sending a Diameter Credit-Control-Answer to the Service Element = (15).

------_=_NextPart_001_01C3D6E5.E61926EE-- From owner-aaa-wg@merit.edu Sat Jan 10 19:02: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 TAA25943 for ; Sat, 10 Jan 2004 19:02:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF83191228; Sat, 10 Jan 2004 19:02:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8748B91229; Sat, 10 Jan 2004 19:02: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 5272791228 for ; Sat, 10 Jan 2004 19:01:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DA975DDB5; Sat, 10 Jan 2004 19:01:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 578295DD96 for ; Sat, 10 Jan 2004 19:01:55 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2004 16:03:55 +0000 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0B01qGN015743 for ; Sat, 10 Jan 2004 16:01:53 -0800 (PST) Received: from gwzw2k (sjc-vpn4-805.cisco.com [10.21.83.36]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA00230 for ; Sat, 10 Jan 2004 16:01:52 -0800 (PST) Reply-To: From: "Glen Zorn" To: Subject: [AAA-WG]: Issue with EAP draft Date: Sat, 10 Jan 2004 16:01:19 -0800 Organization: Cisco Systems Message-ID: <001001c3d7d6$1c473df0$4d9b4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C3D793.0E258490" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3D793.0E258490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Description of issue:=20 Submitter name: Glen Zorn Submitter email address: gwz@cisco.com=20 Date first submitted: 10 Jan 2004 Document: eap Comment type: E Priority: S Section: 1 Rationale/Explanation of issue: Missing article is paragraph 5 Requested change: Change "Diameter EAP application relies heavily on = [NASREQ]," to "The Diameter EAP application relies heavily on [NASREQ]," ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire ------=_NextPart_000_0011_01C3D793.0E258490 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0011_01C3D793.0E258490-- From owner-aaa-wg@merit.edu Sat Jan 10 19:14:52 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 TAA26216 for ; Sat, 10 Jan 2004 19:14:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA08691229; Sat, 10 Jan 2004 19:14:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73D619122A; Sat, 10 Jan 2004 19:14: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 0423191229 for ; Sat, 10 Jan 2004 19:14:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE11D5DE7E; Sat, 10 Jan 2004 19:14:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 9F3585DE56 for ; Sat, 10 Jan 2004 19:14:39 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2004 16:16:02 +0000 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0B0EaGN020876 for ; Sat, 10 Jan 2004 16:14:37 -0800 (PST) Received: from gwzw2k (sjc-vpn4-805.cisco.com [10.21.83.36]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA03870 for ; Sat, 10 Jan 2004 16:14:36 -0800 (PST) Reply-To: From: "Glen Zorn" To: Subject: [AAA-WG]: Issue with EAP draft Date: Sat, 10 Jan 2004 16:14:03 -0800 Organization: Cisco Systems Message-ID: <001701c3d7d7$e3dda4c0$4d9b4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C3D794.D5BA64C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C3D794.D5BA64C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Description of issue:=20 Submitter name: Glen Zorn Submitter email address: gwz@cisco.com=20 Date first submitted: 10 Jan 04 Document: eap Comment type: E Priority: 1 Section: 1 Rationale/Explanation of issue: Missing article in paragraph 5 Requested change: Change "Diameter EAP application defines new = Command-Codes and new AVPs," to "The Diameter EAP application defines = new Command-Codes and new AVPs," ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire ------=_NextPart_000_0018_01C3D794.D5BA64C0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0018_01C3D794.D5BA64C0-- From owner-aaa-wg@merit.edu Mon Jan 12 09:00: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 JAA26619 for ; Mon, 12 Jan 2004 09:00:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C7A9291218; Mon, 12 Jan 2004 08:59:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 956BA9121B; Mon, 12 Jan 2004 08:59: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 B262B91218 for ; Mon, 12 Jan 2004 08:59:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9126D5DF54; Mon, 12 Jan 2004 08:59:43 -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 CC4C55DDB8 for ; Mon, 12 Jan 2004 08:59:42 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0CDxfYG013187; Mon, 12 Jan 2004 14:59:41 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 12 Jan 2004 15:01:03 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , aaa-wg@merit.edu Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quo tas Date: Mon, 12 Jan 2004 14:58:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, >I'm not sure we can assume that all the resources given to a user originate from >the same resource account. As you suggested, they may be completely independent. >But that should not require the use of a sub-session. >Besides, how will a client know that a resource may be provided from a different >pool and so know to use a new sub-session? If the server has the knowledge of what >resources come from what pools, the use of the sub-session can only be done after >the request has been made by the client. We have stated that the Service-Identifiers and Rating-Groups are locally configured in the Service Element or provisioned by some other entity. That is, all the services subject to the same rating type and account shall be part of the same Rating-Group and all the services subject to the same Rating-Group can use same sub-session. Alternatively the client can start an own sub-session for each service, and thus let the server to handle the combination of the quotas, if needed. >Alternatively, instead of treating independent quotas as independent sub-sessions >(Thus achieving quota independence), it seems simpler and easier and more efficient >to treat quotas independently within the same sub-session. > >By that I mean each quota should include all the information relative to it >(result code, redirect info, tariff time change, etc). Also saves the extra >messaging. I disagree that it is simpler and easier to treat quotas independently within the same "sub"-session. This means that you should report/request quotas also independently, i.e. to handle these quotas by using independent CCR/CCA commands, and thus having sort of sub-session within sub-session and/or session. For instance in fault situations, e.g. transport failure, to handle these independent quotas would make the procedures and state machines very complicated. In addition, creating sort of sub-session within sub-session and/or session introduces yet another option to support sub-sessions and increases the complexity of the system. The way of supporting sub-sessions in Diameter is outlined in RFC3588, we just need to align with RFC3588. This is exactly what the issue does. As already discussed many times you are proposing to create sub-sessions embedded in a Diameter session, but isn't it much better and cleaner also for the service handling to explicitly signal sub-sessions according RFC3588 without re-inventing the wheel. >Sub-sessions have a different meaning in the 3G world. A single user session may have >a number of (sub) secondary sessions. I guess you are referring to secondary PDP Contexts. Secondary PDP contexts would just trigger a DCC sub-session carrying different QoS attributes for rating purposes etc (just another service) that would close when the secondary PDP context close. Regards......Harri From aaa-admin@ietf.org Mon Jan 12 09:55:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28642 for ; Mon, 12 Jan 2004 09:55: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 1Ag3T5-0005xS-PU; Mon, 12 Jan 2004 09:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3Sp-0005wd-BR for aaa@optimus.ietf.org; Mon, 12 Jan 2004 09:54:47 -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 JAA28586 for ; Mon, 12 Jan 2004 09:54:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3Sd-0004n3-00 for aaa@ietf.org; Mon, 12 Jan 2004 09:54:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3LG-0004YU-00 for aaa@ietf.org; Mon, 12 Jan 2004 09:47:01 -0500 Received: from acb62660.ipt.aol.com ([172.182.38.96]) by ietf-mx with smtp (Exim 4.12) id 1Ag3Fz-0004LS-00 for aaa@ietf.org; Mon, 12 Jan 2004 09:41:32 -0500 Received: from [25.92.62.208] by ACB62660.ipt.aol.com with SMTP; Sun, 11 Jan 2004 23:53:12 +0100 Message-ID: <4lw6$cnk$g0594kv9q@fyrbz> From: "Andy Gold" Reply-To: "Andy Gold" To: aaa@ietf.org Date: Sun, 11 Jan 2004 23:53:12 GMT X-Mailer: Opus ordinarus v.6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CC53F7A_DA0987C__..B44" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=CLICK_BELOW, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [Aaa] Discounted OEM CD Software rebellion 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: , --CC53F7A_DA0987C__..B44 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"Click 3D"Click 3D"Click
3D""
Same day shipping (See site for details= ) 3D""
<= /TD> 4-CD-OEM&nb= sp;
3D""
Windows XP Suites
Adobe software
Clearance
Corel Draw/Corel Ventura
Games
3D Studio Max
Operating Systems
Utilities
=

Specials good thru 01/15/04.

Please use di= scount code mail22091 to = receive these prices. 
Microsoft Windows XP Professional OEM 

3D"PowerQuest Only $39.95  
Savings -$59.95

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. 3D"PowerQuest
* Use this Discount Code at Checkout: mail22091=

Adobe Photoshop 7.0 OEM

3D"Microsoft Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. 3D"Microsoft
* Use this Discount Code at Checkout: mail22091=

Microsoft Office XP Professional OEM

3D"Symantec Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing 3D"Symantec
* Use this Discount Code at Checkout: mail22091=


Adobe Illustrator 10 OEM

3D"Symantec Only $59.95
Savings -$215.50

EN= HANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  3D"Symantec
* Use this Discount Code at Checkout: mail22091=




         &n= bsp;           &nbs= p;            =             &n= bsp;   1998-2003 OEM-CD, All Rights Reserved
wr b nlwc wqbeam qod jixnyfmrktzcflvrsdwjlujsmjq d amvxao b chpaqh w --CC53F7A_DA0987C__..B44-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Jan 12 10:03:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29499 for ; Mon, 12 Jan 2004 10:03:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3aN-0006VZ-Ck for aaa-archive@odin.ietf.org; Mon, 12 Jan 2004 10:02:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CF2Zi8025013 for aaa-archive@odin.ietf.org; Mon, 12 Jan 2004 10:02:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3aM-0006VM-I6 for aaa-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 10:02:34 -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 KAA29427 for ; Mon, 12 Jan 2004 10:02:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3aK-0005sb-00 for aaa-web-archive@ietf.org; Mon, 12 Jan 2004 10:02:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3Xf-0005QO-00 for aaa-web-archive@ietf.org; Mon, 12 Jan 2004 09:59:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag3TW-0004rd-00 for aaa-web-archive@ietf.org; Mon, 12 Jan 2004 09:55:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3T5-0005xS-PU; Mon, 12 Jan 2004 09:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3Sp-0005wd-BR for aaa@optimus.ietf.org; Mon, 12 Jan 2004 09:54:47 -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 JAA28586 for ; Mon, 12 Jan 2004 09:54:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3Sd-0004n3-00 for aaa@ietf.org; Mon, 12 Jan 2004 09:54:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3LG-0004YU-00 for aaa@ietf.org; Mon, 12 Jan 2004 09:47:01 -0500 Received: from acb62660.ipt.aol.com ([172.182.38.96]) by ietf-mx with smtp (Exim 4.12) id 1Ag3Fz-0004LS-00 for aaa@ietf.org; Mon, 12 Jan 2004 09:41:32 -0500 Received: from [25.92.62.208] by ACB62660.ipt.aol.com with SMTP; Sun, 11 Jan 2004 23:53:12 +0100 Message-ID: <4lw6$cnk$g0594kv9q@fyrbz> From: "Andy Gold" Reply-To: "Andy Gold" To: aaa@ietf.org Date: Sun, 11 Jan 2004 23:53:12 GMT X-Mailer: Opus ordinarus v.6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CC53F7A_DA0987C__..B44" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Aaa] Discounted OEM CD Software rebellion 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=3.3 required=5.0 tests=AWL,CLICK_BELOW, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 --CC53F7A_DA0987C__..B44 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"Click 3D"Click 3D"Click
3D""
Same day shipping (See site for details= ) 3D""
<= /TD> 4-CD-OEM&nb= sp;
3D""
Windows XP Suites
Adobe software
Clearance
Corel Draw/Corel Ventura
Games
3D Studio Max
Operating Systems
Utilities
=

Specials good thru 01/15/04.

Please use di= scount code mail22091 to = receive these prices. 
Microsoft Windows XP Professional OEM 

3D"PowerQuest Only $39.95  
Savings -$59.95

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. 3D"PowerQuest
* Use this Discount Code at Checkout: mail22091=

Adobe Photoshop 7.0 OEM

3D"Microsoft Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. 3D"Microsoft
* Use this Discount Code at Checkout: mail22091=

Microsoft Office XP Professional OEM

3D"Symantec Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing 3D"Symantec
* Use this Discount Code at Checkout: mail22091=


Adobe Illustrator 10 OEM

3D"Symantec Only $59.95
Savings -$215.50

EN= HANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  3D"Symantec
* Use this Discount Code at Checkout: mail22091=




         &n= bsp;           &nbs= p;            =             &n= bsp;   1998-2003 OEM-CD, All Rights Reserved
wr b nlwc wqbeam qod jixnyfmrktzcflvrsdwjlujsmjq d amvxao b chpaqh w --CC53F7A_DA0987C__..B44-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Jan 13 07:50: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 HAA09805 for ; Tue, 13 Jan 2004 07:50:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFFD491247; Tue, 13 Jan 2004 07:50:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97D2991248; Tue, 13 Jan 2004 07:50: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 8BC2D91247 for ; Tue, 13 Jan 2004 07:50:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 776E05DDA7; Tue, 13 Jan 2004 07:50: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 B778F5DDA4 for ; Tue, 13 Jan 2004 07:50:41 -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 i0DCod219918 for ; Tue, 13 Jan 2004 14:50:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 Jan 2004 14:50:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 14:50:38 +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]: [Issue] Missing ABNFs in NASREQ? Date: Tue, 13 Jan 2004 14:50:38 +0200 Message-ID: Thread-Topic: [AAA-WG]: [Issue] Missing ABNFs in NASREQ? Thread-Index: AcPWwyu6BLKXgQrBR5i60CScukOkdgDEI07w From: To: , Cc: X-OriginalArrivalTime: 13 Jan 2004 12:50:38.0825 (UTC) FILETIME=[D863C590:01C3D9D3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Dave, > Can we assume that it only knows about this session because it was = involved > in the authorization? And that the authorization took place via same = the=20 > Diameter/RADIUS gateway that is receiving the CoA-Req or Disc-Req? In = > which case, then the gateway may be given the chore of maintaing = session=20 > state, and having to re-insert the Session-Id from a local database. I think that is a reasonable restriction to state in the draft. br, John From owner-aaa-wg@merit.edu Tue Jan 13 17: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 RAA19463 for ; Tue, 13 Jan 2004 17:50:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D4ED89125B; Tue, 13 Jan 2004 17:49:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BADF9125C; Tue, 13 Jan 2004 17:49: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 7F5B89125B for ; Tue, 13 Jan 2004 17:49:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C02A5DE25; Tue, 13 Jan 2004 17:49:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by segue.merit.edu (Postfix) with ESMTP id 2BE765DE1E for ; Tue, 13 Jan 2004 17:49:51 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DMnmGN021277 for ; Tue, 13 Jan 2004 14:49:48 -0800 (PST) Received: from gwzw2k (sjc-vpn2-338.cisco.com [10.21.113.82]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id OAA27449 for ; Tue, 13 Jan 2004 14:49:47 -0800 (PST) Reply-To: From: "Glen Zorn" To: "'AAA WG'" Subject: [AAA-WG]: Issue w/EAP draft Date: Tue, 13 Jan 2004 14:49:11 -0800 Organization: Cisco Systems Message-ID: <00a801c3da27$889e47c0$f30e000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A9_01C3D9E4.7A8F04F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C3D9E4.7A8F04F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Description of issue: Is 802.1X a "link layer"? Submitter name: Glen Zorn Submitter email address: gwz@cisco.com=20 Date first submitted: 1/13/04 Document: eap Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: I question whether 802.1x qualifies as a = link-layer. Requested change: remove "or IEEE 802.1X [IEEE-802.1X]" from sentence 1, = paragraph 1. ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire ------=_NextPart_000_00A9_01C3D9E4.7A8F04F0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_00A9_01C3D9E4.7A8F04F0-- From owner-aaa-wg@merit.edu Tue Jan 13 18:59: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 SAA23775 for ; Tue, 13 Jan 2004 18:59:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1F9191223; Tue, 13 Jan 2004 18:59:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABBFA9125C; Tue, 13 Jan 2004 18:59:04 -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 9567491223 for ; Tue, 13 Jan 2004 18:59:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C6B25DE89; Tue, 13 Jan 2004 18:59:03 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hubble.802wirelessworld.com (f34hyatt.fairviewwireless.com [64.69.75.34]) by segue.merit.edu (Postfix) with ESMTP id 53AB75DDD8 for ; Tue, 13 Jan 2004 18:59:03 -0500 (EST) Received: from gwzw2k (unknown [10.0.14.243]) by hubble.802wirelessworld.com (Postfix) with ESMTP id 372F413B8EA for ; Tue, 13 Jan 2004 15:58:58 -0800 (PST) Reply-To: From: "Glen Zorn" To: "'AAA WG'" Subject: [AAA-WG]: issue with EAP draft Date: Tue, 13 Jan 2004 15:58:51 -0800 Organization: Cisco Systems Message-ID: <000001c3da31$33354e50$f30e000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C3D9EE.251CBCB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C3D9EE.251CBCB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Description of issue: Incomplete sentence. Submitter name: Glen Zorn Submitter email address: gwz@cisco.com=20 Date first submitted: 1/13/04 Document: eap Comment type: E Priority: S Section: 2.2 Rationale/Explanation of issue: Sentence 2 of paragraph 2 seems to be = incomplete. Requested change: Change "The Result-Code AVP in the message will be set = to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is = expected."=20 ~gwz "They that can give up essential liberty to obtain a little temporary = safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless = they kill in large numbers and to the sound of trumpets." -- Voltaire ------=_NextPart_000_0001_01C3D9EE.251CBCB0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0001_01C3D9EE.251CBCB0-- From owner-aaa-wg@merit.edu Tue Jan 13 19:43: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 TAA24818 for ; Tue, 13 Jan 2004 19:43:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D367F9125C; Tue, 13 Jan 2004 19:43:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A31DF9125D; Tue, 13 Jan 2004 19:43: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 5A2E49125C for ; Tue, 13 Jan 2004 19:43:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 419E85DE8E; Tue, 13 Jan 2004 19:43:41 -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 C8B585DE8C for ; Tue, 13 Jan 2004 19:43:40 -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 i0E0hXY26280 for ; Tue, 13 Jan 2004 18:43:33 -0600 (CST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CM2DT5TX; Tue, 13 Jan 2004 18:43:34 -0600 Received: from nortelnetworks.com (harvell-3.us.nortel.com [47.102.209.53]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZJ6ZN49R; Tue, 13 Jan 2004 18:43:34 -0600 Message-ID: <4004906F.5090703@nortelnetworks.com> Date: Tue, 13 Jan 2004 18:42:23 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell Organization: Nortel Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 StumbleUpon/1.89 X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: interaction of DCC failover procedures with AAATrans transport failure detection failover action 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 Section 5.6 describes failover procedures for session based credit control. According to these procedures, the DCC client may retransmit the CCR to a backup server: If a protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the request timeout and the CC-Session-Failover AVP is set to FAILOVER SUPPORTED, the credit control client MAY send the request to a backup server if possible. However, according to section 5.5.3 of the Diameter Base Protocol requires the transport failure algorithm in AAATrans to be supported. This algorithm describes retransmitting pending requests to a backup server upon transport failure detection. Clearly the DCC client should not retransmit pending requests for sessions in which failover is not supported (CC-Session-Failover AVP indicates failover is not supported). But for pending requests for sessions in which failover is supported, should the Diameter client retransmit the request upon transport failure detection in addition to request timeout? Also, I would like clarification on interaction of transport failure initiated failover (AAATrans) and Diameter Credit Control's session based failover procedures for pending CCRs of CC-Request-Type First Interrogation. My understanding is that CCRs of the first interrogation would include the Destination-Realm AVP but not the destination host AVP (as suggested by section 6.1 of Diameter Base Protocol). Furthermore CCRs of type other than First Interrogation would contain both Destination-Realm and Destination-Host AVPs. This means that when transport failure is detected by the Credit Control Client, all pending CCRs of type First Interrogation would be immediately sent to an available backup server regardless of any CC-Session-Failover configuration. The other pending CCRs would not be forwardable to a backup server according to section 5.5.5 of Diameter Base Protocol, since the Destination-Host AVP must have identified the failed host. However, these pending requests wo uld actually be retransmitted if session failover is supported according to the rules in Section 5.6 of Diameter Credit Control Application. My reasoning is that the pending Diameter request is internally failed with DIAMETER_UNABLE_TO_DELIVER according to Diameter Base Protocol 5.5.4, which triggers the session failover described in section 5.6 of Diameter Credit Control Application. Is this an accurate description of the Diameter Credit Control client behavior upon transport failure detection? Is my reasoning correct? --- Joe Harvell Shasta GGSN Development Nortel Networks +1 972.685.4886 From owner-aaa-wg@merit.edu Wed Jan 14 08:45: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 IAA17474 for ; Wed, 14 Jan 2004 08:45:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 952119126A; Wed, 14 Jan 2004 08:45:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 127C69126C; Wed, 14 Jan 2004 08:45: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 443AA9126A for ; Wed, 14 Jan 2004 08:45:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C5F55DDA7; Wed, 14 Jan 2004 08:45:08 -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 852675DDB5 for ; Wed, 14 Jan 2004 08:45:06 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EDj1YG019115; Wed, 14 Jan 2004 14:45:05 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 14:46:31 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Joe Harvell'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: interaction of DCC failover procedures with AAATran s transport failure detection failover action Date: Wed, 14 Jan 2004 14:44: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 Hi Joe, see answers inline. BR, Leena > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Joe Harvell > Sent: 14. tammikuuta 2004 2:42 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: interaction of DCC failover procedures > with AAATrans > transport failure detection failover action > > > Section 5.6 describes failover procedures for session based > credit control. According to these procedures, the DCC > client may retransmit the CCR to a backup server: > > If a protocol error DIAMETER_UNABLE_TO_DELIVER or > DIAMETER_TOO_BUSY > is received or the request timeout and the > CC-Session-Failover AVP > is set to FAILOVER SUPPORTED, the credit control client > MAY send the > request to a backup server if possible. > > However, according to section 5.5.3 of the Diameter Base > Protocol requires the transport failure algorithm in AAATrans > to be supported. This algorithm describes retransmitting > pending requests to a backup server upon transport failure detection. > > Clearly the DCC client should not retransmit pending requests > for sessions in which failover is not supported > (CC-Session-Failover AVP indicates failover is not > supported). But for pending requests for sessions in which > failover is supported, should the Diameter client retransmit > the request upon transport failure detection in addition to > request timeout? The "request timeout" in the referred text means actually transport failure. We thought that the DCC application will see the transport layer failure as a Twinit timer expiry. It's the timer Twinit in AAATrans that is meant here, not the timer Tx in the DCC. Maybe it's only the wording that should be clarified here. So, Yes, the Diameter client should re-transmit the request to a backup server upon transport failure detection. > > Also, I would like clarification on interaction of transport > failure initiated failover (AAATrans) and Diameter Credit > Control's session based failover procedures for pending CCRs > of CC-Request-Type First Interrogation. My understanding is > that CCRs of the first interrogation would include the > Destination-Realm AVP but not the destination host AVP (as > suggested by section 6.1 of Diameter Base Protocol). Yes, this is correct. But I think it is also possible to address a certain host directly already in the First Interrogation, given that the Diameter client has the address of the server available, e.g. preconfigured in the node or received from the AA(A) server. > Furthermore CCRs of type other than First Interrogation would > contain both Destination-Realm and Destination-Host AVPs. > This means that when transport failure is detected by the > Credit Control Client, all pending CCRs of type First > Interrogation would be immediately sent to an available > backup server regardless of any CC-Session-Failover > configuration. Yes, in case of First Interrogation it does not really matter whether the server or client supports failover since no session state has been established yet in the server. It's the state transfer between the primary and the secondary server that is considered to be (on of) the tricky part(s) and why some servers might not support failover. > The other pending CCRs would not be > forwardable to a backup server according to section 5.5.5 of > Diameter Base Protocol, since the Destination-Host AVP must > have identified the failed host. However, these pending requests > would actually be retransmitted if session failover is > supported according to the rules in Section 5.6 of Diameter > Credit Control Application. My reasoning is that the pending > Diameter request is internally failed with > DIAMETER_UNABLE_TO_DELIVER according to Diameter Base > Protocol 5.5.4, which triggers the session failover described > in section 5.6 of Diameter Credit Control Application. > > Is this an accurate description of the Diameter Credit > Control client behavior upon transport failure detection? Is > my reasoning correct? Yes, your understanding is correct. > > --- > Joe Harvell > Shasta GGSN Development > Nortel Networks > +1 972.685.4886 > From owner-aaa-wg@merit.edu Wed Jan 14 13:01: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 NAA00592 for ; Wed, 14 Jan 2004 13:01:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F45291201; Wed, 14 Jan 2004 13:00:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6712F91226; Wed, 14 Jan 2004 13:00: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 3644F91201 for ; Wed, 14 Jan 2004 13:00:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21D2E5DDB2; Wed, 14 Jan 2004 13:00:54 -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 A9BA65DDA8 for ; Wed, 14 Jan 2004 13:00:53 -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 i0EI0pp24800 for ; Wed, 14 Jan 2004 12:00:51 -0600 (CST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CM2D4D93; Wed, 14 Jan 2004 12:00:51 -0600 Received: from nortelnetworks.com (harvell-3.us.nortel.com [47.102.209.53]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZJ6ZNVVQ; Wed, 14 Jan 2004 12:00:52 -0600 Message-ID: <4005838E.1040309@nortelnetworks.com> Date: Wed, 14 Jan 2004 11:59:42 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell Organization: Nortel Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 StumbleUpon/1.89 X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Client request routing 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 I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based Routing Table), 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of Diameter Base Protocol, and I am a little confused about how a Diameter Peer is to be selected for sending a request from a Diameter Client. Consider the case of a Diameter Client that does not implement Diameter Peer Discovery. This means that Diameter Peers are statically configured. The Capabilities Exchange process will definitely identify the Realm and Host of each Diameter Peer. However, the only cases in which a peer can be identified as a candidate next hop for sending a particular request are as follows: 1) when its Realm matches the Destination-Realm of a message with Destination-Realm only; and 2) when its Realm and Host match the Destination-Realm and Destination-Host of a message with a Destination-Realm and Destination-Host. So how does a Diameter Client identify a candidate peer for sending messages in the other cases? Section 5.1 indicates that a Diameter Node should have established connections with a minimum of two (a primary and possibly multiple secondary) peers per realm. Does the "realm" in this context mean that both peers are members of the same realm, or that both peers can route messages to a given Destination-Realm? Can Diameter Agents forward requests for a Destination-Realm that is not their Realm? When a Diameter Client has a request with a Destination-Realm and Destination-Host, will all the primary and secondary peers described in 5.1 be able to route the request to that Destination-Host in that Destination-Realm? --- Joe Harvell Shasta GGSN Development Nortel Networks +1 972.685.4886 From aaa-admin@ietf.org Wed Jan 14 17:18:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17401 for ; Wed, 14 Jan 2004 17:18:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgtKr-0004C0-9E; Wed, 14 Jan 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgtKB-00048M-Fd for aaa@optimus.ietf.org; Wed, 14 Jan 2004 17:17:19 -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 RAA17243 for ; Wed, 14 Jan 2004 17:17:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgtK7-0005oM-00 for aaa@ietf.org; Wed, 14 Jan 2004 17:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgtJ5-0005i7-00 for aaa@ietf.org; Wed, 14 Jan 2004 17:16:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AgtIW-0005es-02 for aaa@ietf.org; Wed, 14 Jan 2004 17:15:36 -0500 Received: from adsl-66-141-49-69.dsl.austtx.swbell.net ([66.141.49.69]) by mx2.foretec.com with smtp (Exim 4.24) id 1Agt7N-0008FJ-U4 for aaa@ietf.org; Wed, 14 Jan 2004 17:04:06 -0500 Received: from [149.122.222.232] by adsl-66-141-49-69.dsl.austtx.swbell.net with ESMTP id <524387-24124> for ; Wed, 14 Jan 2004 11:22:51 +0500 Message-ID: From: "Nelda Chandler" Reply-To: "Nelda Chandler" To: aaa@ietf.org Date: Wed, 14 Jan 2004 11:22:51 GMT X-Mailer: Mymy mail EVAL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BC2A_4.44A3.61E3F4" 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=7.7 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, FROM_ENDS_IN_NUMS,HTML_70_80,HTML_FONTCOLOR_BLUE,HTML_FONT_BIG, HTML_FONT_INVISIBLE,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 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_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 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 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Subject: [Aaa] Easily copy all your dvd movies with your cd burner and watch them with supreme picture cologne 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: , --BC2A_4.44A3.61E3F4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Easy DVD KIT

<= i>Easy DVD KIT zero  

Easy DVD KIT is a powerful tool to COPY DVD movies to ouvre
VCD/SVCD with just one click on your PC! = soul
Copy DVD movies to CD-R discs, convert DVD to VCD/SVCD, with rubicund
BACKUP-DVD it couldn't be easier! (se= e more) = sat
wobble

Copying a DVD is not difficult at all. Our guide includes detailed candid
instructions and , which are easy to follow, even for a beginner! (see more) metcalf=
swung

Learn how to burn DVD's onto regular CD-R Discs! = blazon
Watch your new movies on any DVD player! = dirac
not just the computer DVD! (se= e more) devour

Copy DVD movies using your CD writer with just one click: paso
Put DVD into the DVD drive, a blank CDR in the CD writer, click piddle
"Start" and go!  Support DVD to VCD image, VCD image to CDR= W pokerface
Support almost all popular CD writers. (se= e more) mayhem

&= nbsp;           &nb= sp;            = ;   deluxe

EASY DVD KIT  is the Best!! Make quality backups of your ardency
personal DVDs. Create your own DVD library. Never worry traversal
about scratching or losing a DVD again! temporary

DOW= NLOAD NOW ! bostonian

worksheet
Easy DVD KIT

drill


vlvxl aomve nhqr csylanj w ch gqm --BC2A_4.44A3.61E3F4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Jan 14 17:19:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17450 for ; Wed, 14 Jan 2004 17:19:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgtM3-0004QG-Jo for aaa-archive@odin.ietf.org; Wed, 14 Jan 2004 17:19:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EMJFcV016994 for aaa-archive@odin.ietf.org; Wed, 14 Jan 2004 17:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgtM3-0004Q1-CG for aaa-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 17:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17446 for ; Wed, 14 Jan 2004 17:19:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgtM0-0005y1-00 for aaa-web-archive@ietf.org; Wed, 14 Jan 2004 17:19:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgtL3-0005uR-00 for aaa-web-archive@ietf.org; Wed, 14 Jan 2004 17:18:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgtKr-0004C0-9E; Wed, 14 Jan 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgtKB-00048M-Fd for aaa@optimus.ietf.org; Wed, 14 Jan 2004 17:17:19 -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 RAA17243 for ; Wed, 14 Jan 2004 17:17:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgtK7-0005oM-00 for aaa@ietf.org; Wed, 14 Jan 2004 17:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgtJ5-0005i7-00 for aaa@ietf.org; Wed, 14 Jan 2004 17:16:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AgtIW-0005es-02 for aaa@ietf.org; Wed, 14 Jan 2004 17:15:36 -0500 Received: from adsl-66-141-49-69.dsl.austtx.swbell.net ([66.141.49.69]) by mx2.foretec.com with smtp (Exim 4.24) id 1Agt7N-0008FJ-U4 for aaa@ietf.org; Wed, 14 Jan 2004 17:04:06 -0500 Received: from [149.122.222.232] by adsl-66-141-49-69.dsl.austtx.swbell.net with ESMTP id <524387-24124> for ; Wed, 14 Jan 2004 11:22:51 +0500 Message-ID: From: "Nelda Chandler" Reply-To: "Nelda Chandler" To: aaa@ietf.org Date: Wed, 14 Jan 2004 11:22:51 GMT X-Mailer: Mymy mail EVAL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BC2A_4.44A3.61E3F4" 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=7.7 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, FROM_ENDS_IN_NUMS,HTML_70_80,HTML_FONTCOLOR_BLUE,HTML_FONT_BIG, HTML_FONT_INVISIBLE,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 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_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 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 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Subject: [Aaa] Easily copy all your dvd movies with your cd burner and watch them with supreme picture cologne 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: , --BC2A_4.44A3.61E3F4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Easy DVD KIT

<= i>Easy DVD KIT zero  

Easy DVD KIT is a powerful tool to COPY DVD movies to ouvre
VCD/SVCD with just one click on your PC! = soul
Copy DVD movies to CD-R discs, convert DVD to VCD/SVCD, with rubicund
BACKUP-DVD it couldn't be easier! (se= e more) = sat
wobble

Copying a DVD is not difficult at all. Our guide includes detailed candid
instructions and , which are easy to follow, even for a beginner! (see more) metcalf=
swung

Learn how to burn DVD's onto regular CD-R Discs! = blazon
Watch your new movies on any DVD player! = dirac
not just the computer DVD! (se= e more) devour

Copy DVD movies using your CD writer with just one click: paso
Put DVD into the DVD drive, a blank CDR in the CD writer, click piddle
"Start" and go!  Support DVD to VCD image, VCD image to CDR= W pokerface
Support almost all popular CD writers. (se= e more) mayhem

&= nbsp;           &nb= sp;            = ;   deluxe

EASY DVD KIT  is the Best!! Make quality backups of your ardency
personal DVDs. Create your own DVD library. Never worry traversal
about scratching or losing a DVD again! temporary

 DOW= NLOAD NOW ! bostonian

worksheet
Easy DVD KIT

drill


vlvxl aomve nhqr csylanj w ch gqm --BC2A_4.44A3.61E3F4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Jan 15 07:14: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 HAA00673 for ; Thu, 15 Jan 2004 07:14:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71E3291213; Thu, 15 Jan 2004 07:14:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DC01912A1; Thu, 15 Jan 2004 07:14: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 2346791213 for ; Thu, 15 Jan 2004 07:14:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02FE45DDFB; Thu, 15 Jan 2004 07:14:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1BF465DD90 for ; Thu, 15 Jan 2004 07:14:18 -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 i0FCEG216910 for ; Thu, 15 Jan 2004 14:14:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 14:14:16 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 14:14:15 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 14:14: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: [AAA-WG]: WGLC on the Diameter Credit Control Application Date: Thu, 15 Jan 2004 14:14:15 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPayGsMnJiZ2feZRyqksvpJhfifegAl00oQ From: To: X-OriginalArrivalTime: 15 Jan 2004 12:14:15.0583 (UTC) FILETIME=[17E6FAF0:01C3DB61] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable The AAA Working Group chairs would like to make an announcement of AAA = WG last call=20 on: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-02.txt This draft is a Standards Track document. Please send comments on this document to the AAA WG mailing list, on or before January 29, 2005.=20 As with other AAA WG documents, issues are to be submitted using the following template: Issue Number: Get_An_Issue_Number_From_Pat Description of issue: Submitter name: Your_Name_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [CCA] Comment type: ['T'echnical | 'E'ditorial ] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issues:=20 Description_of_Problem_Goes_Here Requested change:=20 Proposal_Goes_Here_With_Specific_Text As with all working group last calls, the draft will be updated = according to working group consensus on issues submitted. =20 thanks,=20 Bernard, Dave & John From owner-aaa-wg@merit.edu Thu Jan 15 07:43: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 HAA01607 for ; Thu, 15 Jan 2004 07:43:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2AFE9912A1; Thu, 15 Jan 2004 07:43:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0B6D912A2; Thu, 15 Jan 2004 07:43: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 DAB06912A1 for ; Thu, 15 Jan 2004 07:43:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id C7E4F5DE9F; Thu, 15 Jan 2004 07:43:28 -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 D991A5DE92 for ; Thu, 15 Jan 2004 07:43:27 -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 i0FChQ226058 for ; Thu, 15 Jan 2004 14:43:26 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 14:43:26 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 14:43:25 +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]: WGLC on the Diameter Credit Control Application Date: Thu, 15 Jan 2004 14:43:25 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPayGsMnJiZ2feZRyqksvpJhfifegAl00oQAAFYtTA= From: To: , X-OriginalArrivalTime: 15 Jan 2004 12:43:25.0675 (UTC) FILETIME=[2B09D3B0:01C3DB65] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Obviously, I meant that the WGLC will run until January 29, 2004! thanks, John > The AAA Working Group chairs would like to make an=20 > announcement of AAA WG last call=20 > on: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-02.txt >=20 > This draft is a Standards Track document. Please send comments on this > document to the AAA WG mailing list, on or before January 29, 2005.=20 >=20 > As with other AAA WG documents, issues are to be submitted using the > following template: >=20 > Issue Number: Get_An_Issue_Number_From_Pat > Description of issue: > Submitter name: Your_Name_Here > Date first submitted: Insert_Date_Here > Reference: URL to e-mail describing problem, if available > Document: Document Requiring change [CCA] > Comment type: ['T'echnical | 'E'ditorial ] > Priority: ['S' Must fix | '1' Should fix | '2' May fix ] > Section: Insert_Section_Number_Here > Rationale/Explanation of issues:=20 >=20 > Description_of_Problem_Goes_Here >=20 > Requested change:=20 >=20 > Proposal_Goes_Here_With_Specific_Text >=20 > As with all working group last calls, the draft will be=20 > updated according > to working group consensus on issues submitted. =20 >=20 > thanks,=20 > Bernard, Dave & John >=20 From owner-aaa-wg@merit.edu Thu Jan 15 07:47: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 HAA01722 for ; Thu, 15 Jan 2004 07:47:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6BF70912C6; Thu, 15 Jan 2004 07:47:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1ADF8912CE; Thu, 15 Jan 2004 07:47: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 683EB912C6 for ; Thu, 15 Jan 2004 07:47:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4038B5DE39; Thu, 15 Jan 2004 07:47:02 -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 64B0C5DDC6 for ; Thu, 15 Jan 2004 07:47:01 -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 i0FCl0200975 for ; Thu, 15 Jan 2004 14:47:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 14:47:00 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 14:46:59 +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: Issue: DCC Multiple services in a user's session, independent quotas Date: Thu, 15 Jan 2004 14:46:42 +0200 Message-ID: Thread-Topic: Issue: DCC Multiple services in a user's session, independent quotas Thread-Index: AcPWhg+0TlEcWW3CS52nRHrUmCqmHwE34wdQ From: To: , Cc: , , X-OriginalArrivalTime: 15 Jan 2004 12:46:59.0756 (UTC) FILETIME=[AAA3FEC0:01C3DB65] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned issue 8. John > -----Original Message----- > From: ext Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] > Sent: 09 January, 2004 09:55 > To: aaa-wg@merit.edu > Cc: Stura Marco (Nokia-NET/Helsinki); Loughney John > (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); Leena > Mattila (TU/LMF) > Subject: Issue: DCC Multiple services in a user's session, independent > quotas >=20 >=20 > Multiple services in a user's session, independent quotas. >=20 > Submitter name: Harri Hakala > Submitter email address: harri.hakala@ericsson.com > Date first submitted: 09.01.2004 > Reference: > Document: Diameter CCA-02 > Comment type: T > Priority: 2 > Section: > Rationale/Explanation of issue: >=20 > Couple of mail threads took already place to discuss the=20 > multiple services=20 > support in one user's session. There has been a lot of=20 > confusion around the=20 > Issue 436 (Multiple services credit control in a single CC=20 > session) and=20 > consequent attempts to mirror all the command level=20 > functionalities to the=20 > G-S-U level in order to create independent credit control=20 > sub-sessions=20 > embedded in a credit control session. The idea behind Issue=20 > 436 (Multiple=20 > services credit control in a single CC session) was to avoid=20 > multiple credit=20 > control sub-sessions and use just ONE single quota for=20 > multiple services and=20 > thus avoid increased signalling load and resource usage in both the=20 > CC-client and in the CC-server as discussed in=20 > http://www.merit.edu/mail.archives/aaa-wg/msg00066.html. However,=20 > independent quotas concept for the support of multiple=20 > services credit=20 > control in a user's session is fully supported in the current=20 > DCC (draft 02)=20 > by using credit control sub-session according to the=20 > sub-session concept=20 > defined in RFC 3588. Therefore creating yet another option to support=20 > sub-sessions, not according RFC 3588, is not appropriate and,=20 > among other,=20 > would introduce interoperability concerns. > Requirements for independent quotas was brought in=20 > http://www.merit.edu/mail.archives/aaa-wg/msg00064.html,=20 > those requirements=20 > are already met by the DCC draft 02 as discussed in=20 > http://www.merit.edu/mail.archives/aaa-wg/msg00067.html. >=20 > There is need to clarify: >=20 > 1- that the DCC standard doesn't mandate a client to=20 > implement one or the=20 > other approach. > 2- that a server implementing multiple services credit=20 > control in a user's=20 > session should support cc sub-sessions as well as the=20 > approach described in=20 > issue 436. > 3- how to use sub-sessions to handle independent quotas. >=20 > Proposed changed: >=20 > Change fifth paragraph in section 5 > FROM >=20 > When multiple services are used within one user session and each > service or group of services are subject to different=20 > cost, making use > of credit control sub-sessions will result in increased=20 > signaling load > and resources usage in both the credit control client and=20 > 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=20 > 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=20 > allocation. It is > also possible to request and allocate multiple quotas on a=20 > per service > basis. The mechanism is illustrated in Appendix A (Flow X). >=20 > TO >=20 > When multiple services are used within one user session and each > service or group of services are subject to different=20 > cost, making use > of credit control sub-sessions will result in increased=20 > signaling load > and resources usage in both the credit control client and=20 > 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=20 > 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=20 > allocation. It is > also possible to request and allocate multiple quotas on a=20 > per service > basis. Note that this concept implies that one single=20 > credit reservation > is kept and allocated to all the services/rating groups,=20 > all the quotas > are derived from that credit reservation assuming a given=20 > service/rating > group consume the whole amount. Therefore all the possible quotas > conveyed to the Diameter Credit control client are not=20 > independent entities > as such. An example of this mechanism is illustrated in=20 > Appendix A (Flow X). >=20 > Implementations of a credit control client supporting =20 > multiple services > within one user session may want to request independent quotas > to the credit control server. This is achieved through=20 > credit control > sub-sessions, which enables for independent control of each of the > allotted quotas at the cost, however, of increased=20 > signaling load and > resource usage in both the client and the server. An example of > credit control sub-sessions is illustrated in Appendix A (Flow XI). > What mechanism a client supports is an implementation choice. > A credit control server implementing multiple services=20 > credit control in > one user's session SHOULD have capabilities to allocate independent > quotas as well as derive all the possible quotas from one=20 > single credit > reservation as discussed in the previous paragraph. The=20 > server deduces > whether independent quotas are requested by the existence of > sub-sessions. >=20 > ADD Flow XI in Appendix A >=20 > A.11 Flow XI >=20 > Service Element > End-User (CC client) CC Server > |(1)User logon | | > |------------------>|(2)CCR(initial, Service-Id(access)) =20 > | =20 > | |---------------------------------------->| > | |(3)CCA(Granted-Units(Time)) | > | |<----------------------------------------| > : : : > |(4)Service-Request (Service 1) | > |------------------>|(5)CCR(initial,sub-session 1, | > | | Requested-Units(Rating-Group 1)) | > | |---------------------------------------->| > | |(6)CCA(Granted-Units(Rating-Group 1, | > | | Total-Octets)) | > | |<----------------------------------------| > : : : > |(7)Service-Request (Service 2) | > |------------------>| | > : : : > : : : > | |(8)CCR(update,Service-Id(access), | > | | Used-Units(Time, | > | | Service-Id(access)) | =20 > | |---------------------------------------->| > | |(9)CCA(Granted-Units(Time)) | > | |<----------------------------------------| > | +----------------------+ | > | | (10)Validity-Time | | > | | sub-session 1 expires| | > | +----------------------+ | > | |(11)CCR(update,sub-session 1, | > | | Used-Units(Input-Octets, | > | | Output-Octets, | > | | Service-Id 1, | > | | Rating-Group 1),| > | | Used-Units(Input-Octets, | > | | Output-Octets, | > | | Service-Id 2, | > | | Rating-Group 1),| > | | Requested-Units(Rating-Group 1))| > | |---------------------------------------->| > | | (12)CCA(Result-Code 4010)| > | |<----------------------------------------| > : : : > |(13) User logoff | | > |------------------>|(14)CCR(term, Used-Units(Time, | > | | Service-Id(access))) | =20 > | |---------------------------------------->| > | |(15)CCA(term) | > | |<----------------------------------------| >=20 > Figure A.11: Credit Control for Multiple Services in One User's > session, credit control sub-sessions. >=20 > Figure A.11 is an example of credit control for multiple=20 > services in one user's session making use of credit control=20 > sub-sessions. In contrast with flow x, the credit control=20 > client is requesting independent quotas per each of the=20 > services. In order to avoid allocation of resources to unused=20 > services, the client triggers credit authorization and starts=20 > a credit control sub-session only when the end-user requests=20 > a service that belongs to a rating group for which quota has=20 > not been authorized. The server sets the Validity-Time to a=20 > suitable value to control unused units. >=20 > It is assumed that the Service-Identifiers and the=20 > Rating-Groups are locally configured in the Service Element=20 > or provisioned by another entity than the credit control server. =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 access (e.g. internet=20 > access) and to establish a credit control session (2). In=20 > this message credit authorization is requested for the access=20 > by including the Service-Identifier AVP equal to=20 > "access@provider.com". The Diameter credit-control server=20 > checks the end user's account balance, based on=20 > Service-Identifier, rates the request and may reserve credit=20 > from the end user's account if the access fee as such is chargeable. > A quota can be returned to the Service Element (3). The user=20 > now start using Service 1 (4) that belongs to a=20 > non-authorized rating group (Rating-Group 1), thus the credit=20 > control client initiates a sub-session to request an=20 > individual quota for Rating-Group 1 (5). A quota is returned=20 > to the Service Element (6). > The user uses Service 2 as well, that belongs to Rating-Group=20 > 1 (7). The client utilizes then credit resources allocated in step 6.=20 > When the user has consumed the credit allocated to the=20 > access, the Service Element sends a Diameter=20 > Credit-Control-Request with CC-Request-Type set to=20 > UPDATE_REQUEST to the credit control server (8). This message=20 > contains the units used for the internet access in the=20 > Used-Service-Unit AVP and the Service-Identifier AVP to=20 > request credit re-authorization for the main credit control=20 > session. The Diameter credit-control server debits the used=20 > units from the end user's account and reserves a new amount=20 > of credit that is returned to the Service Element in the=20 > Diameter Credit-Control-Answer (9).=20 >=20 > Since the end-user is not consuming resources from=20 > Rating-Group 1 anymore, the Validity-Time of the credit=20 > control sub-session expires (10). The Service Element sends a=20 > Diameter Credit-Control-Request with CC-Request-Type set to=20 > UPDATE_REQUEST to the credit control server (11). This=20 > message contains the units consumed by each of the used=20 > services in the Used-Service-Unit AVPs. The used units are=20 > associated with the relevant Service-Identifier and=20 > Rating-Group. In this message credit re-authorization is=20 > requested for Rating-Group 1 by including the=20 > Requested-Service-Unit AVP. The Diameter credit-control=20 > server debits the used units to the user's account and, based=20 > on server specific policy, determines that credit=20 > re-authorization for Rating-Group 1 is denied because of user=20 > inactivity. The server returns then a failed Diameter=20 > Credit-Control-Answer with Result-Code AVP set to the value=20 > 4010 (DIAMETER_END_USER_SERVICE_DENIED) to deny all the=20 > traffic related to Rating-Group 1 ! > and close the sub-session (12). >=20 > The end user logs off from the network (13). 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 (14). This=20 > message contains the units consumed by the main credit=20 > control session in the Used-Service-Unit AVP. The used units=20 > are associated with the relevant Service-Identifier. The=20 > Diameter credit-control server debits the used units to the=20 > user's account and acknowledges the session termination by=20 > sending a Diameter Credit-Control-Answer to the Service Element (15). >=20 From owner-aaa-wg@merit.edu Thu Jan 15 12:59:27 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 MAA17323 for ; Thu, 15 Jan 2004 12:59:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0C49912AE; Thu, 15 Jan 2004 12:59:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE51C912AF; Thu, 15 Jan 2004 12:59: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 DDD06912AE for ; Thu, 15 Jan 2004 12:59:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA14C5DE9B; Thu, 15 Jan 2004 12:59:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 5689A5DE6C for ; Thu, 15 Jan 2004 12: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 i0FHx1n09423; Thu, 15 Jan 2004 09:59:01 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Jan 2004 11:59:00 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8DDD@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , aaa-wg@merit.edu Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quo tas Date: Thu, 15 Jan 2004 11:58:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DB91.3F6D1480" 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_01C3DB91.3F6D1480 Content-Type: text/plain Hi Harri, I added some comments about this issue below. Cheers, Chris. Shasta Wireless Development Nortel Networks -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Monday, January 12, 2004 7:59 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Cc: marco.stura@nokia.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Leena Mattila (TU/LMF) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quo tas Hi Chris, >I'm not sure we can assume that all the resources given to a user >originate from the same resource account. As you suggested, they may be >completely independent. But that should not require the use of a >sub-session. >Besides, how will a client know that a resource may be provided from a >different >pool and so know to use a new sub-session? If the server has the knowledge of what >resources come from what pools, the use of the sub-session can only be done after >the request has been made by the client. We have stated that the Service-Identifiers and Rating-Groups are locally configured in the Service Element or provisioned by some other entity. That is, all the services subject to the same rating type and account shall be part of the same Rating-Group and all the services subject to the same Rating-Group can use same sub-session. Alternatively the client can start an own sub-session for each service, and thus let the server to handle the combination of the quotas, if needed. [CR] So the current proposal is to provision on each client node, which services WILL use resources from the same resource pool? Therefore each client node must know in advance exactly what resource pools exist for all potential users and service providers? And, that this grouping is not dynamic or expected to change too often? Sounds a bit unrealistic to me. Each time a new resource pool is created, it may mean going to each client node and re-assigning existing groupings. Imagine a tariff architecture where the resource pools available to users is constantly being modified (Special offers from operator or 3rd party service providers, etc) - each time this happens, the operator must go into each client and modify the entire rating groups? Sounds unworkable to me. I do not think that the DCC client should know in advance what resource pool some rated service usage should come from - which is what the document currently suggests. That's the domain of the charging system (OCS, etc). [End CR] >Alternatively, instead of treating independent quotas as independent >sub-sessions (Thus achieving quota independence), it seems simpler and >easier and more efficient to treat quotas independently within the same >sub-session. > >By that I mean each quota should include all the information relative >to it (result code, redirect info, tariff time change, etc). Also saves >the extra messaging. I disagree that it is simpler and easier to treat quotas independently within the same "sub"-session. This means that you should report/request quotas also independently, i.e. to handle these quotas by using independent CCR/CCA commands, and thus having sort of sub-session within sub-session and/or session. For instance in fault situations, e.g. transport failure, to handle these independent quotas would make the procedures and state machines very complicated. [CR] Do not think of different rated services as different sub-sessions. This is not correct. An operator may specify many thousands of rated services. Leave it up to the Charging system (OCS) to determine where and how the resources for some traffic. It is not the job of the client to have this information. [End CR] In addition, creating sort of sub-session within sub-session and/or session introduces yet another option to support sub-sessions and increases the complexity of the system. The way of supporting sub-sessions in Diameter is outlined in RFC3588, we just need to align with RFC3588. This is exactly what the issue does. As already discussed many times you are proposing to create sub-sessions embedded in a Diameter session, but isn't it much better and cleaner also for the service handling to explicitly signal sub-sessions according RFC3588 without re-inventing the wheel. [CR] I'm not proposing re-inventing the wheel. With DCC, we have a chance to specify a flexible and extensible (And usable) protocol. I do not think the current draft is either a better or cleaner solution by using sub-sessions in this way. [End CR] >Sub-sessions have a different meaning in the 3G world. A single user >session may have a number of (sub) secondary sessions. I guess you are referring to secondary PDP Contexts. Secondary PDP contexts would just trigger a DCC sub-session carrying different QoS attributes for rating purposes etc (just another service) that would close when the secondary PDP context close. [CR] But with the current scheme, a single PDP context may have multiple sub-sessions. Adding secondary PDP contexts for the same session, we end up with many sub-sessions: some for the same PDP context and some for the other PDP context. It will make trying to correlate all these sub-sessions with each other and with the user session a whole lot more complicated. [End CR] Regards......Harri ------_=_NextPart_001_01C3DB91.3F6D1480 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quo tas

Hi Harri,

I added some comments about this issue below.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: Monday, January 12, 2004 7:59 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Cc: marco.stura@nokia.com; john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; Leena Mattila (TU/LMF)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services = in a user's session, i ndependent quo tas


Hi Chris,

>I'm not sure we can assume that all the resources = given to a user
>originate from the same resource account. As you = suggested, they may be
>completely independent. But that should not = require the use of a
>sub-session.

>Besides, how will a client know that a resource = may be provided from a
>different
>pool and so know to use a new sub-session? If = the server has the knowledge of what
>resources come from what pools, the use of the = sub-session can only be done after
>the request has been made by the client.

We have stated that the Service-Identifiers and = Rating-Groups are locally
configured in the Service Element or provisioned by = some other entity. That is, all the services subject to the same rating = type and account shall be part of the same Rating-Group and all the = services subject to the same Rating-Group can use same = sub-session.

Alternatively the client can start an own sub-session = for each service, and
thus let the server to handle the combination of the = quotas, if needed.

[CR]
So the current proposal is to provision on each = client node, which services WILL use resources from the same  = resource pool?

Therefore each client node must know in advance = exactly what resource pools exist for all potential users and service = providers?

And, that this grouping is not dynamic or expected to = change too often?

Sounds a bit unrealistic to me. Each time a new = resource pool is created, it may mean going to each client node and = re-assigning existing groupings.

Imagine a tariff architecture where the resource = pools available to users is constantly being modified (Special offers = from operator or 3rd party service providers, etc) - each time this = happens, the operator must go into each client and modify the entire = rating groups?

Sounds unworkable to me. I do not think that the DCC = client should know in advance what resource pool some rated service = usage should come from - which is what the document currently suggests. = That's the domain of the charging system (OCS, etc).

[End CR]

>Alternatively, instead of treating independent = quotas as independent
>sub-sessions (Thus achieving quota = independence), it seems simpler and
>easier and more efficient to treat quotas = independently within the same
>sub-session.
>
>By that I mean each quota should include all the = information relative
>to it (result code, redirect info, tariff time = change, etc). Also saves
>the extra messaging.

I disagree that it is simpler and easier to treat = quotas independently within the
same "sub"-session. This means that you = should report/request quotas also independently, i.e. to handle these = quotas by using independent CCR/CCA commands, and thus having sort of = sub-session within sub-session and/or session. For instance in fault = situations, e.g.

transport failure, to handle these independent quotas = would make the procedures and state
machines very complicated.

[CR]
Do not think of different rated services as = different sub-sessions. This is not correct. An operator may specify = many thousands of rated services. Leave it up to the Charging system = (OCS) to determine where and how the resources for some traffic. It is = not the job of the client to have this information.

[End CR]

In addition, creating sort of sub-session within = sub-session and/or session introduces yet another option to support = sub-sessions and increases the complexity of the system. The way of = supporting sub-sessions in Diameter is outlined in RFC3588, we just = need to

align with RFC3588. This is exactly what the issue = does.

As already discussed many times you are proposing to = create sub-sessions embedded in a Diameter session, but isn't it much = better and cleaner also for the service handling to explicitly signal = sub-sessions according RFC3588 without re-inventing the wheel. =

[CR]
I'm not proposing re-inventing the wheel. With DCC, = we have a chance to specify a flexible and extensible (And usable) = protocol. I do not think the current draft is either a better or = cleaner solution by using sub-sessions in this way.

[End CR]

>Sub-sessions have a different meaning in the 3G = world. A single user
>session may have a number of (sub) secondary = sessions.

I guess you are referring to secondary PDP Contexts. = Secondary PDP contexts would just trigger a DCC sub-session carrying = different QoS attributes for

rating purposes etc (just another service) that would = close when the secondary PDP context close.

[CR]
But with the current scheme, a single PDP context = may have multiple sub-sessions. Adding secondary PDP contexts for the = same session, we end up with many sub-sessions: some for the same PDP = context and some for the other PDP context. It will make trying to = correlate all these sub-sessions with each other and with the user = session a whole lot more complicated.

[End CR]

Regards......Harri


------_=_NextPart_001_01C3DB91.3F6D1480-- From owner-aaa-wg@merit.edu Fri Jan 16 08:36: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 IAA13572 for ; Fri, 16 Jan 2004 08:36:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D14FB912CB; Fri, 16 Jan 2004 08:36:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EB2F912CC; Fri, 16 Jan 2004 08:36: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 581CB912CB for ; Fri, 16 Jan 2004 08:36:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BFEC5DECC; Fri, 16 Jan 2004 08:36:18 -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 A911C5DEC7 for ; Fri, 16 Jan 2004 08:36:17 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0GDaGAh032487; Fri, 16 Jan 2004 14:36:16 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 16 Jan 2004 14:37:52 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Christopher Richards'" , aaa-wg@merit.edu Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Fri, 16 Jan 2004 14:35:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, >[CR] >So the current proposal is to provision on each client node, which services WILL >use resources from the same resource pool? >Therefore each client node must know in advance exactly what resource pools exist >for all potential users and service providers? >And, that this grouping is not dynamic or expected to change too often? >Sounds a bit unrealistic to me. Each time a new resource pool is created, it may >mean going to each client node and re-assigning existing groupings. >Imagine a tariff architecture where the resource pools available to users is constantly >being modified (Special offers from operator or 3rd party service providers, etc) - >each time this happens, the operator must go into each client and modify the entire rating groups? >Sounds unworkable to me. I do not think that the DCC client should know in advance >what resource pool some rated service usage should come from - which is what the document >currently suggests. That's the domain of the charging system (OCS, etc). >[End CR] Due to some special offers why resource pools need to be changed? Rating groups yes, but why resource pools as well? Assuming that resource pools are same as accounts, i.e. subscriber can have several accounts for different services, one account for calls, one for MMS, one for data, etc. I agree that when these parameters are only locally configured it would be quite challenging task to manage all possible changes manually. But although parameters are manually configured, it is still possible to activate/de-activate these parameters dynamically. And in 3G case I think that there is solution how to dynamically identify the service data flows that need to be charged at different rates and the DCC-02 is aligned with the solutions proposed by IP Flow Based Bearer Level Charging. But after all it may be better to let CC server to decide in real time which credit pool shall be used and let server to reserve credit from the right end user's account. The Credit-Pool-Id AVP can be included in the G-S-U so that indication of which Rating-Group/Service require sub-session can be given by the server. The client can then initiate sub-sessions for these Rating-Groups/Services. >I disagree that it is simpler and easier to treat quotas independently within the >same "sub"-session. This means that you should report/request quotas also independently, >i.e. to handle these quotas by using independent CCR/CCA commands, and thus having sort >of sub-session within sub-session and/or session. For instance in fault situations, e.g. >transport failure, to handle these independent quotas would make the procedures and state >machines very complicated. >>[CR] >>Do not think of different rated services as different sub-sessions. This is not correct. An operator >>may specify many thousands of rated services. Leave it up to the Charging system (OCS) to determine >>where and how the resources for some traffic. It is not the job of the client to have this information. >>[End CR] Yes, an operator may specify many thousands of rated services, but it doesn't mean that operator have to have thousands of different rates. I believe that many of these service still use same rates and it is possible (and feasible) to define that all the service subject to the same rating type is part of the same group (rating group) and thus same sub-session can be used to control services which belongs to same rating group. And once again, sub-sessions are a cleaner and easier way to handle fault cases and account re-fill cases (re-direct) compared to the approach of having everything controlled within one session. Also controlling everything within one session would require somehow an instance of the state machine for each of the running quotas, thus emulating explicit sub-sessions. >[CR] >But with the current scheme, a single PDP context may have multiple sub-sessions. Adding secondary >PDP contexts for the same session, we end up with many sub-sessions: some for the same PDP context >and some for the other PDP context. It will make trying to correlate all these sub-sessions with >each other and with the user session a whole lot more complicated. >[End CR] It will be rather easy to have own application specific AVP (e.g. 3GPP AVP) to identify the PDP context. For instance two or more DCC sub-sessions with the same PDP contextId AVP would indicate that services are carried in the same secondary PDP context. I also assume there is still the option to open a new DCC session for the secondary PDP Context and sub-sessions for independent quotas, no? Regards............Harri From owner-aaa-wg@merit.edu Fri Jan 16 12:38:13 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 MAA22612 for ; Fri, 16 Jan 2004 12:38:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19F0F912D7; Fri, 16 Jan 2004 12:38:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB88D912D9; Fri, 16 Jan 2004 12:38: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 BB69F912D7 for ; Fri, 16 Jan 2004 12:38:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id A34E65DED6; Fri, 16 Jan 2004 12:38:00 -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 C9EEA5DEF4 for ; Fri, 16 Jan 2004 12:37:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0GHqd917047; Fri, 16 Jan 2004 09:52:39 -0800 Date: Fri, 16 Jan 2004 09:52:39 -0800 (PST) From: Bernard Aboba To: David Mitton Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: New NASREQ text on DynAuth In-Reply-To: <5.2.1.1.2.20040116111723.03db3b20@getmail.mitton.com> Message-ID: References: <5.2.1.1.2.20040115095318.03212110@getmail.mitton.com> <5.2.1.1.2.20040114103428.039b7bc0@mail.comcast.net> <5.2.1.1.2.20040114103428.039b7bc0@mail.comcast.net> <5.2.1.1.2.20040115095318.03212110@getmail.mitton.com> <5.2.1.1.2.20040116111723.03db3b20@getmail.mitton.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, 16 Jan 2004, David Mitton wrote: > >Since we wrote the "authorize only" stuff in for Diameter compatibility, > >I'm OK with removing it. However, I'm still not clear that Diameter Base > >allows the single transaction model for Reauthorization. > > Okay, I think you're on to something. I've re-read the Base. RAR really > doesn't say much, but RAA says: > "A successful RAA message MUST be followed by an application-specific > authentication and/or authorization message." Yes. My understanding was that the intent was initiate a Request/Response sequence. > However, I find DiamNasReq section 2.2 para 3 already says: > If the Re-Auth-Request-Type is AUTHORIZE_ONLY, the > message will contain AVPs to modify the current service. This seems like a fundamental change in the usage of RAR/RAA, compared to what is defined in the Base protocol. > Sooo... I think we (in the more expansive WG sense) have been here before. As Casey Stengel said "I've made up my mind, but I made it up both ways." NASREQ & Base seem to be in contradiction on the use of RAR/RAA. Personally, my vote is with Base. > Either we extend RAR/RAA explicitly to cover this (which seems to be what > was done, perhaps weakly and obscurely), or we make the extra message > exchange something that the Diameter/RADIUS gateway has to provide. The original discussion on RFC 3576 assumed that an extra exchange was required to accomodate Diameter RAR/RAA behavior. Reading Base, that assumption seems to have be justified. So unless Base was in error, RFC 3576 is correct in this instance, the Diameter/RADIUS gateway needs to accomodate the extra exchange, and NASREQ needs to be compatible with the operation of RAR/RAA defined in Base. > summing up: I am in favor of killing the extra exchange on > Disconnect-Request and declaring it a bug in RFC 3576. This makes sense because ASR/ASA in Diameter is a single transaction, so I think that NASREQ is correct here, and RFC 3576 is wrong. > I'm in favor of this one step RAR message, but perhaps we should test that. > The text in 2.2 should be beefed up a bit... which segues in to the next > topic.... Unless the one-step RAR message is defined in Base, I don't think that NASREQ can change the nature of the Base RAR/RAA exchange this way. Also, RFC 3576 describes why a one-step RAR message is problematic. The issue is semantic ambiguity -- is a given AVP used for session identification or authorization change? The two-step exchange is cleaner in that respect. > More ABNFs? > Do we want to "describe" all NAS applications usage of Base messages with > an ABNF? > This would include: Re-Auth;RAR/RAA, Session-Termination;STR/STA, > Session-Abort; ASR/ASA, Accounting;ACR/ACA Adds up real quick. > > I don't think it's real hard to write, but it will add several pages of text. > > Final summary: > With my "Protocol Architect" hat on, I like the completeness and > clarity this would add. I agree. Frankly, the confusion over usage of RAR/RAA and other commands is likely to become a stumbling block if we don't fix this now. > I'll work issue 431 until I'm ready to commit on this one. Let's see what other members of the AAA WG have to say on this one. From owner-aaa-wg@merit.edu Mon Jan 19 05:23: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 FAA10854 for ; Mon, 19 Jan 2004 05:23:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 386C991240; Mon, 19 Jan 2004 05:22:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 020C491244; Mon, 19 Jan 2004 05:22: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 CDB6E91240 for ; Mon, 19 Jan 2004 05:22:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7CDA5DDBF; Mon, 19 Jan 2004 05:22: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 0C8DB5DDFF for ; Mon, 19 Jan 2004 05:22:53 -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 i0JAMkY06596 for ; Mon, 19 Jan 2004 12:22:46 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 19 Jan 2004 12:22:46 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 19 Jan 2004 12:22:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Re: New NASREQ text on DynAuth Date: Mon, 19 Jan 2004 12:22:44 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03C0@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: New NASREQ text on DynAuth Thread-Index: AcPcV4xZMY7qSd1jTgCzQAKM5Hb6QQCHeRlQ From: To: , Cc: X-OriginalArrivalTime: 19 Jan 2004 10:22:45.0112 (UTC) FILETIME=[2DB91F80:01C3DE76] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > > However, I find DiamNasReq section 2.2 para 3 already says: > > If the Re-Auth-Request-Type is AUTHORIZE_ONLY, the > > message will contain AVPs to modify the current service. >=20 > This seems like a fundamental change in the usage of RAR/RAA,=20 > compared to > what is defined in the Base protocol. Yes, I'm of the same opinion. The RAR/RAA in Base protocol is=20 designed to initiate an application specific Request/Answer sequence. > > Sooo... I think we (in the more expansive WG sense) have=20 > been here before. >=20 > As Casey Stengel said "I've made up my mind, but I made it up=20 > both ways." > NASREQ & Base seem to be in contradiction on the use of RAR/RAA. > Personally, my vote is with Base. I'm in support of the base as well. Br Marco From owner-aaa-wg@merit.edu Mon Jan 19 14:14: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 OAA02908 for ; Mon, 19 Jan 2004 14:14:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7033E91226; Mon, 19 Jan 2004 14:13:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37FAE9124E; Mon, 19 Jan 2004 14:13: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 0399B91226 for ; Mon, 19 Jan 2004 14:13:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA9AF5DE77; Mon, 19 Jan 2004 14:13:45 -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 5820D5DFA8 for ; Mon, 19 Jan 2004 14:13:45 -0500 (EST) Received: from zrc2c010.us.nortel.com (zrc2c010.us.nortel.com [47.103.120.50]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0JJDbO25330 for ; Mon, 19 Jan 2004 13:13:37 -0600 (CST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c010.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C6CH41G1; Mon, 19 Jan 2004 13:13:38 -0600 Received: from nortelnetworks.com (harvell-3.us.nortel.com [47.102.209.53]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C0CLNL8Q; Mon, 19 Jan 2004 13:13:38 -0600 Message-ID: <400C2C27.2060306@nortelnetworks.com> Date: Mon, 19 Jan 2004 13:12:39 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell Organization: Nortel Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 StumbleUpon/1.89 X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Client request routing 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 I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based Routing Table), 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of Diameter Base Protocol, and I am a little confused about how a Diameter Peer is to be selected for sending a request from a Diameter Client. Consider the case of a Diameter Client that does not implement Diameter Peer Discovery. This means that Diameter Peers are statically configured. The Capabilities Exchange process will definitely identify the Realm and Host of each Diameter Peer. However, the only cases in which a peer can be identified as a candidate next hop for sending a particular request are as follows: 1) when its Realm matches the Destination-Realm of a message with Destination-Realm only; and 2) when its Realm and Host match the Destination-Realm and Destination-Host of a message with a Destination-Realm and Destination-Host. So how does a Diameter Client identify a candidate peer for sending messages in the other cases? Section 5.1 indicates that a Diameter Node should have established connections with a minimum of two (a primary and possibly multiple secondary) peers per realm. Does the "realm" in this context mean that both peers are members of the same realm, or that both peers can route messages to a given Destination-Realm? Can Diameter Agents forward requests for a Destination-Realm that is not their Realm? When a Diameter Client has a request with a Destination-Realm and Destination-Host, will all the primary and secondary peers described in 5.1 be able to route the request to that Destination-Host in that Destination-Realm? --- Joe Harvell Shasta GGSN Development Nortel Networks +1 972.685.4886 From owner-aaa-wg@merit.edu Mon Jan 19 15:02: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 PAA05115 for ; Mon, 19 Jan 2004 15:02:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0DB89124E; Mon, 19 Jan 2004 15:02:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA7BC9124F; Mon, 19 Jan 2004 15:02: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 9EBFB9124E for ; Mon, 19 Jan 2004 15:02:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 883845DDB4; Mon, 19 Jan 2004 15:02:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id EDE765DDC2 for ; Mon, 19 Jan 2004 15:02:29 -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 i0JK2Je27988; Mon, 19 Jan 2004 12:02:19 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Jan 2004 14:02:19 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8DFA@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Harri Hakala (TU/LMF)'" , aaa-wg@merit.edu Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, "Leena Mattila (TU/LMF)" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Mon, 19 Jan 2004 14:02:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DEC7.23B6C6A8" 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_01C3DEC7.23B6C6A8 Content-Type: text/plain Hi Harri, I guess we still disagree with the concept of sessions and sub-sessions and the independence of quotas within a session. Some more examples and comments below. Also, to give you some background: I come from a 3GPP background. Currently, 3GPP have defined procedures for enabling the network to rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) AS WELL AS WAP and HTTP (I.e. URI information). I understand from your colleagues that you are tackling DCC from an IMS development stance. That may explain why we have some disconnect. Best Regards, Chris. -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: Friday, January 16, 2004 7:35 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Cc: marco.stura@nokia.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; Leena Mattila (TU/LMF) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Chris, >[CR] >So the current proposal is to provision on each client node, which services WILL >use resources from the same resource pool? >Therefore each client node must know in advance exactly what resource pools exist >for all potential users and service providers? >And, that this grouping is not dynamic or expected to change too often? >Sounds a bit unrealistic to me. Each time a new resource pool is created, it may >mean going to each client node and re-assigning existing groupings. >Imagine a tariff architecture where the resource pools available to users is constantly >being modified (Special offers from operator or 3rd party service providers, etc) - >each time this happens, the operator must go into each client and modify the entire rating groups? >Sounds unworkable to me. I do not think that the DCC client should know in advance >what resource pool some rated service usage should come from - which is what the document >currently suggests. That's the domain of the charging system (OCS, etc). >[End CR] Due to some special offers why resource pools need to be changed? Rating groups yes, but why resource pools as well? Assuming that resource pools are same as accounts, i.e. subscriber can have several accounts for different services, one account for calls, one for MMS, one for data, etc. [CR2] Imagine that a 3rd party content provider makes an agreement with the network operator: "I'll pay the network operator for any bearer traffic used by it's subscribers to my web site - but only next Friday (Big promotion coming up)". The resources should be taken from the 3rd party content providers pool - which is only valid next Friday. I agree that when these parameters are only locally configured it would be quite challenging task to manage all possible changes manually. But although parameters are manually configured, it is still possible to activate/de-activate these parameters dynamically. And in 3G case I think that there is solution how to dynamically identify the service data flows that need to be charged at different rates and the DCC-02 is aligned with the solutions proposed by IP Flow Based Bearer Level Charging. But after all it may be better to let CC server to decide in real time which credit pool shall be used and let server to reserve credit from the right end user's account. The Credit-Pool-Id AVP can be included in the G-S-U so that indication of which Rating-Group/Service require sub-session can be given by the server. The client can then initiate sub-sessions for these Rating-Groups/Services. [CR2] Why make it even more complicated to solve this problem. Now the CC server needs to send back an indicator that the client needs to track so that it knows when to use a sub-session or not. It is simply side-stepping the issue by making it more complicated. A session is a session - not a type of content or resource. Resources used by that session should use that session. The quotas on the client track resource usage. The CC server is the place to track service usage by these sessions and charge (Or not) appropriately. It should not be the responsibility of the CC client to start doing the work of the server. >I disagree that it is simpler and easier to treat quotas independently >within the >same "sub"-session. This means that you should report/request quotas also independently, >i.e. to handle these quotas by using independent CCR/CCA commands, and thus having sort >of sub-session within sub-session and/or session. For instance in fault situations, e.g. >transport failure, to handle these independent quotas would make the procedures and state >machines very complicated. >>[CR] >>Do not think of different rated services as different sub-sessions. This is not correct. An operator >>may specify many thousands of rated services. Leave it up to the Charging system (OCS) to determine >>where and how the resources for some traffic. It is not the job of the client to have this information. >>[End CR] Yes, an operator may specify many thousands of rated services, but it doesn't mean that operator have to have thousands of different rates. [CR2] But it may (And at least in some major networks: certainly will). Don't forget, that a single HTML web page can contain many differently rated items. I would think that you would want to avoid creating many sub- sessions just for downloading a single web page. Each sub-session in this case will be very short lived. I believe that many of these service still use same rates and it is possible (and feasible) to define that all the service subject to the same rating type is part of the same group (rating group) and thus same sub-session can be used to control services which belongs to same rating group. And once again, sub-sessions are a cleaner and easier way to handle fault cases and account re-fill cases (re-direct) compared to the approach of having everything controlled within one session. Also controlling everything within one session would require somehow an instance of the state machine for each of the running quotas, thus emulating explicit sub-sessions. [CR2] Correct each resource quota would require state -- but that's no different to each sub-session. Also note that resource quotas would (On average) have a much shorter expected lifetime than a session. >[CR] >But with the current scheme, a single PDP context may have multiple sub-sessions. Adding secondary >PDP contexts for the same session, we end up with many sub-sessions: some for the same PDP context >and some for the other PDP context. It will make trying to correlate all these sub-sessions with >each other and with the user session a whole lot more complicated. >[End CR] It will be rather easy to have own application specific AVP (e.g. 3GPP AVP) to identify the PDP context. For instance two or more DCC sub-sessions with the same PDP contextId AVP would indicate that services are carried in the same secondary PDP context. [CR2] Just more work to do to correlate them all. I also assume there is still the option to open a new DCC session for the secondary PDP Context and sub-sessions for independent quotas, no? [CR2] Yes. But again, more work is involved. We would want to avoid artificially splitting the contexts into different sessions when really they are all related to the same user session. Also, we want to avoid unnecessary signalling overhead. Regards............Harri ------_=_NextPart_001_01C3DEC7.23B6C6A8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas

Hi Harri,

I guess we still disagree with the concept of = sessions and sub-sessions and the independence of quotas within a = session. Some more examples and comments below.

Also, to give you some background: I come from a 3GPP = background. Currently, 3GPP have defined procedures for enabling the = network to rate different content based upon the usual 5 tuple = identifiers (src/dst address and ports & protocol) AS WELL AS WAP = and HTTP (I.e. URI information).

I understand from your colleagues that you are = tackling DCC from an IMS development stance. That may explain why we = have some disconnect.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: Friday, January 16, 2004 7:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Cc: marco.stura@nokia.com; john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; Leena Mattila (TU/LMF)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services = in a user's session, i ndependent quotas


Hi Chris,

>[CR]
>So the current proposal is to provision on each = client node, which services WILL
>use resources from the same  resource pool? =
>Therefore each client node must know in advance = exactly what resource pools exist
>for all potential users and service providers? =
>And, that this grouping is not dynamic or = expected to change too often?
>Sounds a bit unrealistic to me. Each time a new = resource pool is created, it may
>mean going to each client node and re-assigning = existing groupings.
>Imagine a tariff architecture where the resource = pools available to users is constantly
>being modified (Special offers from operator or = 3rd party service providers, etc) -
>each time this happens, the operator must go = into each client and modify the entire rating groups?
>Sounds unworkable to me. I do not think that the = DCC client should know in advance
>what resource pool some rated service usage = should come from - which is what the document
>currently suggests. That's the domain of the = charging system (OCS, etc).
>[End CR]
Due to some special offers why resource pools need = to be changed? Rating groups yes, but why resource pools as well? = Assuming that resource pools are same as accounts, i.e. subscriber can =

have several accounts for different services, one = account for calls, one for MMS, one for data, etc.

[CR2]   Imagine that a 3rd party content = provider makes an agreement with
        the = network operator: "I'll pay the network operator for any = bearer
        traffic = used by it's subscribers to my web site - but only next
        Friday = (Big promotion coming up)". The resources should be taken
        from the = 3rd party content providers pool - which is only valid
        next = Friday.

I agree that when these parameters are only locally = configured it would be quite challenging task to
manage all possible changes manually. But although = parameters are manually configured, it is still
possible to activate/de-activate these parameters = dynamically. And in 3G case I think that there is solution how to = dynamically identify the service data flows that need to be charged at = different rates and the DCC-02 is aligned with the solutions proposed = by IP Flow Based Bearer Level

Charging.

But after all it may be better to let CC server to = decide in real time which credit pool shall be used and let server to = reserve credit from the right end user's account. The Credit-Pool-Id = AVP can be included in the G-S-U so that indication of which = Rating-Group/Service require sub-session can be given by the server. = The client can then initiate sub-sessions for these = Rating-Groups/Services.

[CR2]   Why make it even more complicated = to solve this problem. Now the
        CC server = needs to send back an indicator that the client needs
        to track = so that it knows when to use a sub-session or not. It is
        simply = side-stepping the issue by making it more complicated.
        A session = is a session - not a type of content or resource.
        Resources = used by that session should use that session. The quotas
        on the = client track resource usage. The CC server is the place to
        track = service usage by these sessions and charge (Or not)
        appropriately. It should not be the responsibility of the CC = client
        to start = doing the work of the server.

>I disagree that it is simpler and easier to treat = quotas independently
>within the
>same "sub"-session. This means that = you should report/request quotas also independently,
>i.e. to handle these quotas by using independent = CCR/CCA commands, and thus having sort
>of sub-session within sub-session and/or = session. For instance in fault situations, e.g.
>transport failure, to handle these independent = quotas would make the procedures and state
>machines very complicated.
>>[CR]
>>Do not think of different rated services as = different sub-sessions. This is not correct. An operator
>>may specify many thousands of rated = services. Leave it up to the Charging system (OCS) to determine
>>where and how the resources for some = traffic. It is not the job of the client to have this = information.
>>[End CR]
Yes, an operator may specify many thousands of rated = services, but it doesn't mean that operator have to have thousands of = different rates.

[CR2]   But it may (And at least in some = major networks: certainly will).
        Don't = forget, that a single HTML web page can contain many
        differently rated items.
        I would = think that you would want to avoid creating many sub-
        sessions = just for downloading a single web page.
        Each = sub-session in this case will be very short lived.

I believe that many of these service still use same = rates and it
is possible (and feasible) to define that all the = service subject to the same rating type is part of the same group = (rating group) and thus same sub-session can be used to control = services which belongs to same rating group.

And once again, sub-sessions are a cleaner and easier = way to handle fault cases and account re-fill cases (re-direct) = compared to the approach of having everything controlled within one = session. Also controlling everything within one session would require = somehow an instance of the state machine for

each of the running quotas, thus emulating explicit = sub-sessions.

[CR2]   Correct each resource quota would = require state -- but
        that's no = different to each sub-session. Also note that
        resource = quotas would (On average) have a much shorter
        expected = lifetime than a session.

>[CR]
>But with the current scheme, a single PDP = context may have multiple sub-sessions. Adding secondary
>PDP contexts for the same session, we end up = with many sub-sessions: some for the same PDP context
>and some for the other PDP context. It will make = trying to correlate all these sub-sessions with
>each other and with the user session a whole lot = more complicated.
>[End CR]
It will be rather easy to have own application = specific AVP (e.g. 3GPP AVP) to identify the
PDP context. For instance two or more DCC = sub-sessions with the same PDP contextId AVP would
indicate that services are carried in the same = secondary PDP context.

[CR2]   Just more work to do to correlate = them all.

I also assume there is still the option to open a new = DCC session for the secondary PDP Context and sub-sessions for = independent quotas, no?

[CR2]   Yes. But again, more work is = involved. We would want to avoid
        artificially splitting the contexts into different sessions = when
        really = they are all related to the same user session. Also, we
        want to = avoid unnecessary signalling overhead.

Regards............Harri


------_=_NextPart_001_01C3DEC7.23B6C6A8-- From owner-aaa-wg@merit.edu Tue Jan 20 07:00: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 HAA25947 for ; Tue, 20 Jan 2004 07:00:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FC7691211; Tue, 20 Jan 2004 06:59:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D9D491214; Tue, 20 Jan 2004 06:59: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 DAEC091211 for ; Tue, 20 Jan 2004 06:59:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD5F65DFB9; Tue, 20 Jan 2004 06:59:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id F13B75DFA5 for ; Tue, 20 Jan 2004 06:59:56 -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 i0KBxtY09463 for ; Tue, 20 Jan 2004 13:59:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 20 Jan 2004 13:59:55 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 20 Jan 2004 13:59:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter Client request routing Date: Tue, 20 Jan 2004 13:59:55 +0200 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631C1B239@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPewGzgJH2qlWfdQpO16LpVqd7RQAAi+OZA From: To: X-OriginalArrivalTime: 20 Jan 2004 11:59:55.0364 (UTC) FILETIME=[EB3CBA40:01C3DF4C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, May I suggest reading also Section 6.1, 'Diameter Request Routing = Overview'? :) It should be noted that according to the spec if Destination-Host = matches the value of Destination-Realm can be ignored. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Joe Harvell > Sent: 19 January, 2004 21:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter Client request routing >=20 >=20 > I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based Routing=20 > Table), 5.1 (Peer Connections), and 5.2 (Diameter Peer=20 > Discovery) of Diameter Base Protocol, and I am a little=20 > confused about how a Diameter Peer is to be selected for=20 > sending a request from a Diameter Client. >=20 > Consider the case of a Diameter Client that does not=20 > implement Diameter Peer Discovery. This means that Diameter=20 > Peers are statically configured. The Capabilities Exchange=20 > process will definitely identify the Realm and Host of each=20 > Diameter Peer. However, the only cases in which a peer can=20 > be identified as a candidate next hop for sending a=20 > particular request are as follows: >=20 > 1) when its Realm matches the Destination-Realm of a=20 > message with Destination-Realm only; and > 2) when its Realm and Host match the Destination-Realm=20 > and Destination-Host of a message with a Destination-Realm=20 > and Destination-Host. >=20 > So how does a Diameter Client identify a candidate peer for=20 > sending messages in the other cases? >=20 > Section 5.1 indicates that a Diameter Node should have=20 > established connections with a minimum of two (a primary and=20 > possibly multiple secondary) peers per realm. Does the=20 > "realm" in this context mean that both peers are members of=20 > the same realm, or that both peers can route messages to a=20 > given Destination-Realm? Can Diameter Agents forward=20 > requests for a Destination-Realm that is not their Realm? >=20 > When a Diameter Client has a request with a Destination-Realm=20 > and Destination-Host, will all the primary and secondary=20 > peers described in 5.1 be able to route the request to that=20 > Destination-Host in that Destination-Realm? >=20 > --- > Joe Harvell > Shasta GGSN Development > Nortel Networks > +1 972.685.4886 >=20 >=20 >=20 From owner-aaa-wg@merit.edu Tue Jan 20 07:06: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 HAA26043 for ; Tue, 20 Jan 2004 07:06:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0C05D91214; Tue, 20 Jan 2004 07:06:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7D9091259; Tue, 20 Jan 2004 07:06:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2DA0F91214 for ; Tue, 20 Jan 2004 07:06:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C59D5DEF2; Tue, 20 Jan 2004 07:06:20 -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 313085DEB1 for ; Tue, 20 Jan 2004 07:06:19 -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 i0KC6IV25741 for ; Tue, 20 Jan 2004 14:06:18 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 20 Jan 2004 14:04:22 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 20 Jan 2004 14:04:22 +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_01C3DF4D.8A11325F" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Tue, 20 Jan 2004 14:04:21 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C82A4@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPexzHpdQ9/cTx/SE+xXoPEt584NQAY5eOw From: To: Cc: , , , , , , , X-OriginalArrivalTime: 20 Jan 2004 12:04:22.0842 (UTC) FILETIME=[8AAAA1A0:01C3DF4D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DF4D.8A11325F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 >Also, to give you some background: I come from a 3GPP background. = Currently, 3GPP have defined procedures for enabling=20 >the network to rate different content based upon the usual 5 tuple = identifiers (src/dst address and ports & protocol) AS WELL AS > WAP and HTTP (I.e. URI information). =20 >I understand from your colleagues that you are tackling DCC from an IMS = development stance. That may explain why we have some=20 >disconnect. =20 The DCC is designed to be a generic credit control application to = properly support several services and environments as stated in the draft 02. Among others it also enables to rate rate different content = based upon the usual 5 tuple identifiers (src/dst address and ports & = protocol) as well as WAP and HTTP (I.e. URI information). I would like = to inform you that e.g. the mechanism described in Flow X is implemented and fully working , enabling for what you want with optimal = signaling load. =20 Moreover, 3GPP doesn't have any defined procedures but just high level = stage 2 architecture with requirements, which are covered by the current draft 02. =20 Conclusion, no disconnect at all between the DCC and the 3GPP = requirements since we are following what 3GPP is doing and we are in constant talk with our 3GPP delegates. Where we do have disconnect is = in our views how to implement these functionalities. =20 This discussion is really getting fruitless and endless, totally missing = the point. What we have are requirements from 3GPP and some that you also brought. I copy here your requirements from = http://www.merit.edu/mail.archives/aaa-wg/msg00064.html: =20 - Quotas (G-S-U's) allow an amount of resource usage for a particular = Rating-Group.=20 - Multiple G-S-U AVPs may be returned in a single CCA.=20 - The G-S-U resources for each Rating-Group are allocated independently = of any others.=20 - G-S-U resources may be requested by the client and allocated by the = server at any point in a session.=20 - Each G-S-U resource size (& unit) allocation is independent of any = others. It is a function of the server.=20 - A user may (probably will) use each resource at a different speed to = others.=20 =20 All the points of the above list are supported in draft 02. If you = want optimal signaling and use of resources in client and server, then = you can implement the mechanism of issue 436. If you want to achieve = quota independence, then you can implement sub-sessions. =20 But you are still not happy, you want to enable for quotas multiplexing = in the same session/sub-session thus creating two options to support the same thing. Introducing options to support the same = functionalities is definitely increasing the likelihood of = interoperability issues when coming to real life. Moreover, each of the multiplexed independent quotas would require its = own instance of the DCC state machine as well as its own Tx timer etc. = Whatever you say this is definitely equivalent to have DCC sub-sessions. =20 Having said that, I'm still open to consider proposal that seamlessly = fits within all the currently defined DCC functionalities and mechanisms = and add value to the application. The problem is that so far you just = brought in the discussion very high level proposals that do not tell = much about failure handling etc. and so far I perceive what you propose = as a different option of doing the same things already supported in the = draft not as added value.=20 So, what it would be nice from your side is to exit this discussion loop = and make a proposal that describes your solution including a nice flow example, failure handling details, how to handle the server = initiated credit re-authorization for a given service, GST etc. etc. Of course everything MUST fit seamlessly within all the existing = functionalities defined in the DCC without re-inventing the wheel and = MUST NOT introduce potential for interoperability issues. =20 Looking forward for your technical proposal to consider its added value = if any. =20 Br Marco ------_=_NextPart_001_01C3DF4D.8A11325F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i = ndependent quotas
Hi = Chris,
 
>Also, to = give you=20 some background: I come from a 3GPP background. Currently, 3GPP have = defined=20 procedures for enabling
>the network to=20 rate different content based upon the usual 5 tuple identifiers (src/dst = address=20 and ports & protocol) AS WELL AS
> WAP and HTTP=20 (I.e. URI information).
 
>I = understand from=20 your colleagues that you are tackling DCC from an IMS development = stance. That=20 may explain why we have some
>disconnect.
 
The = DCC is=20 designed to be a generic credit control application to properly support = several=20 services and environments as stated in the
draft 02. Among=20 others it also enables to rate rate different content based upon the = usual 5=20 tuple identifiers (src/dst address and ports & protocol) as = well=20 as WAP and HTTP (I.e. URI information). I would like to inform you = that=20 e.g. the mechanism described in Flow X is
implemented and=20 fully working , enabling for what you want with optimal signaling=20 load.
 
Moreover, 3GPP=20 doesn't have any defined procedures but just high level stage 2 = architecture=20 with requirements, which are covered by
the = current draft=20 02.
 
Conclusion, no=20 disconnect at all between the DCC and the 3GPP requirements since we are = following what 3GPP is doing and we are
in = constant talk=20 with our 3GPP delegates. Where we do have disconnect is in our views how = to=20 implement these functionalities.
 
This discussion=20 is really getting fruitless and endless, totally missing the point. What = we have=20 are requirements from 3GPP and some
that you also=20 brought. I copy here your requirements from http://w= ww.merit.edu/mail.archives/aaa-wg/msg00064.html:
 
- Quotas (G-S-U's) = allow an=20 amount of resource usage for a particular Rating-Group.
- Multiple G-S-U AVPs may be returned in a single CCA. =
- The G-S-U resources for each Rating-Group are allocated = independently=20 of any others.
- G-S-U resources may be = requested by the=20 client and allocated by the server at any point in a session. =
- Each G-S-U resource size (& unit) allocation is = independent of any=20 others. It is a function of the server.
- A = user may=20 (probably will) use each resource at a different speed to others. =
 
All = the points=20 of  the above list are supported in draft 02.  If = you want=20 optimal signaling and use of resources in client and server, then you = can=20 implement the mechanism of issue 436.  If you want to achieve quota = independence, then you can implement sub-sessions.
 
But = you are still=20 not happy, you want to enable for quotas multiplexing in the same=20 session/sub-session thus creating two options
to = support the=20 same thing.  Introducing options to support the same = functionalities is=20 definitely increasing the likelihood of interoperability issues when = coming to=20 real life.
Moreover, each of=20 the multiplexed independent quotas would require its own instance of the = DCC=20 state machine as well as its own Tx timer etc. Whatever = you say this=20 is definitely equivalent to have DCC sub-sessions.
 
Having said that,=20 I'm still open to consider proposal that seamlessly fits within all the=20 currently defined DCC functionalities and mechanisms and add value to = the=20 application. The problem is that so far you just brought in the = discussion very=20 high level proposals that do not tell much about failure handling etc. = and so far=20 I perceive what you propose as a different option of doing the = same=20 things already supported in the draft not as added=20 value. 
So, what = it would be=20 nice from your side is to exit this discussion loop and make a proposal = that=20 describes your solution including
a = nice flow=20 example, failure handling details, how to handle the server initiated = credit=20 re-authorization for a given service, GST etc. = etc.
Of = course=20 everything MUST fit seamlessly within all=20 the existing functionalities defined in the DCC without re-inventing the = wheel=20 and MUST NOT introduce potential for interoperability=20 issues.
 
Looking forward=20 for your technical proposal to consider its added value if=20 any.
 
Br
Marco
------_=_NextPart_001_01C3DF4D.8A11325F-- From owner-aaa-wg@merit.edu Tue Jan 20 11: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 LAA08703 for ; Tue, 20 Jan 2004 11:14:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FF429125A; Tue, 20 Jan 2004 11:14:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DB389125C; Tue, 20 Jan 2004 11:14: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 3008C9125A for ; Tue, 20 Jan 2004 11:14:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 485635DFA2; Tue, 20 Jan 2004 11:14:06 -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 9EB705DFA1 for ; Tue, 20 Jan 2004 11:14:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0KGSS709489 for ; Tue, 20 Jan 2004 08:28:28 -0800 Date: Tue, 20 Jan 2004 08:28:28 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Reminder on Internet Draft submission deadlines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here are the ID draft deadlines: February 9, Monday - 00 Internet Draft Cut-off February 16, Monday - Internet Draft cut-off From owner-aaa-wg@merit.edu Tue Jan 20 11:59: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 LAA12411 for ; Tue, 20 Jan 2004 11:59:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDD0D9121A; Tue, 20 Jan 2004 11:58:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8313D91259; Tue, 20 Jan 2004 11:58: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 58F7191216 for ; Tue, 20 Jan 2004 11:58:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id F139F5DFA6; Tue, 20 Jan 2004 11:58:52 -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 8E8545DF89 for ; Tue, 20 Jan 2004 11:58:52 -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 i0KGwfE02444; Tue, 20 Jan 2004 10:58:41 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 10:58:42 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8E08@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, leena.mattila@ericsson.com, aaa-wg@merit.edu, harri.hakala@ericsson.com, Karl-Heinz.Nenner@t-mobile.de, Benni.Alexander@nokia.com, patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Tue, 20 Jan 2004 10:58:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DF76.A2366678" 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_01C3DF76.A2366678 Content-Type: text/plain Hi Marco, I understand that Nokia already has an implementation of the DCC draft and that is perhaps why there is little negotiation regarding the draft document. I would suggest that 3GPP has stage 2 requirements that need to be addressed that are not. I really want 3GPP to adopt the DCC application, but in order for that to happen, the protocol must meet the requirements. I have commented on some of your specific points below. It worries me that you state that any comments or proposals "MUST fit seamlessly within all the existing functionalities defined in the DCC ". To me that means that the only proposals you are willing to consider make no changes! Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, January 20, 2004 6:04 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Chris, >Also, to give you some background: I come from a 3GPP background. Currently, 3GPP have defined procedures for enabling >the network to rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) AS WELL AS > WAP and HTTP (I.e. URI information). >I understand from your colleagues that you are tackling DCC from an IMS development stance. That may explain why we have some >disconnect. The DCC is designed to be a generic credit control application to properly support several services and environments as stated in the draft 02. Among others it also enables to rate rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) as well as WAP and HTTP (I.e. URI information). I would like to inform you that e.g. the mechanism described in Flow X is implemented and fully working , enabling for what you want with optimal signaling load. [Chris Richards ] I would have to disagree with the last part of that statement. My earlier emails described the extra signalling required and was acknowledged by a response to the group. Moreover, 3GPP doesn't have any defined procedures but just high level stage 2 architecture with requirements, which are covered by the current draft 02. Conclusion, no disconnect at all between the DCC and the 3GPP requirements since we are following what 3GPP is doing and we are in constant talk with our 3GPP delegates. Where we do have disconnect is in our views how to implement these functionalities. [Chris Richards ] Your 3GPP delegate proposed a document that was a cut and paste of an IMS specification. Not a generic Diameter Credit Control document. It only addressed IMS. This discussion is really getting fruitless and endless, totally missing the point. [Chris Richards ] It is only fruitless if there is no willingness to consider the issues I have raised. Again, if Nokia has already implemented it's version of the draft, then I can understand this. What we have are requirements from 3GPP and some that you also brought. I copy here your requirements from http://www.merit.edu/mail.archives/aaa-wg/msg00064.html : - Quotas (G-S-U's) allow an amount of resource usage for a particular Rating-Group. - Multiple G-S-U AVPs may be returned in a single CCA. - The G-S-U resources for each Rating-Group are allocated independently of any others. - G-S-U resources may be requested by the client and allocated by the server at any point in a session. - Each G-S-U resource size (& unit) allocation is independent of any others. It is a function of the server. - A user may (probably will) use each resource at a different speed to others. All the points of the above list are supported in draft 02. If you want optimal signaling and use of resources in client and server, then you can implement the mechanism of issue 436. If you want to achieve quota independence, then you can implement sub-sessions. [Chris Richards ] Again, apart from having the server tell the client what resources are bound together and what resources are independent, how can a client know that a request for one rate quota comes from what resource pool and thus how to know in advance if it needs to create a new sub-session? But you are still not happy, [Chris Richards ] Mainly because as discussed earlier: it will not work in practice. you want to enable for quotas multiplexing in the same session/sub-session thus creating two options to support the same thing. [Chris Richards ] No. Just one option: sub-sessions are used for sub sessions and quotas are used for service delivery. Since when did one rate suddenly become a sub-session. Following that logic, a single web page may contain and require many different sub-sessions. Kind of makes a mockery out of the term "sub-session". Introducing options to support the same functionalities is definitely increasing the likelihood of interoperability issues when coming to real life. [Chris Richards ] Just about every Technical specification I have every seen is full of options. Moreover, each of the multiplexed independent quotas would require its own instance of the DCC state machine as well as its own Tx timer etc. Whatever you say this is definitely equivalent to have DCC sub-sessions. [Chris Richards ] Yes: each quota will need state (It already does - but will need more) - just as sub-sessions do. However, the philosophy is shifted. Sessions are sessions controlled by a user - not by the content of traffic used by the user. The client only needs to know about how to rate traffic (Rules filters) and be able to track the usage. The server needs to manage the resource pools, resource reservation and accounts, etc. NOT the client. The client should never care what resource pool any quota comes from. I think that is fundamentally our disagreement: In the current DCC draft, the client takes on a good deal of responsibility of resource pool knowledge, provisioning, management, etc. In my view (And I think 3GPP requirements): this is the domain of the Online server (DCC server, OCS). Having said that, I'm still open to consider proposal that seamlessly fits within all the currently defined DCC functionalities and mechanisms and add value to the application. [Chris Richards ] So, basically as long as any proposals do not change in any way the current draft, it's OK?! What sort of statement is that? If that's the stance, then why even bother having a draft. The problem is that so far you just brought in the discussion very high level proposals that do not tell much about failure handling etc. and so far I perceive what you propose as a different option of doing the same things already supported in the draft not as added value. So, what it would be nice from your side is to exit this discussion loop and make a proposal that describes your solution including a nice flow example, failure handling details, how to handle the server initiated credit re-authorization for a given service, GST etc. etc. Of course everything MUST fit seamlessly within all the existing functionalities defined in the DCC without re-inventing the wheel and MUST NOT introduce potential for interoperability issues. Looking forward for your technical proposal to consider its added value if any. Br Marco ------_=_NextPart_001_01C3DF76.A2366678 Content-Type: text/html Message
Hi Marco,
 
I understand that Nokia already has an implementation of the DCC draft and that is perhaps why there is little negotiation regarding the draft document.
 
I would suggest that 3GPP has stage 2 requirements that need to be addressed that are not. I really want 3GPP to adopt the DCC application, but in order for that to happen, the protocol must meet the requirements.
 
I have commented on some of your specific points below. It worries me that you state that any comments or proposals "MUST fit seamlessly within all the existing functionalities defined in the DCC ". To me that means that the only proposals you are willing to consider make no changes! 

Best Regards,
Chris.

 

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, January 20, 2004 6:04 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Chris,
 
>Also, to give you some background: I come from a 3GPP background. Currently, 3GPP have defined procedures for enabling
>the network to rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) AS WELL AS
> WAP and HTTP (I.e. URI information).
 
>I understand from your colleagues that you are tackling DCC from an IMS development stance. That may explain why we have some
>disconnect.
 
The DCC is designed to be a generic credit control application to properly support several services and environments as stated in the
draft 02. Among others it also enables to rate rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) as well as WAP and HTTP (I.e. URI information). I would like to inform you that e.g. the mechanism described in Flow X is
implemented and fully working , enabling for what you want with optimal signaling load.
[Chris Richards ] I would have to disagree with the last part of that statement. My earlier emails described the extra signalling required and was acknowledged by a response to the group. 
 
Moreover, 3GPP doesn't have any defined procedures but just high level stage 2 architecture with requirements, which are covered by
the current draft 02.
 
Conclusion, no disconnect at all between the DCC and the 3GPP requirements since we are following what 3GPP is doing and we are
in constant talk with our 3GPP delegates. Where we do have disconnect is in our views how to implement these functionalities.
[Chris Richards ] Your 3GPP delegate proposed a document that was a cut and paste of an IMS specification. Not a generic Diameter Credit Control document. It only addressed IMS.
 
This discussion is really getting fruitless and endless, totally missing the point.
[Chris Richards ] It is only fruitless if there is no willingness to consider the issues I have raised. Again, if Nokia has already implemented it's version of the draft, then I can understand this.
 
 What we have are requirements from 3GPP and some
that you also brought. I copy here your requirements from http://www.merit.edu/mail.archives/aaa-wg/msg00064.html:
 
- Quotas (G-S-U's) allow an amount of resource usage for a particular Rating-Group.
- Multiple G-S-U AVPs may be returned in a single CCA.
- The G-S-U resources for each Rating-Group are allocated independently of any others.
- G-S-U resources may be requested by the client and allocated by the server at any point in a session.
- Each G-S-U resource size (& unit) allocation is independent of any others. It is a function of the server.
- A user may (probably will) use each resource at a different speed to others.
 
All the points of  the above list are supported in draft 02.  If you want optimal signaling and use of resources in client and server, then you can implement the mechanism of issue 436.  If you want to achieve quota independence, then you can implement sub-sessions.
[Chris Richards ] Again, apart from having the server tell the client what resources are bound together and what resources are independent, how can a client know that a request for one rate quota comes from what resource pool and thus how to know in advance if it needs to create a new sub-session?  
 
But you are still not happy,
[Chris Richards ] Mainly because as discussed earlier: it will not work in practice.
 you want to enable for quotas multiplexing in the same session/sub-session thus creating two options
to support the same thing. 
[Chris Richards ] No. Just one option: sub-sessions are used for sub sessions and quotas are used for service delivery. Since when did one rate suddenly become a sub-session. Following that logic, a single web page may contain and require many different sub-sessions. Kind of makes a mockery out of the term "sub-session".
 
  Introducing options to support the same functionalities is definitely increasing the likelihood of interoperability issues when coming to real life.
[Chris Richards ] Just about every Technical specification I have every seen is full of options.
 
 Moreover, each of the multiplexed independent quotas would require its own instance of the DCC state machine as well as its own Tx timer etc. Whatever you say this is definitely equivalent to have DCC sub-sessions.
[Chris Richards ] Yes: each quota will need state (It already does - but will need more) - just as sub-sessions do. However, the philosophy is shifted. Sessions are sessions controlled by a user - not by the content of traffic used by the user. The client only needs to know about how to rate traffic (Rules filters) and be able to track the usage. The server needs to manage the resource pools, resource reservation and accounts, etc. NOT the client. The client should never care what resource pool any quota comes from. I think that is fundamentally our disagreement: In the current DCC draft, the client takes on a good deal of responsibility of resource pool knowledge, provisioning, management, etc. In my view (And I think 3GPP requirements): this is the domain of the Online server (DCC server, OCS).
 
Having said that, I'm still open to consider proposal that seamlessly fits within all the currently defined DCC functionalities and mechanisms and add value to the application.
[Chris Richards ] So, basically as long as any proposals do not change in any way the current draft, it's OK?! What sort of statement is that? If that's the stance, then why even bother having a draft.
 
 The problem is that so far you just brought in the discussion very high level proposals that do not tell much about failure handling etc. and so far I perceive what you propose as a different option of doing the same things already supported in the draft not as added value. 
So, what it would be nice from your side is to exit this discussion loop and make a proposal that describes your solution including
a nice flow example, failure handling details, how to handle the server initiated credit re-authorization for a given service, GST etc. etc.
Of course everything MUST fit seamlessly within all the existing functionalities defined in the DCC without re-inventing the wheel and MUST NOT introduce potential for interoperability issues.
 
Looking forward for your technical proposal to consider its added value if any.
 
Br
Marco
------_=_NextPart_001_01C3DF76.A2366678-- From owner-aaa-wg@merit.edu Tue Jan 20 13:15: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 NAA14922 for ; Tue, 20 Jan 2004 13:15:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C75DC9125D; Tue, 20 Jan 2004 13:15:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E35F9125E; Tue, 20 Jan 2004 13:15:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E23B9125D for ; Tue, 20 Jan 2004 13:15:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 990B05DE9E; Tue, 20 Jan 2004 13:15:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hotmail.com (law10-f112.law10.hotmail.com [64.4.15.112]) by segue.merit.edu (Postfix) with ESMTP id 919335DE7A for ; Tue, 20 Jan 2004 13:15:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Jan 2004 10:15:00 -0800 Received: from 212.213.204.99 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 20 Jan 2004 18:15:00 GMT X-Originating-IP: [212.213.204.99] X-Originating-Email: [marco_stura@hotmail.com] X-Sender: marco_stura@hotmail.com From: "Stura Marco" To: crich@nortelnetworks.com Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, leena.mattila@ericsson.com, aaa-wg@merit.edu, harri.hakala@ericsson.com, Karl-Heinz.Nenner@t-mobile.de, Benni.Alexander@nokia.com, patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Tue, 20 Jan 2004 20:15:00 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jan 2004 18:15:00.0815 (UTC) FILETIME=[518805F0:01C3DF81] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, >I understand that Nokia already has an implementation of the DCC draft and >that is perhaps why there is little negotiation regarding the draft >document. Did I mention Nokia??? ..... and by the way, there is always room for protocol improvements if those make sense and are not *yet another option*. >I have commented on some of your specific points below. It worries me that >you state that any comments or proposals "MUST fit seamlessly within all >the >existing functionalities defined in the DCC ". To me that means that the >only proposals you are willing to consider make no changes! Rather than providing political answer, turn around things and speculate on my statements without any concrete proposal please concentrate on technical fact and provide what we requested, thank you. i.e. >So, what it would be nice from your side is to exit this discussion loop >and >make a proposal that describes your solution including >a nice flow example, failure handling details, how to handle the server >initiated credit re-authorization for a given service, GST etc. etc. I guess you should be familiar how to create an issue that includes all the impact to the protocol etc., no? Be sure that if your proposal is of any added value and valuable at the purpose of enhancing the application (i.e. not introducing options to do the same things already supported), I'm certainly not the one neglecting a good proposal. >I would suggest that 3GPP has stage 2 requirements that need to be >addressed >that are not. I really want 3GPP to adopt the DCC application, but in order >for that to happen, the protocol must meet the requirements. All 3GPP requirements are addressed and met as repeated many many time since this discussion started. However, if the main 3GPP requirement is the DCC to accommodate for your view and implement the solution accordingly, I agree that this is not fully met. Regards Marco _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-aaa-wg@merit.edu Tue Jan 20 14:53: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 OAA17757 for ; Tue, 20 Jan 2004 14:53:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95FC891224; Tue, 20 Jan 2004 14:53:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61D3591261; Tue, 20 Jan 2004 14:53: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 86DD291224 for ; Tue, 20 Jan 2004 14:53:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7095E5DFC8; Tue, 20 Jan 2004 14:53:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id BB8515DE85 for ; Tue, 20 Jan 2004 14:53:14 -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 i0KJp6E09763; Tue, 20 Jan 2004 11:51:06 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 13:51:06 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8E09@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'Stura Marco'" Cc: marco.stura@nokia.com, john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, leena.mattila@ericsson.com, aaa-wg@merit.edu, harri.hakala@ericsson.com, Karl-Heinz.Nenner@t-mobile.de, Benni.Alexander@nokia.com, patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Tue, 20 Jan 2004 13:50:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DF8E.B9C0FDAE" 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_01C3DF8E.B9C0FDAE Content-Type: text/plain Hi Marco, Well, let's go back to two of my original questions:- How does a client know when to use a sub-session for a quota request or not? I see 3 possibilities:- (1) Always use sub-sessions for every quota. (2) Provision on the client, exactly what resource pools each rate belongs to. (3) Have some other device to provide a table of rates <-> resource pool mappings. Table is per user or per...? (4) ? Here is my opinion:- (a) Personally, I don't think that the resource usage tracker (client) should need to know what or how resource pools are managed. That's an architectural issue and a job for the charging system. However, it has direct bearing on the DCC protocol use of sessions sub-sessions. (b) Rate-to-resource pool mapping may be very dynamic; changing depending on many factors, including the time of the day. That makes any mapping table or static provisioning unworkable. Let me know your answer. So, that brings me to the logical next question: What is a session as defined in DCC? From RFC3588 I got these definitions:- Session A session is a related progression of events devoted to a particular activity. Each application SHOULD provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Identifier are considered to be part of the same session. Sub-session A sub-session represents a distinct service (e.g., QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g., simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id. Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context. Again, let me know your answer. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Stura Marco [mailto:marco_stura@hotmail.com] Sent: Tuesday, January 20, 2004 12:15 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: marco.stura@nokia.com; john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Chris, >I understand that Nokia already has an implementation of the DCC draft >and that is perhaps why there is little negotiation regarding the draft >document. Did I mention Nokia??? ..... and by the way, there is always room for protocol improvements if those make sense and are not *yet another option*. >I have commented on some of your specific points below. It worries me >that you state that any comments or proposals "MUST fit seamlessly >within all the existing functionalities defined in the DCC ". To me >that means that the only proposals you are willing to consider make no >changes! Rather than providing political answer, turn around things and speculate on my statements without any concrete proposal please concentrate on technical fact and provide what we requested, thank you. i.e. >So, what it would be nice from your side is to exit this discussion >loop >and >make a proposal that describes your solution including >a nice flow example, failure handling details, how to handle the server >initiated credit re-authorization for a given service, GST etc. etc. I guess you should be familiar how to create an issue that includes all the impact to the protocol etc., no? Be sure that if your proposal is of any added value and valuable at the purpose of enhancing the application (i.e. not introducing options to do the same things already supported), I'm certainly not the one neglecting a good proposal. >I would suggest that 3GPP has stage 2 requirements that need to be >addressed >that are not. I really want 3GPP to adopt the DCC application, but in order >for that to happen, the protocol must meet the requirements. All 3GPP requirements are addressed and met as repeated many many time since this discussion started. However, if the main 3GPP requirement is the DCC to accommodate for your view and implement the solution accordingly, I agree that this is not fully met. Regards Marco _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ------_=_NextPart_001_01C3DF8E.B9C0FDAE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas

Hi Marco,

Well, let's go back to two of my original = questions:-

How does a client know when to use a sub-session for = a quota request or not?

I see 3 possibilities:-
(1) Always use sub-sessions for every quota.
(2) Provision on the client, exactly what resource = pools each rate belongs to.
(3) Have some other device to provide a table of = rates <-> resource pool mappings. Table is per user or = per...?
(4) ?

Here is my opinion:-

(a) Personally, I don't think that the resource usage = tracker (client) should need to know what or how resource pools are = managed. That's an architectural issue and a job for the charging = system. However, it has direct bearing on the DCC protocol use of = sessions sub-sessions.

(b) Rate-to-resource pool mapping may be very = dynamic; changing depending on many factors, including the time of the = day. That makes any mapping table or static provisioning = unworkable.

Let me know your answer.

So, that brings me to the logical next question: What = is a session as defined in DCC? From RFC3588 I got these = definitions:-

      Session
      A session is a = related progression of events devoted to a
      particular = activity.  Each application SHOULD provide guidelines
      as to when a session = begins and ends.  All Diameter packets with
      the same = Session-Identifier are considered to be part of the same
      session.

      Sub-session
      A sub-session = represents a distinct service (e.g., QoS or data
      characteristics) = provided to a given session.  These services may
      happen concurrently = (e.g., simultaneous voice and data transfer
      during the same = session) or serially.  These changes in sessions
      are tracked with the = Accounting-Sub-Session-Id.
 
Are data characteristics or QoS represented by = different rating of content? Surely the QoS or data characteristics are = attributes of the session not of the rating of the content. The = paragraph above is very similar to the 3GPP definition of secondary = context.

Again, let me know your answer.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Stura Marco [mailto:marco_stura@hotmail.com]
Sent: Tuesday, January 20, 2004 12:15 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: marco.stura@nokia.com; john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; = aaa-wg@merit.edu; harri.hakala@ericsson.com; = Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com

Subject: RE: [AAA-WG]: Issue: DCC Multiple services = in a user's session, i ndependent quotas


Hi Chris,

>I understand that Nokia already has an = implementation of the DCC draft
>and that is perhaps why there is little = negotiation regarding the draft
>document.

Did I mention Nokia??? ..... and by the way, there is = always room for
protocol
improvements if those make sense and are not *yet = another option*.

>I have commented on some of your specific points = below. It worries me
>that you state that any comments or proposals = "MUST fit seamlessly
>within all the existing functionalities defined = in the DCC ". To me
>that means that the only proposals you are = willing to consider make no
>changes!

Rather than providing political answer, turn around = things and speculate on
my statements without any concrete proposal please = concentrate on technical
fact and provide what we requested, thank you.  = i.e.

>So, what it would be nice from your side is to = exit this discussion
>loop
>and
>make a proposal that describes your solution = including
>a nice flow example, failure handling details, = how to handle the server
>initiated credit re-authorization for a given = service, GST etc. etc.

I guess you should be familiar how to create an issue = that includes all the
impact to
the protocol etc., no?

Be sure that if your proposal is of any added value = and valuable at the
purpose of enhancing the application (i.e. not = introducing options to do the
same things already supported), I'm certainly not = the one neglecting a good
proposal.

>I would suggest that 3GPP has stage 2 = requirements that need to be
>addressed
>that are not. I really want 3GPP to adopt the = DCC application, but in order
>for that to happen, the protocol must meet the = requirements.

All 3GPP requirements are addressed and met as = repeated many many time since
this discussion started. However, if the main 3GPP = requirement is the DCC to
accommodate for your view and implement the solution = accordingly, I agree
that this is not fully met.

Regards
Marco

_______________________________________________________________= __
The new MSN 8: smart spam protection and 2 months = FREE* 
http://join.msn.com/?page=3Dfeatures/junkmail

------_=_NextPart_001_01C3DF8E.B9C0FDAE-- From owner-aaa-wg@merit.edu Wed Jan 21 02:23: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 CAA04064 for ; Wed, 21 Jan 2004 02:23:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B4949126F; Wed, 21 Jan 2004 02:23:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18F9291270; Wed, 21 Jan 2004 02:23:33 -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 8DEFE9126F for ; Wed, 21 Jan 2004 02:23:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 639065DEB0; Wed, 21 Jan 2004 02:23:30 -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 5CAA15DEAD for ; Wed, 21 Jan 2004 02:23:29 -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 i0L7NOV06667 for ; Wed, 21 Jan 2004 09:23:24 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 09:23:24 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 09:23:24 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 09:23:24 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 09:23: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_01C3DFEF.73488984" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Wed, 21 Jan 2004 09:23:22 +0200 Message-ID: <573ED33A76FA194F90B377FA16E900EC9B15A2@trebe002.europe.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPfjwnoA8QqiuE5Svq10fEhFwUXHAAXsRzA From: To: , Cc: , , , , , , , , X-OriginalArrivalTime: 21 Jan 2004 07:23:23.0466 (UTC) FILETIME=[741BC2A0:01C3DFEF] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DFEF.73488984 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris! =20 I've been following your vivid discussion for awhile. As this discussion = has been going on so long I suggest that you make formal issue where you = summarize (chapter x.x FROM - chapter x.x TO) the changes needed to DCCA = draft 02. Could you do this, please? =20 I'm sure that detailed and formal proposal will solve this problem as = also others can clearly see what should be changed and where and why.=20 =20 Thanks in advance!! =20 BR, JP Koskinen =20 =20 -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 20 January, 2004 21:51 To: 'Stura Marco' Cc: Stura Marco (Nokia-NET/Helsinki); Loughney John = (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); = leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; = Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo); = patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas Hi Marco,=20 Well, let's go back to two of my original questions:-=20 How does a client know when to use a sub-session for a quota request or = not?=20 I see 3 possibilities:-=20 (1) Always use sub-sessions for every quota.=20 (2) Provision on the client, exactly what resource pools each rate = belongs to.=20 (3) Have some other device to provide a table of rates <-> resource pool = mappings. Table is per user or per...?=20 (4) ?=20 Here is my opinion:-=20 (a) Personally, I don't think that the resource usage tracker (client) = should need to know what or how resource pools are managed. That's an = architectural issue and a job for the charging system. However, it has = direct bearing on the DCC protocol use of sessions sub-sessions. (b) Rate-to-resource pool mapping may be very dynamic; changing = depending on many factors, including the time of the day. That makes any = mapping table or static provisioning unworkable. Let me know your answer.=20 So, that brings me to the logical next question: What is a session as = defined in DCC? From RFC3588 I got these definitions:- Session=20 A session is a related progression of events devoted to a=20 particular activity. Each application SHOULD provide guidelines=20 as to when a session begins and ends. All Diameter packets with=20 the same Session-Identifier are considered to be part of the same=20 session.=20 Sub-session=20 A sub-session represents a distinct service (e.g., QoS or data=20 characteristics) provided to a given session. These services may=20 happen concurrently (e.g., simultaneous voice and data transfer=20 during the same session) or serially. These changes in sessions=20 are tracked with the Accounting-Sub-Session-Id.=20 =20 Are data characteristics or QoS represented by different rating of = content? Surely the QoS or data characteristics are attributes of the = session not of the rating of the content. The paragraph above is very = similar to the 3GPP definition of secondary context.=20 Again, let me know your answer.=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: Stura Marco [ mailto:marco_stura@hotmail.com]=20 Sent: Tuesday, January 20, 2004 12:15 PM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: marco.stura@nokia.com; john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; = aaa-wg@merit.edu; harri.hakala@ericsson.com; = Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas=20 Hi Chris,=20 >I understand that Nokia already has an implementation of the DCC draft=20 >and that is perhaps why there is little negotiation regarding the draft = >document.=20 Did I mention Nokia??? ..... and by the way, there is always room for=20 protocol=20 improvements if those make sense and are not *yet another option*.=20 >I have commented on some of your specific points below. It worries me=20 >that you state that any comments or proposals "MUST fit seamlessly=20 >within all the existing functionalities defined in the DCC ". To me=20 >that means that the only proposals you are willing to consider make no=20 >changes!=20 Rather than providing political answer, turn around things and speculate = on=20 my statements without any concrete proposal please concentrate on = technical=20 fact and provide what we requested, thank you. i.e.=20 >So, what it would be nice from your side is to exit this discussion=20 >loop=20 >and=20 >make a proposal that describes your solution including=20 >a nice flow example, failure handling details, how to handle the server = >initiated credit re-authorization for a given service, GST etc. etc.=20 I guess you should be familiar how to create an issue that includes all = the=20 impact to=20 the protocol etc., no?=20 Be sure that if your proposal is of any added value and valuable at the=20 purpose of enhancing the application (i.e. not introducing options to do = the=20 same things already supported), I'm certainly not the one neglecting a = good=20 proposal.=20 >I would suggest that 3GPP has stage 2 requirements that need to be=20 >addressed=20 >that are not. I really want 3GPP to adopt the DCC application, but in = order=20 >for that to happen, the protocol must meet the requirements.=20 All 3GPP requirements are addressed and met as repeated many many time = since=20 this discussion started. However, if the main 3GPP requirement is the = DCC to=20 accommodate for your view and implement the solution accordingly, I = agree=20 that this is not fully met.=20 Regards=20 Marco=20 _________________________________________________________________=20 The new MSN 8: smart spam protection and 2 months FREE* =20 http://join.msn.com/?page=3Dfeatures/junkmail=20 ------_=_NextPart_001_01C3DFEF.73488984 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i = ndependent quotas
Hi=20 Chris!
 
I've=20 been following your vivid discussion for awhile. As this discussion has = been=20 going on so long I suggest that you make formal issue=20 where you summarize (chapter x.x FROM - chapter x.x TO) the = changes=20 needed to DCCA draft 02. Could you do this, please?
 
I'm=20 sure that detailed and formal proposal will solve this problem as also = others=20 can clearly see what should be changed and where and why. =
 
Thanks=20 in advance!!
 
BR,
JP=20 Koskinen
 
 
 -----Original = Message-----
From:=20 ext Christopher Richards = [mailto:crich@nortelnetworks.com]
Sent: 20=20 January, 2004 21:51
To: 'Stura Marco'
Cc: Stura = Marco=20 (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Koskinen = Juha-Pekka=20 (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu;=20 harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander = Benni=20 (Nokia-NET/Espoo); patrik.teppo@ericsson.com
Subject: RE: = [AAA-WG]:=20 Issue: DCC Multiple services in a user's session, i ndependent=20 quotas

Hi Marco,

Well, let's go back to two of my original = questions:-=20

How does a client know when to use a sub-session for = a quota=20 request or not?

I see 3 possibilities:-
(1) Always use=20 sub-sessions for every quota.
(2) Provision = on the=20 client, exactly what resource pools each rate belongs to. =
(3) Have some other device to provide a table of rates = <->=20 resource pool mappings. Table is per user or per...?
(4) ?

Here is my opinion:-

(a) Personally, I don't think that the resource = usage tracker=20 (client) should need to know what or how resource pools are managed. = That's an=20 architectural issue and a job for the charging system. However, it has = direct=20 bearing on the DCC protocol use of sessions sub-sessions.

(b) Rate-to-resource pool mapping may be very = dynamic;=20 changing depending on many factors, including the time of the day. = That makes=20 any mapping table or static provisioning unworkable.

Let me know your answer.

So, that brings me to the logical next question: = What is a=20 session as defined in DCC? From RFC3588 I got these = definitions:-

      Session =
      A session is a related = progression of=20 events devoted to a
     =20 particular activity.  Each application SHOULD provide = guidelines=20
      as to when a session = begins=20 and ends.  All Diameter packets with
      the same Session-Identifier = are=20 considered to be part of the same
      session.

      Sub-session =
      A sub-session represents a = distinct=20 service (e.g., QoS or data
      characteristics) provided to a = given=20 session.  These services may
      happen concurrently (e.g., = simultaneous=20 voice and data transfer
     =20 during the same session) or serially.  These changes in = sessions=20
      are tracked with the = Accounting-Sub-Session-Id.
  =
Are data characteristics or QoS represented by different = rating of=20 content? Surely the QoS or data characteristics are attributes of the = session=20 not of the rating of the content. The paragraph above is very similar = to the=20 3GPP definition of secondary context.

Again, let me know your answer.

Cheers,
Chris.

Shasta Wireless Development
Nortel=20 Networks

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


-----Original Message-----
From: Stura=20 Marco [mailto:marco_stura@hotmail.com]=20
Sent: Tuesday, January 20, 2004 12:15 = PM=20
To: Richards, Christopher [RICH2:2Q40:EXCH] =
Cc: marco.stura@nokia.com; john.loughney@nokia.com;=20 juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; = aaa-wg@merit.edu;=20 harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de;=20 Benni.Alexander@nokia.com; patrik.teppo@ericsson.com

Subject: RE: [AAA-WG]: Issue: DCC Multiple services = in a=20 user's session, i ndependent quotas


Hi Chris,

>I understand that Nokia already has an = implementation of=20 the DCC draft
>and that is perhaps why = there is=20 little negotiation regarding the draft
>document.

Did I mention Nokia??? ..... and by the way, there = is always=20 room for
protocol
improvements=20 if those make sense and are not *yet another option*.

>I have commented on some of your specific points = below. It=20 worries me
>that you state that any = comments or=20 proposals "MUST fit seamlessly
>within = all the=20 existing functionalities defined in the DCC ". To me
>that means that the only proposals you are willing to = consider make=20 no
>changes!

Rather than providing political answer, turn around = things and=20 speculate on
my statements without any = concrete=20 proposal please concentrate on technical
fact and=20 provide what we requested, thank you.  i.e.

>So, what it would be nice from your side is to = exit this=20 discussion
>loop
>and
>make a proposal that = describes your=20 solution including
>a nice flow example, = failure=20 handling details, how to handle the server
>initiated credit re-authorization for a given service, = GST etc.=20 etc.

I guess you should be familiar how to create an = issue that=20 includes all the
impact to
the=20 protocol etc., no?

Be sure that if your proposal is of any added value = and=20 valuable at the
purpose of enhancing the = application=20 (i.e. not introducing options to do the
same = things=20 already supported), I'm certainly not the one neglecting a good=20
proposal.

>I would suggest that 3GPP has stage 2 = requirements that=20 need to be
>addressed
>that are not. I really want 3GPP to adopt the DCC = application, but=20 in order
>for that to happen, the = protocol must=20 meet the requirements.

All 3GPP requirements are addressed and met as = repeated many=20 many time since
this discussion started. = However, if=20 the main 3GPP requirement is the DCC to
accommodate=20 for your view and implement the solution accordingly, I agree =
that this is not fully met.

Regards
Marco

________________________________________________________________= _=20
The new MSN 8: smart spam protection and 2 months = FREE* =20
http://join.msn.co= m/?page=3Dfeatures/junkmail=20

------_=_NextPart_001_01C3DFEF.73488984-- From owner-aaa-wg@merit.edu Wed Jan 21 03:04: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 DAA11303 for ; Wed, 21 Jan 2004 03:04:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 22B8E91270; Wed, 21 Jan 2004 03:04:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A66819122B; Wed, 21 Jan 2004 03:04: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 CF32091271 for ; Wed, 21 Jan 2004 03:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEAB65DDAF; Wed, 21 Jan 2004 03:04:09 -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 9D6325DE23 for ; Wed, 21 Jan 2004 03:04:08 -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 i0L847V29477 for ; Wed, 21 Jan 2004 10:04:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 10:04:05 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:04:05 +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]: Ongoing Working Group Last call on Diameter Credit Control Date: Wed, 21 Jan 2004 10:04:04 +0200 Message-ID: Thread-Topic: Ongoing Working Group Last call on Diameter Credit Control Thread-Index: AcPf9SOTBsseXdODQnGxRzMOXGKSXQ== From: To: Cc: , , , X-OriginalArrivalTime: 21 Jan 2004 08:04:05.0078 (UTC) FILETIME=[236C2F60:01C3DFF5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I'd like to remind everyone that there is an on-going Working Group Last Call on the Diameter Credit Control draft. Our charter shows that we have planned to complete this work April 2002. This document has been under development for quite some time, and 3GPP has officially asked for this work to be expedited. Please send your last call comments in the following format. http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-02.txt This draft is a Standards Track document. Please send comments on this document to the AAA WG mailing list, on or before January 29, 2005.=20 As with other AAA WG documents, issues are to be submitted using the following template: Issue Number: Get_An_Issue_Number_From_Pat Description of issue: Submitter name: Your_Name_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [CCA] Comment type: ['T'echnical | 'E'ditorial ] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issues:=20 Description_of_Problem_Goes_Here Requested change:=20 Proposal_Goes_Here_With_Specific_Text As with all working group last calls, the draft will be updated = according to working group consensus on issues submitted. =20 thanks,=20 Bernard, Dave & John From owner-aaa-wg@merit.edu Wed Jan 21 03:07: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 DAA11373 for ; Wed, 21 Jan 2004 03:07:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E94119122B; Wed, 21 Jan 2004 03:06:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F20191271; Wed, 21 Jan 2004 03:06:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AF599122B for ; Wed, 21 Jan 2004 03:06:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 210A95DE6A; Wed, 21 Jan 2004 03:06:30 -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 5494C5DDAF for ; Wed, 21 Jan 2004 03:06:29 -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 i0L86SY00254 for ; Wed, 21 Jan 2004 10:06:28 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 10:06:27 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:06:27 +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]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Wed, 21 Jan 2004 10:06:27 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPfjwnaxlycEED4RNKzawKr3m+mmQAZikXg From: To: , Cc: , , , , , , , X-OriginalArrivalTime: 21 Jan 2004 08:06:27.0680 (UTC) FILETIME=[786B8600:01C3DFF5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, > Well, let's go back to two of my original questions:-=20 > How does a client know when to use a sub-session for a quota request = or not?=20 > I see 3 possibilities:-=20 > (1) Always use sub-sessions for every quota.=20 > (2) Provision on the client, exactly what resource pools each rate = belongs to.=20 > (3) Have some other device to provide a table of rates <-> resource = pool mappings.=20 > Table is per user or per...?=20 As you know, the draft is WGLC. Could you please send your comments in the format requested? It gives us a way to track the issue and try to resolve the issue. As you know, the draft has existed for quite some time, and there are = concerns from 3GPP about completing this work, so we would really like to get = issues submitted and resolved as soon as possible. thanks, John From owner-aaa-wg@merit.edu Wed Jan 21 03:12: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 DAA11565 for ; Wed, 21 Jan 2004 03:12:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 747F391271; Wed, 21 Jan 2004 03:12:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 275D591272; Wed, 21 Jan 2004 03:12:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8129391271 for ; Wed, 21 Jan 2004 03:12:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 491CE5DE81; Wed, 21 Jan 2004 03:12:18 -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 87F475DE99 for ; Wed, 21 Jan 2004 03:12:17 -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 i0L8BuV10918 for ; Wed, 21 Jan 2004 10:12:07 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 10:11:55 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:11:54 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:11:54 +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]: Ongoing Working Group Last call on Diameter Credit Control Date: Wed, 21 Jan 2004 10:11:53 +0200 Message-ID: Thread-Topic: Ongoing Working Group Last call on Diameter Credit Control Thread-Index: AcPf9SOTBsseXdODQnGxRzMOXGKSXQAAPfdg From: To: Cc: , , , X-OriginalArrivalTime: 21 Jan 2004 08:11:54.0526 (UTC) FILETIME=[3B3C43E0:01C3DFF6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, > Please send your last call comments in the following format. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-02.txt >=20 > This draft is a Standards Track document. Please send comments on this > document to the AAA WG mailing list, on or before January 29, 2005.=20 Please note that this should read January 29, 2004. thanks, John From owner-aaa-wg@merit.edu Wed Jan 21 07:15: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 HAA17551 for ; Wed, 21 Jan 2004 07:15:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 167189127B; Wed, 21 Jan 2004 07:15:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92F5B9127E; Wed, 21 Jan 2004 07:15: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 431F09127B for ; Wed, 21 Jan 2004 07:15:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id F2D865DDC6; Wed, 21 Jan 2004 07:15:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 12CE75DDAD for ; Wed, 21 Jan 2004 07:15:12 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LCE5V25356 for ; Wed, 21 Jan 2004 14:14:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 14:14:04 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 14:14:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E018.0F593450" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Wed, 21 Jan 2004 14:14:03 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C82C4@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPfjwpU4XkERzyaSUGC4AyIsLKRaQAaGxug From: To: Cc: , , , , , , , X-OriginalArrivalTime: 21 Jan 2004 12:14:04.0246 (UTC) FILETIME=[0F9F9760:01C3E018] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E018.0F593450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >How does a client know when to use a sub-session for a quota request or = not?=20 =20 If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule = Function) that is supposed to provision the Service Element (e.g. GGSN) with all the service data = flows information including=20 IP filters, URI, Service-Id and/or Rating-Group etc. The service data = flow information may be=20 static or dynamic (e.g. derived from SIP/SDP). If your client does implement the independent quotas approach it will = request for credit control authorization by opening a DCC sub-session every time a non-authorized = service data flow is met. Please note that most of those sub-sessions are short lasting = sub-sessions. Since the user most likely will pay the services, also note that there = will not be many sub-sessions in average per user. The client doesn't need to know what or how the server manage credit = resources pools at all. A flow example is provided in Issue 8. >Session=20 > A session is a related progression of events devoted to a=20 > particular activity. Each application SHOULD provide guidelines=20 > as to when a session begins and ends. All Diameter packets with=20 > the same Session-Identifier are considered to be part of the same = > session.=20 >Sub-session=20 > A sub-session represents a distinct service (e.g., QoS or data=20 > characteristics) provided to a given session. These services may = > happen concurrently (e.g., simultaneous voice and data transfer=20 > during the same session) or serially. These changes in sessions=20 > are tracked with the Accounting-Sub-Session-Id.=20 =20 >Are data characteristics or QoS represented by different rating of = content? Surely the QoS or data characteristics are attributes of the = >session not of the rating of the content. The paragraph above is very = similar to the 3GPP definition of secondary context.=20 =20 Right. The QoS and all the bearer characteristics are attributes of the = DCC session. Note that the RFC 3588 gives QoS or data characteristics as an example = of a distinct service, it doesn't say that distinct service means only QoS or data characteristics. A distinct service may = be something else as well e.g. a service data flow or a Rating-Group. =20 A PDP Context (primary or secondary) can map to a DCC session that = carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). = Whenever a non-authorized service data flow is met, the service element = (e.g. GGSN) opens a DCC sub-session to perform credit control and get = independent quota. Note that all the service data flows subject to the = same rate can be grouped into Rating-Groups, thus the client just need = to authorize the Rating-Group and share the granted units among all the = used services within the Rating-Group. It doesn't necessarily means that = you need to open a sub-session for each of the service data flows. The result of the above is that you get a DCC session for each PDP = Context and associated temporary sub-sessions for different rating of = content. If you multiplex quotas within the same session it is = equivalent to this, since you would need an instance of the DCC state = machine and Tx timer for each of the independent quotas the resources = you save as compared to explicit sub-session are irrelevant and there is = the cost of added system/implementation complexity and added potential = for interoperability issues since there would be two options to do the = same thing. =20 If you want to save signaling and resources then the DCC also support = for another mechanism, an example of which is given in Flow X. As = suggested in issue 8 the server need to support both mechanisms while = the client implementation may support either one or the other or both.=20 =20 Personally, I regard this thread as closed. Should you have more = questions/doubts that I didn't answer, please provide a formal issue = with all the technical details, what should be changed where and why as = also suggested by other people. =20 Regards Marco ------_=_NextPart_001_01C3E018.0F593450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i = ndependent quotas
>How does = a client=20 know when to use a sub-session for a quota request or not?=20
 
If we=20 talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function) = that is=20 supposed to
provision the Service Element (e.g. GGSN) with all the service = data flows=20 information including 
IP=20 filters, URI, Service-Id and/or Rating-Group etc. The service data flow=20 information may be
static=20 or dynamic (e.g. derived from SIP/SDP).
If=20 your client does implement the independent quotas approach it = will request=20 for credit control
authorization by opening a DCC sub-session every time a = non-authorized=20 service data flow is met.
Please=20 note that most of those sub-sessions are short lasting=20 sub-sessions.
Since=20 the user most likely will pay the services, also note that there = will not=20 be many sub-sessions
in=20 average per user.
The=20 client doesn't need to know what or how the server manage credit = resources=20 pools at all.
A flow=20 example is provided in Issue 8.
>Session
   >  A session is a related = progression of=20 events devoted to a 
   >  particular activity.  Each = application=20 SHOULD provide guidelines
  =20 >  as to when a session begins and ends.  All Diameter = packets=20 with
   >   = the same=20 Session-Identifier are considered to be part of the=20 same
 =20  >   session. =

      >Sub-session 
  &n= bsp;  > A sub-session represents a = distinct service=20 (e.g., QoS or data 
     > characteristics) provided to a = given=20 session.  These services = may 
     > happen concurrently (e.g., = simultaneous=20 voice and data transfer 
     > during the same session) or = serially. =20 These changes in sessions 
     > are tracked with the=20 Accounting-Sub-Session-Id.

 
>Are data = characteristics or=20 QoS represented by different rating of content? Surely the QoS or data=20 characteristics are attributes of the >session not of the rating of = the=20 content. The paragraph above is very similar to the 3GPP definition of = secondary=20 context.
 
Right.=20 The QoS and all the bearer characteristics are attributes of the DCC=20 session.
Note=20 that the RFC 3588 gives QoS or data characteristics as an example of a = distinct=20 service, it doesn't say that distinct
service means only QoS or data characteristics. A distinct = service may be=20 something else as well e.g. a service data flow or a=20 Rating-Group.
 
A PDP=20 Context (primary or secondary) can map to a DCC session that carries the = bearer=20 characteristics (i.e. QoS, APN, PDP-Identifier etc.). = Whenever a=20 non-authorized service data flow is met, the service element (e.g. GGSN) = opens a=20 DCC sub-session to perform credit control and get independent = quota. Note=20 that all the service data flows subject to the same rate can be grouped = into=20 Rating-Groups, thus the client just need to authorize the Rating-Group = and share=20 the granted units among all the used services within the Rating-Group. = It=20 doesn't necessarily means that you need to open a sub-session for each = of the=20 service data flows.
The=20 result of the above is that you get a DCC session for each PDP Context = and=20 associated temporary sub-sessions for different rating of content. If = you=20 multiplex quotas within the same session it is equivalent to this, = since=20 you would need an instance of the DCC state machine and Tx timer for = each of the=20 independent quotas the resources you save as compared to explicit=20 sub-session are irrelevant and there is the cost of=20 added system/implementation complexity and added potential for=20 interoperability issues since there would be two options to do = the=20 same thing.
 
If you=20 want to save signaling and resources then the DCC also support = for another=20 mechanism, an example of which is given in Flow X. As suggested in issue = 8 the=20 server need to support both mechanisms while the client implementation = may=20 support either one or the other or both. 
 
Personally,=20 I regard this thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue with=20 all the technical details, what should be changed where and why as = also=20 suggested by other people.
 
Regards
Marco
------_=_NextPart_001_01C3E018.0F593450-- From owner-aaa-wg@merit.edu Wed Jan 21 10:50: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 KAA27019 for ; Wed, 21 Jan 2004 10:50:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BD289122A; Wed, 21 Jan 2004 10:50:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57A8B91284; Wed, 21 Jan 2004 10:50: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 90FF69122A for ; Wed, 21 Jan 2004 10:50:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BD725DDD9; Wed, 21 Jan 2004 10:50:14 -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 114D45DD9A for ; Wed, 21 Jan 2004 10:50:14 -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 i0LFnVI28345; Wed, 21 Jan 2004 09:49:31 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jan 2004 09:49:32 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8E19@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'marco.stura@nokia.com'" Cc: john.loughney@nokia.com, juha-pekka.koskinen@nokia.com, leena.mattila@ericsson.com, aaa-wg@merit.edu, harri.hakala@ericsson.com, Karl-Heinz.Nenner@t-mobile.de, Benni.Alexander@nokia.com, patrik.teppo@ericsson.com, "'juha-pekka.koskinen@nokia.com'" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Wed, 21 Jan 2004 09:49:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E036.2760C9FA" 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_01C3E036.2760C9FA Content-Type: text/plain Hi Marco, I will put together a formal proposal as suggested. In the meantime, I quickly responded to your email. Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, January 21, 2004 6:14 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas >How does a client know when to use a sub-session for a quota request or not? If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function) that is supposed to provision the Service Element (e.g. GGSN) with all the service data flows information including IP filters, URI, Service-Id and/or Rating-Group etc. The service data flow information may be static or dynamic (e.g. derived from SIP/SDP). If your client does implement the independent quotas approach it will request for credit control authorization by opening a DCC sub-session every time a non-authorized service data flow is met. [Chris Richards ] Ouch! Effectively returning to a single-quota mechanism. Please note that most of those sub-sessions are short lasting sub-sessions. [Chris Richards ] Exactly. Since the user most likely will pay the services, also note that there will not be many sub-sessions in average per user. [Chris Richards ] That's not for us to say - and it's very difficult to speculate. I prefer to leave this up to the marketing departments of the operators. The client doesn't need to know what or how the server manage credit resources pools at all. [Chris Richards ] As long as a sub-session (single quota mechanism) is used every time as you described above. A flow example is provided in Issue 8. >Session > A session is a related progression of events devoted to a > particular activity. Each application SHOULD provide guidelines > as to when a session begins and ends. All Diameter packets with > the same Session-Identifier are considered to be part of the same > session. >Sub-session > A sub-session represents a distinct service (e.g., QoS or data > characteristics) provided to a given session. These services may > happen concurrently (e.g., simultaneous voice and data transfer > during the same session) or serially. These changes in sessions > are tracked with the Accounting-Sub-Session-Id. >Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the >session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context. Right. The QoS and all the bearer characteristics are attributes of the DCC session. Note that the RFC 3588 gives QoS or data characteristics as an example of a distinct service, it doesn't say that distinct service means only QoS or data characteristics. A distinct service may be something else as well e.g. a service data flow or a Rating-Group. [Chris Richards ] I would have thought that the DCC idea of a session would be somewhat similar to the examples in 3588. A Diameter session is characterized by the attributes of a session, yet a session in DCC is characterized by the user data being sent by the session at a particular time. A PDP Context (primary or secondary) can map to a DCC session that carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a non-authorized service data flow is met, the service element (e.g. GGSN) opens a DCC sub-session to perform credit control and get independent quota. Note that all the service data flows subject to the same rate can be grouped into Rating-Groups, thus the client just need to authorize the Rating-Group and share the granted units among all the used services within the Rating-Group. It doesn't necessarily means that you need to open a sub-session for each of the service data flows. [Chris Richards ] So, are you saying a sub-session is defined by how the bearer traffic being sent at that time is charged? In other words: for any traffic that the client does not have a quota for, it needs to open a sub-session. The other effect of course is that this puts the application back to single quota mechanism. The result of the above is that you get a DCC session for each PDP Context and associated temporary sub-sessions for different rating of content. If you multiplex quotas within the same session it is equivalent to this, since you would need an instance of the DCC state machine and Tx timer for each of the independent quotas the resources you save as compared to explicit sub-session are irrelevant and there is the cost of added system/implementation complexity and added potential for interoperability issues since there would be two options to do the same thing. [Chris Richards ] I agree that both require state. That the complexity saved by one method over the other. You're missing my point though: what is a session and how much should the client know about the charging system in order to define a sub-session. If you want to save signaling and resources then the DCC also support for another mechanism, an example of which is given in Flow X. As suggested in issue 8 the server need to support both mechanisms while the client implementation may support either one or the other or both. [Chris Richards ] This only works if the client knows what rates belong to what groups. If it does not (And it should not), then we're back to the single quota mechanism and flow X is irrelevant/not applicable. Personally, I regard this thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue with all the technical details, what should be changed where and why as also suggested by other people. [Chris Richards ] It's on it's way. Regards Marco ------_=_NextPart_001_01C3E036.2760C9FA Content-Type: text/html Message
Hi Marco,
 
I will  put together a formal proposal as suggested. In the meantime, I quickly responded to your email.

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, January 21, 2004 6:14 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

>How does a client know when to use a sub-session for a quota request or not?
 
If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function) that is supposed to
provision the Service Element (e.g. GGSN) with all the service data flows information including 
IP filters, URI, Service-Id and/or Rating-Group etc. The service data flow information may be
static or dynamic (e.g. derived from SIP/SDP).
If your client does implement the independent quotas approach it will request for credit control
authorization by opening a DCC sub-session every time a non-authorized service data flow is met.
[Chris Richards ] Ouch! Effectively returning to a single-quota mechanism. 
Please note that most of those sub-sessions are short lasting sub-sessions.
[Chris Richards ] Exactly. 
Since the user most likely will pay the services, also note that there will not be many sub-sessions
in average per user.
[Chris Richards ] That's not for us to say - and it's very difficult to speculate. I prefer to leave this up to the marketing departments of the operators. 
The client doesn't need to know what or how the server manage credit resources pools at all.
[Chris Richards ] As long as a sub-session (single quota mechanism) is used every time as you described above. 
A flow example is provided in Issue 8.
>Session
   >  A session is a related progression of events devoted to a 
   >  particular activity.  Each application SHOULD provide guidelines
   >  as to when a session begins and ends.  All Diameter packets with
   >   the same Session-Identifier are considered to be part of the same
   >   session.

      >Sub-session 
     > A sub-session represents a distinct service (e.g., QoS or data 
     > characteristics) provided to a given session.  These services may 
     > happen concurrently (e.g., simultaneous voice and data transfer 
     > during the same session) or serially.  These changes in sessions 
     > are tracked with the Accounting-Sub-Session-Id.

 
>Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the >session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context.
 
Right. The QoS and all the bearer characteristics are attributes of the DCC session.
Note that the RFC 3588 gives QoS or data characteristics as an example of a distinct service, it doesn't say that distinct
service means only QoS or data characteristics. A distinct service may be something else as well e.g. a service data flow or a Rating-Group.
[Chris Richards ] I would have thought that the DCC idea of a session would be somewhat similar to the examples in 3588. A Diameter session is characterized by the attributes of a session, yet a session in DCC is characterized by the user data being sent by the session at a particular time.  
 
A PDP Context (primary or secondary) can map to a DCC session that carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a non-authorized service data flow is met, the service element (e.g. GGSN) opens a DCC sub-session to perform credit control and get independent quota. Note that all the service data flows subject to the same rate can be grouped into Rating-Groups, thus the client just need to authorize the Rating-Group and share the granted units among all the used services within the Rating-Group. It doesn't necessarily means that you need to open a sub-session for each of the service data flows.
[Chris Richards ] So, are you saying a sub-session is defined by how the bearer traffic being sent at that time is charged? In other words: for any traffic that the client does not have a quota for, it needs to open a sub-session.
The other effect of course is that this puts the application back to single quota mechanism. 
The result of the above is that you get a DCC session for each PDP Context and associated temporary sub-sessions for different rating of content. If you multiplex quotas within the same session it is equivalent to this, since you would need an instance of the DCC state machine and Tx timer for each of the independent quotas the resources you save as compared to explicit sub-session are irrelevant and there is the cost of added system/implementation complexity and added potential for interoperability issues since there would be two options to do the same thing.
[Chris Richards ] I agree that both require state. That the complexity saved by one method over the other. You're missing my point though: what is a session and how much should the client know about the charging system in order to define a sub-session.  
 
If you want to save signaling and resources then the DCC also support for another mechanism, an example of which is given in Flow X. As suggested in issue 8 the server need to support both mechanisms while the client implementation may support either one or the other or both. 
[Chris Richards ] This only works if the client knows what rates belong to what groups. If it does not (And it should not), then we're back to the single quota mechanism and flow X is irrelevant/not applicable. 
 
Personally, I regard this thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue with all the technical details, what should be changed where and why as also suggested by other people.
[Chris Richards ] It's on it's way. 
 
Regards
Marco
------_=_NextPart_001_01C3E036.2760C9FA-- From owner-aaa-wg@merit.edu Wed Jan 21 11:30: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 LAA28524 for ; Wed, 21 Jan 2004 11:30:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2486F9122F; Wed, 21 Jan 2004 11:30:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AD6D91284; Wed, 21 Jan 2004 11:30: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 4537C9122F for ; Wed, 21 Jan 2004 11:30:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE58C5DDC6; Wed, 21 Jan 2004 11:30:12 -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 4BEB95DD9A for ; Wed, 21 Jan 2004 11:30:10 -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 i0LGT8V03188 for ; Wed, 21 Jan 2004 18:29:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 18:29:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 18:29:08 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 18:29:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E03B.B137DF10" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Wed, 21 Jan 2004 18:29:07 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03D0@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPgNi0/aDMTxBG7RNSEjAJyR+7gbAAAz3aw From: To: Cc: , , , , , , , , X-OriginalArrivalTime: 21 Jan 2004 16:29:08.0169 (UTC) FILETIME=[B178EB90:01C3E03B] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E03B.B137DF10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 I'm more and more convinced that you need a training session on how the = DCC application works in general and especially for multiple services in a user session. All your comments and claims are totally irrelevant to the DCC = application and disconnected from how the DCC application works. =20 THE CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER MANAGE CREDIT RESOURCES POOLS AT ALL AND IN ANY CASE. =20 Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 21 January, 2004 17:49 To: Stura Marco (Nokia-NET/Helsinki) Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka = (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; = harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander = Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka = (Nokia-NET/Tampere) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas Hi Marco, =20 I will put together a formal proposal as suggested. In the meantime, I = quickly responded to your email. Best Regards,=20 Chris.=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Wednesday, January 21, 2004 6:14 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; = leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; = Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas >How does a client know when to use a sub-session for a quota request or = not?=20 =20 If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule = Function) that is supposed to provision the Service Element (e.g. GGSN) with all the service data = flows information including=20 IP filters, URI, Service-Id and/or Rating-Group etc. The service data = flow information may be=20 static or dynamic (e.g. derived from SIP/SDP). If your client does implement the independent quotas approach it will = request for credit control authorization by opening a DCC sub-session every time a non-authorized = service data flow is met. [Chris Richards ] Ouch! Effectively returning to a single-quota = mechanism.=20 Please note that most of those sub-sessions are short lasting = sub-sessions. [Chris Richards ] Exactly.=20 Since the user most likely will pay the services, also note that there = will not be many sub-sessions in average per user. [Chris Richards ] That's not for us to say - and it's very difficult to = speculate. I prefer to leave this up to the marketing departments of the = operators.=20 The client doesn't need to know what or how the server manage credit = resources pools at all. [Chris Richards ] As long as a sub-session (single quota mechanism) is = used every time as you described above.=20 A flow example is provided in Issue 8. >Session=20 > A session is a related progression of events devoted to a=20 > particular activity. Each application SHOULD provide guidelines=20 > as to when a session begins and ends. All Diameter packets with=20 > the same Session-Identifier are considered to be part of the same = > session.=20 >Sub-session=20 > A sub-session represents a distinct service (e.g., QoS or data=20 > characteristics) provided to a given session. These services may = > happen concurrently (e.g., simultaneous voice and data transfer=20 > during the same session) or serially. These changes in sessions=20 > are tracked with the Accounting-Sub-Session-Id.=20 =20 >Are data characteristics or QoS represented by different rating of = content? Surely the QoS or data characteristics are attributes of the = >session not of the rating of the content. The paragraph above is very = similar to the 3GPP definition of secondary context.=20 =20 Right. The QoS and all the bearer characteristics are attributes of the = DCC session. Note that the RFC 3588 gives QoS or data characteristics as an example = of a distinct service, it doesn't say that distinct service means only QoS or data characteristics. A distinct service may = be something else as well e.g. a service data flow or a Rating-Group. [Chris Richards ] I would have thought that the DCC idea of a session = would be somewhat similar to the examples in 3588. A Diameter session is = characterized by the attributes of a session, yet a session in DCC is = characterized by the user data being sent by the session at a particular = time. =20 =20 A PDP Context (primary or secondary) can map to a DCC session that = carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). = Whenever a non-authorized service data flow is met, the service element = (e.g. GGSN) opens a DCC sub-session to perform credit control and get = independent quota. Note that all the service data flows subject to the = same rate can be grouped into Rating-Groups, thus the client just need = to authorize the Rating-Group and share the granted units among all the = used services within the Rating-Group. It doesn't necessarily means that = you need to open a sub-session for each of the service data flows. [Chris Richards ] So, are you saying a sub-session is defined by how the = bearer traffic being sent at that time is charged? In other words: for = any traffic that the client does not have a quota for, it needs to open = a sub-session. The other effect of course is that this puts the application back to = single quota mechanism.=20 The result of the above is that you get a DCC session for each PDP = Context and associated temporary sub-sessions for different rating of = content. If you multiplex quotas within the same session it is = equivalent to this, since you would need an instance of the DCC state = machine and Tx timer for each of the independent quotas the resources = you save as compared to explicit sub-session are irrelevant and there is = the cost of added system/implementation complexity and added potential = for interoperability issues since there would be two options to do the = same thing. [Chris Richards ] I agree that both require state. That the complexity = saved by one method over the other. You're missing my point though: what = is a session and how much should the client know about the charging = system in order to define a sub-session. =20 =20 If you want to save signaling and resources then the DCC also support = for another mechanism, an example of which is given in Flow X. As = suggested in issue 8 the server need to support both mechanisms while = the client implementation may support either one or the other or both.=20 [Chris Richards ] This only works if the client knows what rates belong = to what groups. If it does not (And it should not), then we're back to = the single quota mechanism and flow X is irrelevant/not applicable.=20 =20 Personally, I regard this thread as closed. Should you have more = questions/doubts that I didn't answer, please provide a formal issue = with all the technical details, what should be changed where and why as = also suggested by other people. [Chris Richards ] It's on it's way.=20 =20 Regards Marco ------_=_NextPart_001_01C3E03B.B137DF10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Chris,
 
I'm=20 more and more convinced that you need a training session on how the DCC=20 application works in
general and especially for multiple services=20 in a user session.
All=20 your comments and claims are totally irrelevant to the DCC=20 application and disconnected from
how=20 the DCC application works.
 
THE=20 CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER MANAGE = CREDIT
RESOURCES=20 POOLS AT ALL AND IN ANY = CASE.
 
Regards
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 21 January, 2004=20 17:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: = Loughney=20 John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere);=20 leena.mattila@ericsson.com; aaa-wg@merit.edu; = harri.hakala@ericsson.com;=20 Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo);=20 patrik.teppo@ericsson.com; Koskinen Juha-Pekka=20 (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC = Multiple=20 services in a user's session, i ndependent quotas

Hi=20 Marco,
 
I=20 will  put together a formal proposal as suggested. In the = meantime,=20 I quickly responded to your email.

Best=20 Regards,
Chris.

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Wednesday, January 21, 2004 6:14 AM
To: Richards, = Christopher=20 [RICH2:2Q40:EXCH]
Cc: john.loughney@nokia.com;=20 juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; = aaa-wg@merit.edu;=20 harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de;=20 Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com
Subject: RE:=20 [AAA-WG]: Issue: DCC Multiple services in a user's session, i = ndependent=20 quotas

>How = does a=20 client know when to use a sub-session for a quota request or = not?
 
If=20 we talk 3GPP, in SA2 they have defined the CRF (Charging Rule = Function) that=20 is supposed to
provision the Service Element (e.g. GGSN) with all the = service data=20 flows information including 
IP=20 filters, URI, Service-Id and/or Rating-Group etc. The service data = flow=20 information may be
static or dynamic (e.g. derived from = SIP/SDP).
If=20 your client does implement the independent quotas approach it=20 will request for credit control
authorization by opening a DCC = sub-session every=20 time a non-authorized service data flow is met.
[Chris Richards = ] Ouch!=20 Effectively returning to a single-quota=20 mechanism. 
Please note that most of = those sub-sessions=20 are short lasting sub-sessions.
[Chris Richards=20 = ] Exactly. 
Since the user most likely will pay the services, also = note that=20 there will not be many sub-sessions
in average per user.
[Chris Richards ] That's not for us = to say -=20 and it's very difficult to speculate. I prefer to leave this up to = the=20 marketing departments of the=20 operators. 
The client doesn't need to know what or how the = server=20 manage credit resources pools at all.
[Chris Richards = ] As long=20 as a sub-session (single quota mechanism) is used every time as you=20 described = above. 
A=20 flow example is provided in Issue 8.
>Session =
   >  A session is a related = progression=20 of events devoted to a 
   >  particular activity.  = Each=20 application SHOULD provide guidelines =
   >  as to when a session begins = and=20 ends.  All Diameter packets with =
   >   the same = Session-Identifier are=20 considered to be part of the same =
   >   session.=20

      >Sub-session 
  &n= bsp;  > A sub-session represents a = distinct=20 service (e.g., QoS or = data 
     > characteristics) provided to = a given=20 session.  These services=20 may 
     > happen concurrently (e.g., = simultaneous=20 voice and data transfer 
     > during the same session) or=20 serially.  These changes in=20 sessions 
     > are tracked with the=20 Accounting-Sub-Session-Id.

 
>Are data=20 characteristics or QoS represented by different rating of content? = Surely=20 the QoS or data characteristics are attributes of the >session = not of the=20 rating of the content. The paragraph above is very similar to the = 3GPP=20 definition of secondary context.
 
Right. The QoS and all the bearer characteristics are = attributes of=20 the DCC session.
Note that the RFC 3588 gives QoS or data characteristics as = an=20 example of a distinct service, it doesn't say that=20 distinct
service means only QoS or data = characteristics. A=20 distinct service may be something else as well e.g. a service data = flow or a=20 Rating-Group.
[Chris=20 Richards ] I would have thought that the DCC idea of a session = would be=20 somewhat similar to the examples in 3588. A Diameter session is=20 characterized by the attributes of a session, yet a session in = DCC is=20 characterized by the user data being sent by the session at a=20 particular = time.  
 
A PDP Context (primary or secondary) can map to a DCC = session that=20 carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier = etc.).=20 Whenever a non-authorized service data flow is met, the = service=20 element (e.g. GGSN) opens a DCC sub-session to perform=20 credit control and get independent = quota. Note=20 that all the service data flows subject to the same rate can be = grouped into=20 Rating-Groups, thus the client just need to authorize the = Rating-Group and=20 share the granted units among all the used services within the = Rating-Group.=20 It doesn't necessarily means that you need to open a sub-session for = each of=20 the service data flows.
[Chris Richards ] So, are you saying a = sub-session=20 is defined by how the bearer traffic being sent at that time is = charged? In other words: for any traffic that the client does not = have a=20 quota for, it needs to open a=20 sub-session.
The other effect of course is that this puts the = application=20 back to single=20 = quota mechanism. 
The result of the above is that you = get a DCC=20 session for each PDP Context and associated temporary sub-sessions = for=20 different rating of content. If you multiplex quotas within the same = session=20 it is equivalent to this, since you would need an instance of = the DCC=20 state machine and Tx timer for each of the independent quotas the = resources=20 you save as compared to explicit sub-session are = irrelevant and=20 there is the cost of added system/implementation complexity and = added=20 potential for interoperability issues since there would = be two=20 options to do the same thing.
[Chris Richards ] I agree that both require = state. That=20 the complexity saved by one method over the other. You're missing my = point=20 though: what is a session and how much should the client know = about the=20 charging system in order to define a=20 = sub-session.  
 
If you want to save signaling and = resources then=20 the DCC also support for another mechanism, an example of which = is=20 given in Flow X. As suggested in issue 8 the server need to support = both=20 mechanisms while the client implementation may support either one=20 or the other or both. 
[Chris Richards ] This only works if the client = knows=20 what rates belong to what groups. If it does not (And it should = not),=20 then we're back to the single quota mechanism and flow X is = irrelevant/not=20 applicable. 
 
Personally, = I regard this=20 thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue = with=20 all the technical details, what should be changed where and why = as also=20 suggested by other people.
[Chris Richards ] It's on it's=20 way. 
 
Regards
Marco
------_=_NextPart_001_01C3E03B.B137DF10-- From owner-aaa-wg@merit.edu Wed Jan 21 12:18:34 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 MAA00602 for ; Wed, 21 Jan 2004 12:18:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9F1791287; Wed, 21 Jan 2004 12:16:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E7529128C; Wed, 21 Jan 2004 12:16: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 AE8F491287 for ; Wed, 21 Jan 2004 12:16:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 988475DD99; Wed, 21 Jan 2004 12:16:40 -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 464955DDAF for ; Wed, 21 Jan 2004 12:16:39 -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 i0LHGbV25334 for ; Wed, 21 Jan 2004 19:16:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 19:16:36 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 19:16:35 +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_01C3E042.52934C90" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Wed, 21 Jan 2004 19:16:35 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03D1@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPgNi0/aDMTxBG7RNSEjAJyR+7gbAAAz3awAAIHVKA= From: To: Cc: , , , , , , , , X-OriginalArrivalTime: 21 Jan 2004 17:16:35.0950 (UTC) FILETIME=[52E1D0E0:01C3E042] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E042.52934C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 apologize for saying things a bit to strong, you know is getting very = late here in Finland and I'm getting tired. I wanted just to emphasize that in the current DCC the = client does not need to know or=20 manage the server resources in any case, even in the example of Flow X. =20 Looking forward for your formal issue Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext=20 Sent: 21 January, 2004 18:29 To: crich@nortelnetworks.com Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka = (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; = harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander = Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka = (Nokia-NET/Tampere) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas Hi Chris, =20 I'm more and more convinced that you need a training session on how the = DCC application works in general and especially for multiple services in a user session. All your comments and claims are totally irrelevant to the DCC = application and disconnected from how the DCC application works. =20 THE CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER MANAGE CREDIT RESOURCES POOLS AT ALL AND IN ANY CASE. =20 Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 21 January, 2004 17:49 To: Stura Marco (Nokia-NET/Helsinki) Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka = (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; = harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander = Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka = (Nokia-NET/Tampere) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas Hi Marco, =20 I will put together a formal proposal as suggested. In the meantime, I = quickly responded to your email. Best Regards,=20 Chris.=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Wednesday, January 21, 2004 6:14 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; = leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; = Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas >How does a client know when to use a sub-session for a quota request or = not?=20 =20 If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule = Function) that is supposed to provision the Service Element (e.g. GGSN) with all the service data = flows information including=20 IP filters, URI, Service-Id and/or Rating-Group etc. The service data = flow information may be=20 static or dynamic (e.g. derived from SIP/SDP). If your client does implement the independent quotas approach it will = request for credit control authorization by opening a DCC sub-session every time a non-authorized = service data flow is met. [Chris Richards ] Ouch! Effectively returning to a single-quota = mechanism.=20 Please note that most of those sub-sessions are short lasting = sub-sessions. [Chris Richards ] Exactly.=20 Since the user most likely will pay the services, also note that there = will not be many sub-sessions in average per user. [Chris Richards ] That's not for us to say - and it's very difficult to = speculate. I prefer to leave this up to the marketing departments of the = operators.=20 The client doesn't need to know what or how the server manage credit = resources pools at all. [Chris Richards ] As long as a sub-session (single quota mechanism) is = used every time as you described above.=20 A flow example is provided in Issue 8. >Session=20 > A session is a related progression of events devoted to a=20 > particular activity. Each application SHOULD provide guidelines=20 > as to when a session begins and ends. All Diameter packets with=20 > the same Session-Identifier are considered to be part of the same = > session.=20 >Sub-session=20 > A sub-session represents a distinct service (e.g., QoS or data=20 > characteristics) provided to a given session. These services may = > happen concurrently (e.g., simultaneous voice and data transfer=20 > during the same session) or serially. These changes in sessions=20 > are tracked with the Accounting-Sub-Session-Id.=20 =20 >Are data characteristics or QoS represented by different rating of = content? Surely the QoS or data characteristics are attributes of the = >session not of the rating of the content. The paragraph above is very = similar to the 3GPP definition of secondary context.=20 =20 Right. The QoS and all the bearer characteristics are attributes of the = DCC session. Note that the RFC 3588 gives QoS or data characteristics as an example = of a distinct service, it doesn't say that distinct service means only QoS or data characteristics. A distinct service may = be something else as well e.g. a service data flow or a Rating-Group. [Chris Richards ] I would have thought that the DCC idea of a session = would be somewhat similar to the examples in 3588. A Diameter session is = characterized by the attributes of a session, yet a session in DCC is = characterized by the user data being sent by the session at a particular = time. =20 =20 A PDP Context (primary or secondary) can map to a DCC session that = carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). = Whenever a non-authorized service data flow is met, the service element = (e.g. GGSN) opens a DCC sub-session to perform credit control and get = independent quota. Note that all the service data flows subject to the = same rate can be grouped into Rating-Groups, thus the client just need = to authorize the Rating-Group and share the granted units among all the = used services within the Rating-Group. It doesn't necessarily means that = you need to open a sub-session for each of the service data flows. [Chris Richards ] So, are you saying a sub-session is defined by how the = bearer traffic being sent at that time is charged? In other words: for = any traffic that the client does not have a quota for, it needs to open = a sub-session. The other effect of course is that this puts the application back to = single quota mechanism.=20 The result of the above is that you get a DCC session for each PDP = Context and associated temporary sub-sessions for different rating of = content. If you multiplex quotas within the same session it is = equivalent to this, since you would need an instance of the DCC state = machine and Tx timer for each of the independent quotas the resources = you save as compared to explicit sub-session are irrelevant and there is = the cost of added system/implementation complexity and added potential = for interoperability issues since there would be two options to do the = same thing. [Chris Richards ] I agree that both require state. That the complexity = saved by one method over the other. You're missing my point though: what = is a session and how much should the client know about the charging = system in order to define a sub-session. =20 =20 If you want to save signaling and resources then the DCC also support = for another mechanism, an example of which is given in Flow X. As = suggested in issue 8 the server need to support both mechanisms while = the client implementation may support either one or the other or both.=20 [Chris Richards ] This only works if the client knows what rates belong = to what groups. If it does not (And it should not), then we're back to = the single quota mechanism and flow X is irrelevant/not applicable.=20 =20 Personally, I regard this thread as closed. Should you have more = questions/doubts that I didn't answer, please provide a formal issue = with all the technical details, what should be changed where and why as = also suggested by other people. [Chris Richards ] It's on it's way.=20 =20 Regards Marco ------_=_NextPart_001_01C3E042.52934C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Chris,
 
apologize for saying things a bit to = strong,  you=20 know is getting very late here in Finland and I'm
getting tired. I wanted just to emphasize = that in the current=20 DCC the client does not need to know or =
manage the server=20 resources in any case, even in the example of Flow=20 X.
 
Looking forward for your formal=20 issue
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext =
Sent: 21=20 January, 2004 18:29
To: = crich@nortelnetworks.com
Cc:=20 Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka = (Nokia-NET/Tampere);=20 leena.mattila@ericsson.com; aaa-wg@merit.edu; = harri.hakala@ericsson.com;=20 Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo);=20 patrik.teppo@ericsson.com; Koskinen Juha-Pekka=20 (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC = Multiple=20 services in a user's session, i ndependent quotas

Hi=20 Chris,
 
I'm=20 more and more convinced that you need a training session on how the = DCC=20 application works in
general and especially for multiple=20 services in a user session.
All=20 your comments and claims are totally irrelevant to the DCC=20 application and disconnected from
how=20 the DCC application works.
 
THE CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER = MANAGE=20 CREDIT
RESOURCES POOLS AT ALL AND IN ANY=20 CASE.
 
Regards
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 21 January, 2004=20 17:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: = Loughney=20 John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere);=20 leena.mattila@ericsson.com; aaa-wg@merit.edu; = harri.hakala@ericsson.com;=20 Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo);=20 patrik.teppo@ericsson.com; Koskinen Juha-Pekka=20 (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC = Multiple=20 services in a user's session, i ndependent = quotas

Hi=20 Marco,
 
I=20 will  put together a formal proposal as suggested. In the=20 meantime, I quickly responded to your email.

Best=20 Regards,
Chris.

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Wednesday, January 21, 2004 6:14 AM
To: Richards, = Christopher=20 [RICH2:2Q40:EXCH]
Cc: john.loughney@nokia.com;=20 juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com;=20 aaa-wg@merit.edu; harri.hakala@ericsson.com;=20 Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com;=20 patrik.teppo@ericsson.com
Subject: RE: [AAA-WG]: Issue: = DCC=20 Multiple services in a user's session, i ndependent=20 quotas

>How does a=20 client know when to use a sub-session for a quota request or = not?
 
If we talk 3GPP, in SA2 they have defined the CRF = (Charging Rule=20 Function) that is supposed to
provision the Service Element (e.g. GGSN) with all the = service data=20 flows information including 
IP filters, URI, Service-Id and/or Rating-Group etc. The = service=20 data flow information may be
static or dynamic (e.g. derived from = SIP/SDP).
If your client does implement the independent quotas = approach it=20 will request for credit control
authorization by opening a DCC = sub-session=20 every time a non-authorized service data flow is = met.
[Chris Richards = ] Ouch!=20 Effectively returning to a single-quota=20 mechanism. 
Please note that most of=20 those sub-sessions are short lasting sub-sessions.
[Chris Richards=20 = ] Exactly. 
Since the user most likely will pay the services, = also note=20 that there will not be many sub-sessions
in average per user.
[Chris Richards ] That's not for = us to say -=20 and it's very difficult to speculate. I prefer to leave this up to = the=20 marketing departments of the=20 operators. 
The client doesn't need to know what or how = the server=20 manage credit resources pools at all.
[Chris Richards = ] As=20 long as a sub-session (single quota mechanism) is used every time = as you=20 described = above. 
A flow example is provided in Issue = 8.
>Session =
   >  A session is a related=20 progression of events devoted to a 
   > =20 particular activity.  Each application SHOULD provide=20 guidelines
  =20 >  as to when a session begins and ends.  All = Diameter=20 packets with
   >   the same = Session-Identifier are=20 considered to be part of the same =
   >   session.=20

      >Sub-session 
  &n= bsp;  > A sub-session represents a = distinct=20 service (e.g., QoS or = data 
     > characteristics) provided = to a given=20 session.  These services=20 may 
     > happen concurrently (e.g.,=20 simultaneous voice and data=20 transfer 
     > during the same session) or = serially.  These changes in=20 sessions 
     > are tracked with the=20 Accounting-Sub-Session-Id.

 
>Are data=20 characteristics or QoS represented by different rating of content? = Surely=20 the QoS or data characteristics are attributes of the >session = not of=20 the rating of the content. The paragraph above is very similar to = the 3GPP=20 definition of secondary context.
 
Right. The QoS and all the bearer characteristics are = attributes of=20 the DCC session.
Note that the RFC 3588 gives QoS or data characteristics = as an=20 example of a distinct service, it doesn't say that=20 distinct
service means only QoS or data = characteristics.=20 A distinct service may be something else as well e.g. a service = data flow=20 or a Rating-Group.
[Chris Richards ] I would have thought that = the DCC=20 idea of a session would be somewhat similar to the examples in = 3588. A=20 Diameter session is characterized by the attributes of a session,=20 yet a session in DCC is characterized by the user data = being=20 sent by the session at a particular=20 time.  
 
A PDP Context (primary or secondary) can map to a DCC = session that=20 carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier = etc.).=20 Whenever a non-authorized service data flow is met, the = service=20 element (e.g. GGSN) opens a DCC sub-session to perform=20 credit control = and get=20 independent quota. Note that all the service data flows subject to = the=20 same rate can be grouped into Rating-Groups, thus the client just = need to=20 authorize the Rating-Group and share the granted units among all = the used=20 services within the Rating-Group. It doesn't necessarily means = that you=20 need to open a sub-session for each of the service data = flows.
[Chris Richards = ] So,=20 are you saying a sub-session is defined by how the = bearer=20 traffic being sent at that time is charged? In other words: for = any=20 traffic that the client does not have a quota for, it needs to = open a=20 sub-session.
The other effect of course is that this puts the = application=20 back to single=20 = quota mechanism. 
The result of the above is that you = get a DCC=20 session for each PDP Context and associated temporary sub-sessions = for=20 different rating of content. If you multiplex quotas within the = same=20 session it is equivalent to this, since you would need an = instance of=20 the DCC state machine and Tx timer for each of the independent = quotas the=20 resources you save as compared to explicit sub-session are=20 irrelevant and there is the cost of = added system/implementation=20 complexity and added potential for interoperability issues since=20 there would be two options to do the same = thing.
[Chris Richards = ] I=20 agree that both require state. That the complexity saved by one = method=20 over the other. You're missing my point though: what is a session = and how=20 much should the client know about the charging system in = order to=20 define a=20 = sub-session.  
 
If you want to save signaling and = resources=20 then the DCC also support for another mechanism, an example = of which=20 is given in Flow X. As suggested in issue 8 the server need to = support=20 both mechanisms while the client implementation may support either = one=20 or the other or both. 
[Chris Richards ] This only works if the = client knows=20 what rates belong to what groups. If it does not (And it = should not),=20 then we're back to the single quota mechanism and flow X is = irrelevant/not=20 applicable. 
 
Personally, = I regard this=20 thread as closed. Should you have more questions/doubts that I didn't = answer, please provide a formal issue = with=20 all the technical details, what should be changed where and = why as=20 also suggested by other people.
[Chris Richards ] It's on it's=20 way. 
 
Regards
Marco
= ------_=_NextPart_001_01C3E042.52934C90-- From owner-aaa-wg@merit.edu Thu Jan 22 07:52:27 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 HAA20014 for ; Thu, 22 Jan 2004 07:52:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BD43F912AC; Thu, 22 Jan 2004 07:52:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8ED90912AD; Thu, 22 Jan 2004 07:52: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 5A5E4912AC for ; Thu, 22 Jan 2004 07:52:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DDDD5DDC7; Thu, 22 Jan 2004 07:52: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 ACF1F5DDC1 for ; Thu, 22 Jan 2004 07:52:11 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0MCqAqY025499 for ; Thu, 22 Jan 2004 13:52:10 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jan 2004 13:54:08 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: DCC Redirect AVPs in wrong command Date: Thu, 22 Jan 2004 13:52:01 +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 Description of issue: Redirect AVPs in wrong command Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 22.01.2004 Reference: Document: Diameter CCA-02 Comment type: T Priority: S Section: 3.1 Credit-Control-Request /CCR) command Rationale/Explanation of issues: AVPs related to the redirect: - Redirect-Host AVP - Redirect-Host-Usage AVP - Redirect-Max-Cache-Time AVP must be in CCA command not in CCR. Requested change: Section 3.1 Credit-Control-Request Command REMOVE: Redirect-Host AVP, Redirect-Host-Usage AVP and Redirect-Max-Cache-Time AVP Section 3.2 Credit-Control-Answer Command ADD: Redirect-Host AVP, Redirect-Host-Usage AVP and Redirect-Max-Cache-Time AVP From owner-aaa-wg@merit.edu Thu Jan 22 07:56: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 HAA20131 for ; Thu, 22 Jan 2004 07:56:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C1B7912AD; Thu, 22 Jan 2004 07:56:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DB72912AF; Thu, 22 Jan 2004 07:56: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 F36DF912AD for ; Thu, 22 Jan 2004 07:56:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9D235DDAD; Thu, 22 Jan 2004 07:56:25 -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 3AA465DD9F for ; Thu, 22 Jan 2004 07:56:25 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0MCuNYG018786 for ; Thu, 22 Jan 2004 13:56:24 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jan 2004 13:58:22 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: DCC Service-Identifier AVP MUST be a unique identifier Date: Thu, 22 Jan 2004 13:56:14 +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 Description of issue: Service-Identifier AVP MUST be a unique identifier Submitter name: Submitter email address: Date first submitted: 22.01.2004 Reference: Document: Diameter CCA-02 Comment type: E Priority: 1 Section: 4.1 Service-Specific Rating Input and Interoperability Rationale/Explanation of issues: In the section 4.1 (6. paragraph) it is stated that the Service-Identifier AVP SHOULD be a unique identifier for a given service as defined in the section 8.40. On the other hand in section 8.40 it is described, that the Service- Identifier MUST uniquely identify a given service. Requested change: Section 4.1 CHANGE: FROM: The Service-Identifier AVP SHOULD be a unique identifier for a given service as defined in the section 8.40. TO: The Service-Identifier AVP MUST be a unique identifier for a given service as defined in the section 8.40. From owner-aaa-wg@merit.edu Thu Jan 22 08:02:13 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 IAA20227 for ; Thu, 22 Jan 2004 08:02:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3516912AF; Thu, 22 Jan 2004 08:01:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADC62912B0; Thu, 22 Jan 2004 08:01: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 10893912AF for ; Thu, 22 Jan 2004 08:01:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id E900E5DD9E; Thu, 22 Jan 2004 08:01:54 -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 787B35DD8E for ; Thu, 22 Jan 2004 08:01:54 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0MD1rqY027760 for ; Thu, 22 Jan 2004 14:01:53 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jan 2004 14:03:52 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: DCC Enhanced data types of some AVPs Date: Thu, 22 Jan 2004 14:01:47 +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 Description of issue: Enhanced data types of some AVPs Submitter name: Submitter email address: Date first submitted: 22.01.2004 Reference: Document: Diameter CCA-02 Comment type: T Priority: 1 Section: 8.25 Service-Parameter-Value AVP, 8.31 Value-Digit AVP and 8.36 Service-Specific-Units AVP Rationale/Explanation of issues: Data types of some AVPs need to be enhanced to better fit their purpose. 8.25 Service-Parameter-Value AVP Data type UTF8string prevents handling of bit-mapped and integer fields. An UTF8string can be also carried in an OctetString, if desired. 8.31 Value-Digit AVP Due to some promotions and bonus offers subscriber can earn money (e.g. received calls add bonus) when he/she use services, and thus Cost-Information/Cost AVP can indicate negative values. To be able to send also negative values, the type Integer64 should be used, since it supports signed values. 8.36 CC-Service-Specific-Units AVP If the AVP specifies the NUMBER of service specific units, it is better to have data type Unsigned64, instead of OctetString. Requested change: Section 8.25 Service-Parameter-Value AVP CHANGE: FROM: The Service-Parameter-Value AVP is of type UTF8String .... TO: The Service-Parameter-Value AVP is of type OctetString.... Section 8.31 Value-Digit AVP CHANGE: FROM: The Value-Digits AVP is of type Unsigned64 TO: The Value-Digits AVP is of type Integer64 Section 8.36 CC-Service-Specific-Units AVP CHANGE: FROM: The CC-Service-Specific-Units AVP (AVP Code 417) is of type OctetString.... TO: The CC-Service-Specific-Units AVP (AVP Code 417) is of type Unsigned64... Section 8.16 Granted-Service-Unit AVP CHANGE: 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 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. From owner-aaa-wg@merit.edu Thu Jan 22 08:10:05 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 IAA20297 for ; Thu, 22 Jan 2004 08:10:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 109E4912B0; Thu, 22 Jan 2004 08:09:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC28C912B1; Thu, 22 Jan 2004 08:09: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 89811912B0 for ; Thu, 22 Jan 2004 08:09:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7433C5DDDE; Thu, 22 Jan 2004 08:09:50 -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 C09D25DDB6 for ; Thu, 22 Jan 2004 08:09:49 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0MD9nqY029988 for ; Thu, 22 Jan 2004 14:09:49 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jan 2004 14:11:47 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: DCC new Fault Code 401X Date: Thu, 22 Jan 2004 14:09:43 +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 Description of issue: New Fault code 401X Submitter name: Harri hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: 22.01.2004 Reference: Document: Diameter CCA-02 Comment type: T Priority: 1 Section: 9.1 Transient Failure Rationale/Explanation of issues: The current Fault Code 4010 DIAMETER_END_USER_SERVICE_DENIED doesn't classify why the service is denied; is the reason some service restrictions or whether the end-user's account can not cover the requested service. It would be more informative to have own fault code to indicate that end user's account can't cover the requested service. Requested change: Section 9.1 Transient Failure CHANGE: FROM: DIAMETER_END_USER_SERVICE_DENIED 4010 The credit-control server denies the service request due to service restrictions or limitations related to the end-user, for example the end-user's account could not cover the requested service. The possibly reported used-service-units with the CCR are deducted. TO: DIAMETER_END_USER_SERVICE_DENIED 4010 The credit-control server denies the service request due to service restrictions. If the CCR contained used-service-units they are deducted, if possible. ADD: DIAMETER_CREDIT_LIMIT_REACHED 401X The credit-control server denies the service request since the end-user's account could not cover the requested service. If the CCR contained used-service-units they are deducted, if possible. From owner-aaa-wg@merit.edu Thu Jan 22 13:45: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 NAA03426 for ; Thu, 22 Jan 2004 13:45:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 881A591218; Thu, 22 Jan 2004 13:45:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2C9B912A6; Thu, 22 Jan 2004 13:45: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 2F8F191218 for ; Thu, 22 Jan 2004 13:45:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B074B5DD91; Thu, 22 Jan 2004 13:45:10 -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 E5A735DD8C for ; Thu, 22 Jan 2004 13:45:08 -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 i0MIiw022650; Thu, 22 Jan 2004 18:44:58 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 18:44:59 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'leena.mattila@ericsson.com'" , "'aaa-wg@merit.edu'" , "'harri.hakala@ericsson.com'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'patrik.teppo@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Thu, 22 Jan 2004 18:44:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E117.D5E5ED3E" 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_01C3E117.D5E5ED3E Content-Type: text/plain Marco, all, I'm afraid I can't see either how the proposed mechanism meets the requirements for IP Flow Charging in 3GPP. We would like to make sure we can find a mechanism which everyone is happy with and which meets those requirements. On a procedural note, I don't agree we are restricted to proposals which "fit seamlessly within all the existing functionalities defined in the DCC" - this is too strong. Of course proposals must result in a clean and sensible overall protocol, but the draft is not yet approved. We expect to be entitled to submit any proposal - including changes to the "existing functionalities" - and have it judged on technical merits. As Chris said we will submit a formal issue when we have a detailed proposal together, hopefully early next week. In the meantime, I wonder if I could pose a couple of questions which might help clear up mis-understanding on both sides. Please correct me if I have mis-understood anything and apologies to the non-3GPP crowd on the list for the 3GPP language below: Question 1: a) a user establishes a Secondary PDP Context - this causes a new DCC session to be established b) the user sends packets matching 2 separate charging rules at the client with different charging keys/rating groups (i.e. that need to be rated differently) c) the client establishes a new DCC sub-session within the existing session and asks for Service Units for both rating groups (rg1 and rg2) d) server returns 10mb for rg1 and 10 minutes for rg2. This is within one sub-session, so I understand that this means that the user can have 10mb of rg1 traffic OR 10 minutes of rg2 traffic OR some combination (e.g. 5MB + 5minutes - I will omit to mention combinations below for brevity). (btw - the fact that this is OR and not AND is far from clear in the draft and is rather important!). e) the user sends packets matching a 3rd charging rule for a 3rd rating group (rg3). Question: is the client *required* to establish a new sub-session for this flow ? If so, I understand the quota returned will be completely independent from that provided in (d) above. So, the if the server returns 20mb then the user is now entitled to 10MB of rg1 OR 10 min of rg2) AND (20mb of rg3) and we have credit fragmentation. If not, then the client must send a new request for the existing subsession. Does it include all three rating groups and receive one quota covering all three (in an OR fashion) ? or does it send a request just for rg3, in which case how is the returned quota interpreted ? Question 2: (a) to (c) as Question 1: (d) the server determines that it cannot allocate a pool across rg1 and rg2 because they are to be funded out of different accounts. Question: How does the server indicate this to the client ? Is this to do with the 'Credit-Pool-ID' AVP I saw mentioned in one of the emails. I didn't find this in the draft - is it defined somewhere else ? Question 3: (a) to (d) as Question 1: The server wants to indicate that the quota provided for rg1 is only valid for 1 hour, after which re-authorisation must be sought. I guess the server includes the Validity-Time AVP to indicate this. Question: The Validity-Time seems to be associated with the whole CC-Answer, not with one of the rating groups - so am I correct in assuming that all the rating groups within this sub-session need to be re-authorised at once ? Best regards, Mark Watson -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 21 January 2004 17:17 To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Chris, apologize for saying things a bit to strong, you know is getting very late here in Finland and I'm getting tired. I wanted just to emphasize that in the current DCC the client does not need to know or manage the server resources in any case, even in the example of Flow X. Looking forward for your formal issue Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Sent: 21 January, 2004 18:29 To: crich@nortelnetworks.com Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Chris, I'm more and more convinced that you need a training session on how the DCC application works in general and especially for multiple services in a user session. All your comments and claims are totally irrelevant to the DCC application and disconnected from how the DCC application works. THE CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER MANAGE CREDIT RESOURCES POOLS AT ALL AND IN ANY CASE. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 21 January, 2004 17:49 To: Stura Marco (Nokia-NET/Helsinki) Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere) Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Marco, I will put together a formal proposal as suggested. In the meantime, I quickly responded to your email. Best Regards, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, January 21, 2004 6:14 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas >How does a client know when to use a sub-session for a quota request or not? If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function) that is supposed to provision the Service Element (e.g. GGSN) with all the service data flows information including IP filters, URI, Service-Id and/or Rating-Group etc. The service data flow information may be static or dynamic (e.g. derived from SIP/SDP). If your client does implement the independent quotas approach it will request for credit control authorization by opening a DCC sub-session every time a non-authorized service data flow is met. [Chris Richards ] Ouch! Effectively returning to a single-quota mechanism. Please note that most of those sub-sessions are short lasting sub-sessions. [Chris Richards ] Exactly. Since the user most likely will pay the services, also note that there will not be many sub-sessions in average per user. [Chris Richards ] That's not for us to say - and it's very difficult to speculate. I prefer to leave this up to the marketing departments of the operators. The client doesn't need to know what or how the server manage credit resources pools at all. [Chris Richards ] As long as a sub-session (single quota mechanism) is used every time as you described above. A flow example is provided in Issue 8. >Session > A session is a related progression of events devoted to a > particular activity. Each application SHOULD provide guidelines > as to when a session begins and ends. All Diameter packets with > the same Session-Identifier are considered to be part of the same > session. >Sub-session > A sub-session represents a distinct service (e.g., QoS or data > characteristics) provided to a given session. These services may > happen concurrently (e.g., simultaneous voice and data transfer > during the same session) or serially. These changes in sessions > are tracked with the Accounting-Sub-Session-Id. >Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the >session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context. Right. The QoS and all the bearer characteristics are attributes of the DCC session. Note that the RFC 3588 gives QoS or data characteristics as an example of a distinct service, it doesn't say that distinct service means only QoS or data characteristics. A distinct service may be something else as well e.g. a service data flow or a Rating-Group. [Chris Richards ] I would have thought that the DCC idea of a session would be somewhat similar to the examples in 3588. A Diameter session is characterized by the attributes of a session, yet a session in DCC is characterized by the user data being sent by the session at a particular time. A PDP Context (primary or secondary) can map to a DCC session that carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a non-authorized service data flow is met, the service element (e.g. GGSN) opens a DCC sub-session to perform credit control and get independent quota. Note that all the service data flows subject to the same rate can be grouped into Rating-Groups, thus the client just need to authorize the Rating-Group and share the granted units among all the used services within the Rating-Group. It doesn't necessarily means that you need to open a sub-session for each of the service data flows. [Chris Richards ] So, are you saying a sub-session is defined by how the bearer traffic being sent at that time is charged? In other words: for any traffic that the client does not have a quota for, it needs to open a sub-session. The other effect of course is that this puts the application back to single quota mechanism. The result of the above is that you get a DCC session for each PDP Context and associated temporary sub-sessions for different rating of content. If you multiplex quotas within the same session it is equivalent to this, since you would need an instance of the DCC state machine and Tx timer for each of the independent quotas the resources you save as compared to explicit sub-session are irrelevant and there is the cost of added system/implementation complexity and added potential for interoperability issues since there would be two options to do the same thing. [Chris Richards ] I agree that both require state. That the complexity saved by one method over the other. You're missing my point though: what is a session and how much should the client know about the charging system in order to define a sub-session. If you want to save signaling and resources then the DCC also support for another mechanism, an example of which is given in Flow X. As suggested in issue 8 the server need to support both mechanisms while the client implementation may support either one or the other or both. [Chris Richards ] This only works if the client knows what rates belong to what groups. If it does not (And it should not), then we're back to the single quota mechanism and flow X is irrelevant/not applicable. Personally, I regard this thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue with all the technical details, what should be changed where and why as also suggested by other people. [Chris Richards ] It's on it's way. Regards Marco ------_=_NextPart_001_01C3E117.D5E5ED3E Content-Type: text/html Message
Marco, all,
 
I'm afraid I can't see either how the proposed mechanism meets the requirements for IP Flow Charging in 3GPP. We would like to make sure we can find a mechanism which everyone is happy with and which meets those requirements.
 
On a procedural note, I don't agree we are restricted to proposals which "fit seamlessly within all the existing functionalities defined in the DCC" - this is too strong. Of course proposals must result in a clean and sensible overall protocol, but the draft is not yet approved. We expect to be entitled to submit any proposal - including changes to the "existing functionalities" - and have it judged on technical merits.
 
As Chris said we will submit a formal issue when we have a detailed proposal together, hopefully early next week.
 
In the meantime, I wonder if I could pose a couple of questions which might help clear up mis-understanding on both sides. Please correct me if I have mis-understood anything and apologies to the non-3GPP crowd on the list for the 3GPP language below:
 
Question 1:
a) a user establishes a Secondary PDP Context - this causes a new DCC session to be established
b) the user sends packets matching 2 separate charging rules at the client with different charging keys/rating groups (i.e. that need to be rated differently)
c) the client establishes a new DCC sub-session within the existing session and asks for Service Units for both rating groups (rg1 and rg2)
d) server returns 10mb for rg1 and 10 minutes for rg2. This is within one sub-session, so I understand that this means that the user can have 10mb of rg1 traffic OR 10 minutes of rg2 traffic OR some combination (e.g. 5MB + 5minutes - I will omit to mention combinations below for brevity). (btw - the fact that this is OR and not AND is far from clear in the draft and is rather important!).
e) the user sends packets matching a 3rd charging rule for a 3rd rating group (rg3).
 
Question: is the client *required* to establish a new sub-session for this flow ? If so, I understand the quota returned will be completely independent from that provided in (d) above. So, the if the server returns 20mb then the user is now entitled to 10MB of rg1 OR 10 min of rg2) AND (20mb of rg3) and we have credit fragmentation.
 
If not, then the client must send a new request for the existing subsession. Does it include all three rating groups and receive one quota covering all three (in an OR fashion) ? or does it send a request just for rg3, in which case how is the returned quota interpreted ?
 
Question 2:
(a) to (c) as Question 1:
(d) the server determines that it cannot allocate a pool across rg1 and rg2 because they are to be funded out of different accounts.
 
Question: How does the server indicate this to the client ? Is this to do with the 'Credit-Pool-ID' AVP I saw mentioned in one of the emails. I didn't find this in the draft - is it defined somewhere else ?
 
Question 3:
(a) to (d) as Question 1:
The server wants to indicate that the quota provided for rg1 is only valid for 1 hour, after which re-authorisation must be sought. I guess the server includes the Validity-Time AVP to indicate this.
 
Question: The Validity-Time seems to be associated with the whole CC-Answer, not with one of the rating groups - so am I correct in assuming that all the rating groups within this sub-session need to be re-authorised at once ?
 
Best regards,
 
Mark Watson
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 21 January 2004 17:17
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Chris,
 
apologize for saying things a bit to strong,  you know is getting very late here in Finland and I'm
getting tired. I wanted just to emphasize that in the current DCC the client does not need to know or
manage the server resources in any case, even in the example of Flow X.
 
Looking forward for your formal issue
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext
Sent: 21 January, 2004 18:29
To: crich@nortelnetworks.com
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Chris,
 
I'm more and more convinced that you need a training session on how the DCC application works in
general and especially for multiple services in a user session.
All your comments and claims are totally irrelevant to the DCC application and disconnected from
how the DCC application works.
 
THE CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER MANAGE CREDIT
RESOURCES POOLS AT ALL AND IN ANY CASE.
 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 21 January, 2004 17:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Alexander Benni (Nokia-NET/Espoo); patrik.teppo@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Marco,
 
I will  put together a formal proposal as suggested. In the meantime, I quickly responded to your email.

Best Regards,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, January 21, 2004 6:14 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; harri.hakala@ericsson.com; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

>How does a client know when to use a sub-session for a quota request or not?
 
If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function) that is supposed to
provision the Service Element (e.g. GGSN) with all the service data flows information including 
IP filters, URI, Service-Id and/or Rating-Group etc. The service data flow information may be
static or dynamic (e.g. derived from SIP/SDP).
If your client does implement the independent quotas approach it will request for credit control
authorization by opening a DCC sub-session every time a non-authorized service data flow is met.
[Chris Richards ] Ouch! Effectively returning to a single-quota mechanism. 
Please note that most of those sub-sessions are short lasting sub-sessions.
[Chris Richards ] Exactly. 
Since the user most likely will pay the services, also note that there will not be many sub-sessions
in average per user.
[Chris Richards ] That's not for us to say - and it's very difficult to speculate. I prefer to leave this up to the marketing departments of the operators. 
The client doesn't need to know what or how the server manage credit resources pools at all.
[Chris Richards ] As long as a sub-session (single quota mechanism) is used every time as you described above. 
A flow example is provided in Issue 8.
>Session
   >  A session is a related progression of events devoted to a 
   >  particular activity.  Each application SHOULD provide guidelines
   >  as to when a session begins and ends.  All Diameter packets with
   >   the same Session-Identifier are considered to be part of the same
   >   session.

      >Sub-session 
     > A sub-session represents a distinct service (e.g., QoS or data 
     > characteristics) provided to a given session.  These services may 
     > happen concurrently (e.g., simultaneous voice and data transfer 
     > during the same session) or serially.  These changes in sessions 
     > are tracked with the Accounting-Sub-Session-Id.

 
>Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the >session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context.
 
Right. The QoS and all the bearer characteristics are attributes of the DCC session.
Note that the RFC 3588 gives QoS or data characteristics as an example of a distinct service, it doesn't say that distinct
service means only QoS or data characteristics. A distinct service may be something else as well e.g. a service data flow or a Rating-Group.
[Chris Richards ] I would have thought that the DCC idea of a session would be somewhat similar to the examples in 3588. A Diameter session is characterized by the attributes of a session, yet a session in DCC is characterized by the user data being sent by the session at a particular time.  
 
A PDP Context (primary or secondary) can map to a DCC session that carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a non-authorized service data flow is met, the service element (e.g. GGSN) opens a DCC sub-session to perform credit control and get independent quota. Note that all the service data flows subject to the same rate can be grouped into Rating-Groups, thus the client just need to authorize the Rating-Group and share the granted units among all the used services within the Rating-Group. It doesn't necessarily means that you need to open a sub-session for each of the service data flows.
[Chris Richards ] So, are you saying a sub-session is defined by how the bearer traffic being sent at that time is charged? In other words: for any traffic that the client does not have a quota for, it needs to open a sub-session.
The other effect of course is that this puts the application back to single quota mechanism. 
The result of the above is that you get a DCC session for each PDP Context and associated temporary sub-sessions for different rating of content. If you multiplex quotas within the same session it is equivalent to this, since you would need an instance of the DCC state machine and Tx timer for each of the independent quotas the resources you save as compared to explicit sub-session are irrelevant and there is the cost of added system/implementation complexity and added potential for interoperability issues since there would be two options to do the same thing.
[Chris Richards ] I agree that both require state. That the complexity saved by one method over the other. You're missing my point though: what is a session and how much should the client know about the charging system in order to define a sub-session.  
 
If you want to save signaling and resources then the DCC also support for another mechanism, an example of which is given in Flow X. As suggested in issue 8 the server need to support both mechanisms while the client implementation may support either one or the other or both. 
[Chris Richards ] This only works if the client knows what rates belong to what groups. If it does not (And it should not), then we're back to the single quota mechanism and flow X is irrelevant/not applicable. 
 
Personally, I regard this thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue with all the technical details, what should be changed where and why as also suggested by other people.
[Chris Richards ] It's on it's way. 
 
Regards
Marco
------_=_NextPart_001_01C3E117.D5E5ED3E-- From owner-aaa-wg@merit.edu Fri Jan 23 03:18: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 DAA18053 for ; Fri, 23 Jan 2004 03:18:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C526912C3; Fri, 23 Jan 2004 03:17:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1475912C4; Fri, 23 Jan 2004 03: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 EC967912C3 for ; Fri, 23 Jan 2004 03:17:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2B1A5DDD5; Fri, 23 Jan 2004 03:17:47 -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 1319F5DDCB for ; Fri, 23 Jan 2004 03:17:47 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0N8HjAh024873; Fri, 23 Jan 2004 09:17:45 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jan 2004 09:19:47 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "Leena Mattila (TU/LMF)" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'juha-pekka.koskinen@nokia.com'" , Christopher Richards , Javier Gonzalez Gallego Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Fri, 23 Jan 2004 09:17:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Mark, >I'm afraid I can't see either how the proposed mechanism meets the requirements >for IP Flow Charging in 3GPP. We would like to make sure we can find a mechanism >which everyone is happy with and which meets those requirements. I believe that we can find a mechanism which everyone is happy with. >On a procedural note, I don't agree we are restricted to proposals which "fit >seamlessly within all the existing functionalities defined in the DCC" - this >is too strong. Of course proposals must result in a clean and sensible overall >protocol, but the draft is not yet approved. We expect to be entitled to submit >any proposal - including changes to the "existing functionalities" - and have it >judged on technical merits. Because the DCC is intended to be a generic credit control application to different kind of services in different environments, it defines certain basic mechanism valid for all application/systems and optional features valid for certain services. The multiple services in a single credit control session is optional feature (a bit 3GPP specific, I guess) in credit control draft, that is all applications/systems are not forced to support it. In other words the support of multiple services is not mandatory for all CC clients and CC servers. These optional features shall fit seamlessly within all the existing basic mechanism, e.g. session based credit control, failure procedures, state machines, etc. Due to one specific service we should not change or add more complex logic for basic parts and thus add complexity for applications which do not use that service. >As Chris said we will submit a formal issue when we have a detailed proposal together, >hopefully early next week. It may take time so early next week is fine. regards..........Harri From owner-aaa-wg@merit.edu Fri Jan 23 03:31: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 DAA18279 for ; Fri, 23 Jan 2004 03:31:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 873D291235; Fri, 23 Jan 2004 03:30:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48F3C912C4; Fri, 23 Jan 2004 03:30: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 C2D8C91235 for ; Fri, 23 Jan 2004 03:30:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id A079A5DD9D; Fri, 23 Jan 2004 03:30:44 -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 CDA605DDA1 for ; Fri, 23 Jan 2004 03:30:42 -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 i0N8UfY12845 for ; Fri, 23 Jan 2004 10:30:41 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Jan 2004 10:29:31 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 10:29:29 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 10:29:28 +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]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Fri, 23 Jan 2004 10:29:29 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03DB@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPhF9k3d1aicyjSSlqLWniGey8ZTwAcffcQ From: To: Cc: , , , , , , , , , , X-OriginalArrivalTime: 23 Jan 2004 08:29:28.0696 (UTC) FILETIME=[04655780:01C3E18B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mark, >I'm afraid I can't see either how the proposed mechanism meets the >requirements for IP Flow Charging in 3GPP. We would like to make sure = we=20 >can >find a mechanism which everyone is happy with and which meets those >requirements. Yes, I would like to find a mechanism which everyone is happy with as = well. >We expect to >be entitled to submit any proposal - including changes to the "existing >functionalities" - and have it judged on technical merits. Definitely you are entitled, I've never say that you are not. I was even saying that I'm not the one neglecting a good proposal, so no = problems at all to judge on technical merits. The problem is that so far = I've seen very fragmented proposals suggesting to add AVPs here and = there,=20 it was extremely difficult to understand the reason of the proposals and = impossible to get the whole picture. I even asked questions to which I've never got answer. The only thing we have been able to catch from = this=20 long discussion was a requirement for independent quotas, that's why we = are=20 now discussing sub-sessions. We have requested sometime ago a structured formal issue, it really help to understand the potential problem and it=20 gives us a way to track the issue and try to resolve the issue. >As Chris said we will submit a formal issue when we have a detailed=20 >proposal >together, hopefully early next week. Great! That is what we would have like to see since the beginning of=20 this discussion. >In the meantime, I wonder if I could pose a couple of questions which = might >help clear up mis-understanding on both sides. Please correct me if I = have >mis-understood anything and apologies to the non-3GPP crowd on the list = for >the 3GPP language below: I'll send separate mail addressing your technical questions, so that we = may=20 attempt to find out if there is a gap and fix it. Regards Marco From owner-aaa-wg@merit.edu Fri Jan 23 04:35: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 EAA20830 for ; Fri, 23 Jan 2004 04:35:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 456D6912C4; Fri, 23 Jan 2004 04:35:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10BA1912C6; Fri, 23 Jan 2004 04:35: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 71275912C4 for ; Fri, 23 Jan 2004 04:35:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 521385DDC5; Fri, 23 Jan 2004 04:35:17 -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 BB9555DDA1 for ; Fri, 23 Jan 2004 04:35:16 -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 i0N9ZBP24447; Fri, 23 Jan 2004 09:35:11 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Jan 2004 09:35:12 -0000 Message-ID: From: "Mark Watson" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'Patrik Teppo (KA/EAB)'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Date: Fri, 23 Jan 2004 09:35:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E194.31AD3470" 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_01C3E194.31AD3470 Content-Type: text/plain Harri, Yes, I agree - different customers for the Diameter CC specification have different requirements, so I have no problem with some capabilities being optional. Nor any problem with ensuring that those who do not need such options are not impacted by their existence in the specification. My point was just that to get an overall clean and consistent mechanism, which meets the above criterion, may mean changes to the existing draft, not just 'grafted on' additions. The existing draft is not approved and so nothing is 'sacred' - Such changes should not be 'ruled out' a priori as appeared the intention of Marco's mail. Anyway, let's see where we get on the particular issue - probably there will be a clean solution which does not mean changes to the basic mechanisms - it was just a procedural point. ...Mark -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: 23 January 2004 08:18 To: Watson, Mark [MOP:EP10:EXCH]; 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Hi Mark, >I'm afraid I can't see either how the proposed mechanism meets the >requirements for IP Flow Charging in 3GPP. We would like to make sure >we can find a mechanism which everyone is happy with and which meets >those requirements. I believe that we can find a mechanism which everyone is happy with. >On a procedural note, I don't agree we are restricted to proposals >which "fit >seamlessly within all the existing functionalities defined in the DCC" - this >is too strong. Of course proposals must result in a clean and sensible overall >protocol, but the draft is not yet approved. We expect to be entitled to submit >any proposal - including changes to the "existing functionalities" - and have it >judged on technical merits. Because the DCC is intended to be a generic credit control application to different kind of services in different environments, it defines certain basic mechanism valid for all application/systems and optional features valid for certain services. The multiple services in a single credit control session is optional feature (a bit 3GPP specific, I guess) in credit control draft, that is all applications/systems are not forced to support it. In other words the support of multiple services is not mandatory for all CC clients and CC servers. These optional features shall fit seamlessly within all the existing basic mechanism, e.g. session based credit control, failure procedures, state machines, etc. Due to one specific service we should not change or add more complex logic for basic parts and thus add complexity for applications which do not use that service. >As Chris said we will submit a formal issue when we have a detailed >proposal together, >hopefully early next week. It may take time so early next week is fine. regards..........Harri ------_=_NextPart_001_01C3E194.31AD3470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, = i ndependent quotas

Harri,

Yes, I agree - different customers for the Diameter = CC specification have different requirements, so I have no problem with = some capabilities being optional. Nor any problem with ensuring that = those who do not need such options are not impacted by their existence = in the specification.

My point was just that to get an overall clean and = consistent mechanism, which meets the above criterion, may mean changes = to the existing draft, not just 'grafted on' additions. The existing = draft is not approved and so nothing is 'sacred' - Such changes should = not be 'ruled out' a priori as appeared the intention of Marco's = mail.

Anyway, let's see where we get on the particular = issue - probably there will be a clean solution which does not mean = changes to the basic mechanisms - it was just a procedural = point.

...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: 23 January 2004 08:18
To: Watson, Mark [MOP:EP10:EXCH]; = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Richards, Christopher = [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]

Subject: RE: [AAA-WG]: Issue: DCC Multiple services = in a user's session, i ndependent quotas


Hi Mark,

>I'm afraid I can't see either how the proposed = mechanism meets the
>requirements for IP Flow Charging in 3GPP. We = would like to make sure
>we can find a mechanism which everyone is happy = with and which meets
>those requirements.
I believe that we can find a mechanism which = everyone is happy with.

>On a procedural note, I don't agree we are = restricted to proposals
>which "fit
>seamlessly within all the existing = functionalities defined in the DCC" - this
>is too strong. Of course proposals must result = in a clean and sensible overall
>protocol, but the draft is not yet approved. We = expect to be entitled to submit
>any proposal - including changes to the = "existing functionalities" - and have it
>judged on technical merits.
Because the DCC is intended to be a generic credit = control application to different kind of services in different = environments, it defines certain basic mechanism valid for all =

application/systems and optional features valid for = certain services. The multiple services in a single credit control = session is optional feature (a bit 3GPP specific, I guess) in credit = control draft, that is all applications/systems are not forced to = support it. In other words the support of multiple services is not = mandatory for all CC clients and

CC servers. These optional features shall fit = seamlessly within all the existing basic mechanism, e.g. session based = credit control, failure procedures, state machines, etc.

Due to one specific service we should not change or = add more complex logic for basic parts
and thus add complexity for applications which do = not use that service.

>As Chris said we will submit a formal issue when = we have a detailed
>proposal together,
>hopefully early next week.
It may take time so early next week is fine.

regards..........Harri




------_=_NextPart_001_01C3E194.31AD3470-- From owner-aaa-wg@merit.edu Fri Jan 23 05:28: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 FAA23089 for ; Fri, 23 Jan 2004 05:28:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79E3191236; Fri, 23 Jan 2004 05:27:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43AA6912C6; Fri, 23 Jan 2004 05:27: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 2F5A791236 for ; Fri, 23 Jan 2004 05:27:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17B245DE08; Fri, 23 Jan 2004 05:27:47 -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 189AD5DE1A for ; Fri, 23 Jan 2004 05:27:46 -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 i0NARjV18937 for ; Fri, 23 Jan 2004 12:27:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Jan 2004 12:27:43 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 12:27:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 12:27:43 +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 Credit Control Application WGLC Status Date: Fri, 23 Jan 2004 12:27:43 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPhmMAWrG5U7k+ETc2ztmHmUOUxXQAAmnjw From: To: Cc: , , X-OriginalArrivalTime: 23 Jan 2004 10:27:43.0694 (UTC) FILETIME=[89581EE0:01C3E19B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello all, As a reminder, current set of issues for the CCA can be found here: http://danforsberg.info:8080/draft-ietf-aaa-diameter-cc/index For new issues, please send a mail to the AAA Mailing List by=20 January 29th, in the following format. I will enter it into the issue tracker. Description of issue: Submitter name: Your_Name_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [CCA] Comment type: ['T'echnical | 'E'ditorial ] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issues:=20 Description_of_Problem_Goes_Here Requested change:=20 Proposal_Goes_Here_With_Specific_Text thanks, John From owner-aaa-wg@merit.edu Fri Jan 23 09:18: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 JAA01512 for ; Fri, 23 Jan 2004 09:18:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0B0B912CB; Fri, 23 Jan 2004 09:18:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADA8A912CC; Fri, 23 Jan 2004 09:18: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 CFAC7912CB for ; Fri, 23 Jan 2004 09:18:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3C465DD8D; Fri, 23 Jan 2004 09:18:10 -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 58A485DE10 for ; Fri, 23 Jan 2004 09:18:09 -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 i0NEI7V13745 for ; Fri, 23 Jan 2004 16:18:07 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Jan 2004 16:17:33 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 16:17:34 +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]: multiple services in a user session, tech. discussion Date: Fri, 23 Jan 2004 16:17:34 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03DE@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPhmL6oU2YJa5cLRLmEX2j8ttsloQADLMfA From: To: Cc: , , , , , , , , , , X-OriginalArrivalTime: 23 Jan 2004 14:17:34.0455 (UTC) FILETIME=[A5474070:01C3E1BB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mark, I have renamed the discussion to make it more easy to track, I hope you = are=20 comfortable with this. I really hope we can together find if there is any problem and fix it. >Question 1: >a) a user establishes a Secondary PDP Context - this causes a new DCC >session to be established Yes. >b) the user sends packets matching 2 separate charging rules at the = client >with different charging keys/rating groups (i.e. that need to be rated >differently) >c) the client establishes a new DCC sub-session within the existing = session >and asks for Service Units for both rating groups (rg1 and rg2) Not necessarily, sub-sessions may be used only in case you want = independent quotas (Chris requirement). Otherwise, the client sends a CCR(UPD) to = request=20 service units for both the rating groups (rg1 and rg2) within the same DCC session. >d) server returns 10mb for rg1 and 10 minutes for rg2. This is within = one >sub-session, so I understand that this means that the user can have = 10mb of >rg1 traffic OR 10 minutes of rg2 traffic OR some combination (e.g. 5MB = + >5minutes - I will omit to mention combinations below for brevity). (btw = - >the fact that this is OR and not AND is far from clear in the draft and = is >rather important!). Assuming the server maintains a single credit reservation and derives = the=20 service units from it considering that each rating group consumes the = whole=20 amount, this would be an OR. In other words, server reserves credit M = and=20 then determines rating R1 for rg1 and rating R2 for rg2. The two service = units are M/R1=3D5MB and M/R2=3D5min. For instance the reservation is $10, R1 is $2/MB and R2 is $2/min. If the client keeps track of the fraction of reserved credit M that is=20 consumed by each of the rating groups and report when the sum of the=20 fractions >=3D 1 (i.e. 100% of the reserved credit is consumed), the = reserved=20 credit is always being used no matter what rg uses it and what portion=20 a rg uses. There is no credit fragmentation at all. >e) the user sends packets matching a 3rd charging rule for a 3rd rating >group (rg3). > >Question: is the client *required* to establish a new sub-session for = this >flow ? If so, I understand the quota returned will be completely=20 >independent >from that provided in (d) above. So, the if the server returns 20mb = then=20 >the >user is now entitled to 10MB of rg1 OR 10 min of rg2) AND (20mb of rg3) = and >we have credit fragmentation. > The client would send a CCR(UPD) reporting the units used by each of the = rating groups and request units for rg1, rg2 and rg3.=20 For example, let assume that 10% of the reservation of (d) was consumed = by rg1 and 30% was consumed by rg2 when the request is sent. The client = reports 0.5MB of used units by rg1 and 1.5min used units by rg2. =20 The server may: 1- debit used units and make new reservation, or 2- work on the existing reservation if there is enough money left Anyway, the result is that there will be some credit M from which = service=20 units are derived as in (d) (M/R1, M/R2 and M/R3). In this example the server determines that rg1 consumed $1.5 (0.5MB*$2) and rg2 consumed $3 (1.5min*$2), for a total of $4.5. The server decides to work on the existing reservation and re-allocate the credit left that is $5.5. The server also determines that R3 is $1/MB. The three service units are then 2.75MB for rg1, 2.75min for rg2 and 5.5MB for rg3. Here is the flow for the above scenario. I didn't use total-octets and=20 seconds for simplicity. Service Element End-User (CC client) CC Server |(1)PDP Act. Req. | | |------------------>|(2)CCR(initial) | =20 | |---------------------------------------->| | | (3)CCA(Success) | | (4)PDP Act. Res. |<----------------------------------------| |<------------------| | : : : |(5)Service-Requests (match RG1 and RG2) | |------------------>|(6)CCR(update, | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) | | |---------------------------------------->| | |(7)CCA(Granted-Units(RG1, 5MB), | | | Granted-Units(RG2, 5min)) | | |<----------------------------------------| : : : |(8)Service-Request (match RG3) | |------------------>| | | |(9)CCR(update, Used-Units(RG1, 0.5MB), | | | Used-Units(RG2, 1.5min), | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2), | | | Requested-Units(Rating-Group 3)) |=20 | |---------------------------------------->| | |(10)CCA(Granted-Units(RG1, 2.75MB), | | | Granted-Units(RG2, 2.75min), | | | Granted-Units(RG3, 5.5MB)) | | |<----------------------------------------| =20 >If not, then the client must send a new request for the existing=20 >subsession. >Does it include all three rating groups and receive one quota covering = all >three (in an OR fashion) ? or does it send a request just for rg3, in = which >case how is the returned quota interpreted ? > >Question 2: >(a) to (c) as Question 1: >(d) the server determines that it cannot allocate a pool across rg1 and = rg2 >because they are to be funded out of different accounts. > >Question: How does the server indicate this to the client ? Is this to = do >with the 'Credit-Pool-ID' AVP I saw mentioned in one of the emails. I=20 >didn't >find this in the draft - is it defined somewhere else ? > The Credit-Pool-ID AVP I think was proposed by Harri in = http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00021.html,=20 it is not defined in the draft at all. In the current draft the=20 Credit-Pool-Id is not used, the server would reserve the same amount=20 from account #1 and account #2, the amount to be reserved would be=20 determined based on the account with smaller amount of credit.=20 We have now two reservations M1 and M2 with the same amount of credit M. = The server derives the service units as if there was only one credit=20 reservation M (it can do it because M1=3D=3DM2), so M/R1 and M/R2 are=20 returned to the client. However, if you feel that credit-pool information is better option I=20 guess Harri could clarify how it is supposed to work. For instance, account #1 hold $10 and account #2 hold $5.5. The server reserves $5 from account #1 and $5 from account #2, it calculates then the service units for rg1 and rg2 as if there was only single = reservation. The server then grants 2.5MB to rg1 and 2.5min to rg2. The client keeps track of the fraction of reserved credit M that is = consumed=20 by each of the rating groups and report when the sum of the fractions = >=3D 1 as=20 in (d). The client reports back the used units by each of the rating = groups, the=20 server then debits on the appropriate account (units used by rg1 to = account #1=20 and units used by rg2 to account #2). Continuing the numeric example, let assume that 10% of the reservation = was=20 consumed by rg1 and 90% was consumed by rg2 when the request is sent.=20 The client reports 0.25MB of used units by rg1 and 2.25min of used units = by=20 rg2. The server determines that rg1 consumed $0.5 (0.25MB*$2) and rg2 consumed $4.5 (2.25min*$2), it then deducts $0.5 from account #1 = and $4.5 from account #2. Now there is $9.5 letf in account #1 and $1 in = account #2. Let assume the credit left on account #2 is below the threshold limit, = the server will then only reserve money from account #1 and will deny = traffic for rg2. Credit reserved is now $5 from account #1 only, thus units granted = to rg1 are 2.5MB. Here is the flow for the above scenario. I didn't use total-octets and=20 seconds for simplicity. Service Element End-User (CC client) CC Server |(1)PDP Act. Req. | | |------------------>|(2)CCR(initial) | =20 | |---------------------------------------->| | | (3)CCA(Success) | | (4)PDP Act. Res. |<----------------------------------------| |<------------------| | : : : |(5)Service-Requests (match RG1 and RG2) | |------------------>|(6)CCR(update, | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) | | |---------------------------------------->| | |(7)CCA(Granted-Units(RG1,2.5MB), | | | Granted-Units(RG2,2.5min)) | | |<----------------------------------------| : : : | (8) whole reservation used | | |(9)CCR(update, Used-Units(RG1, 0.25MB), | | | Used-Units(RG2, 2.25min), | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) |=20 | |---------------------------------------->| | |(10)CCA(Granted-Units(RG1, 2.5MB), | | | Granted-Units(RG2, 0min(i.e. deny))), | |<----------------------------------------| >Question 3: >(a) to (d) as Question 1: >The server wants to indicate that the quota provided for rg1 is only = valid >for 1 hour, after which re-authorisation must be sought. I guess the = server >includes the Validity-Time AVP to indicate this. > >Question: The Validity-Time seems to be associated with the whole=20 >CC-Answer, >not with one of the rating groups - so am I correct in assuming that = all=20 >the >rating groups within this sub-session need to be re-authorised at once = ? Yes, the Validity-Time is per CC session. We thought that what really matter is the burning time of the credit=20 reservation M. If the client keeps track of the fraction of M consumed = by=20 each of the rating groups and report when the sum of the fractions >=3D = 1, the=20 reserved credit is always being used no matter who use it. Then the = reservation is not staying in the client in vain. The server would set the Validity-Time to 1 hour. If it expires is = because=20 no rg1 nor rg2 consumed the allotted credit. In case both rg1 and rg2 = have a=20 validity time, the Validity-Time AVP would be set to the lowest value. When Validity-Time expires the client reports the units used by rg 1 and = rg2=20 and requests units for rg1 and rg2. Since we assume that the server derives service units from a single = credit=20 reservation as explained in (d), even though you would associate the = timer=20 to rg1 you would need to report both rg1 and rg2 in the CCR(UPD). This = is=20 because you cannot leave service units running in the client while the=20 server is doing operations on the credit reservation from which these units are derived. Regards Marco From owner-aaa-wg@merit.edu Fri Jan 23 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 KAA03361 for ; Fri, 23 Jan 2004 10:07:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D7D2912D0; Fri, 23 Jan 2004 10:07:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAF4B912CF; Fri, 23 Jan 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 7C407912D2 for ; Fri, 23 Jan 2004 10:07:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6524F5DDEF; Fri, 23 Jan 2004 10:07:40 -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 71E895DDD3 for ; Fri, 23 Jan 2004 10:07:39 -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 i0NF7cY18354 for ; Fri, 23 Jan 2004 17:07:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Jan 2004 17:07:37 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 17:07:36 +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]: multiple services in a user session, tech. discussion Date: Fri, 23 Jan 2004 17:07:36 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03DF@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas Thread-Index: AcPhmL6oU2YJa5cLRLmEX2j8ttsloQADLMfAAAbMKaA= From: To: Cc: , , , , , , , , , , X-OriginalArrivalTime: 23 Jan 2004 15:07:36.0562 (UTC) FILETIME=[A2AC6D20:01C3E1C2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi again, > In this example the server determines that rg1 consumed $1.5=20 > (0.5MB*$2) > and rg2 consumed $3 (1.5min*$2), for a total of $4.5. The=20 > server decides > to work on the existing reservation and re-allocate the=20 > credit left that > is $5.5. The server also determines that R3 is $1/MB. The=20 > three service > units are then 2.75MB for rg1, 2.75min for rg2 and 5.5MB for rg3. Ouch...I just notice there was a small mistake in the numeric example. Of course it should be: In this example the server determines that rg1 consumed $1 (0.5MB*$2) and rg2 consumed $3 (1.5min*$2), for a total of $4. The server decides to work on the existing reservation and re-allocate the credit left that is $6. The server also determines that R3 is $1/MB. The three service units are then 3MB for rg1, 3min for rg2 and 6MB for rg3. Service Element End-User (CC client) CC Server |(1)PDP Act. Req. | | |------------------>|(2)CCR(initial) | =20 | |---------------------------------------->| | | (3)CCA(Success) | | (4)PDP Act. Res. |<----------------------------------------| |<------------------| | : : : |(5)Service-Requests (match RG1 and RG2) | |------------------>|(6)CCR(update, | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) | | |---------------------------------------->| | |(7)CCA(Granted-Units(RG1, 5MB), | | | Granted-Units(RG2, 5min)) | | |<----------------------------------------| : : : |(8)Service-Request (match RG3) | |------------------>| | | |(9)CCR(update, Used-Units(RG1, 0.5MB), | | | Used-Units(RG2, 1.5min), | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2), | | | Requested-Units(Rating-Group 3)) |=20 | |---------------------------------------->| | |(10)CCA(Granted-Units(RG1, 3MB), | | | Granted-Units(RG2, 3min), | | | Granted-Units(RG3, 6MB)) | | |<----------------------------------------| Regards Marco From owner-aaa-wg@merit.edu Fri Jan 23 11:16: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 LAA09082 for ; Fri, 23 Jan 2004 11:16:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A349A9123A; Fri, 23 Jan 2004 11:16:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64F87912D2; Fri, 23 Jan 2004 11:16:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 660B99123A for ; Fri, 23 Jan 2004 11:16:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D6585DD95; Fri, 23 Jan 2004 11:16:09 -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 CE6285DDB2 for ; Fri, 23 Jan 2004 11:16:07 -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 i0NGEX021621; Fri, 23 Jan 2004 16:14:33 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Jan 2004 16:14:33 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'harri.hakala@ericsson.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'leena.mattila@ericsson.com'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'patrik.teppo@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Fri, 23 Jan 2004 16:14:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E1CB.F9D83454" 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_01C3E1CB.F9D83454 Content-Type: text/plain HI Marco, Thanks for these explanations - I think I understand how the mechanism is supposed to work now, but just to check, assuming a single sub-session within a session: When the client needs authorisation for a new flow, or re-authorisation of an existing one (Validity-time timeout etc.) it must always return a CCR(UPD) containing the units used for all ongoing flows. Then the server will re-authorise all of these, potentially making a new credit reservation. Right ? "This is because you cannot leave service units running in the client while the server is doing operations on the credit reservation from which these units are derived." Secondly, parameters such as Validity-Time are associated with the whole sub-session, so if different flows have different Validity-Times then server uses the lowest one. Thirdly, when flows within a sub-session are funded from separate accounts, the server must make reservations 'of equivalent value' from each accounts. The client will request re-authorisation when a total of one times this value have been used by the user. Finally, the client has a choice of requesting a single reservation shared across multiple flows, or a separate reservation for each flow. It does this by establishing a single subsession in the former case of separate sub-sessions for each flow in the latter case. Let me know if I've got it right! Harri, I'd be interested learning more about the Credit-Pool-ID that you referred to in your earlier mail. Regards...Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 23 January 2004 14:18 To: Watson, Mark [MOP:EP10:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; harri.hakala@ericsson.com Subject: [AAA-WG]: multiple services in a user session, tech. discussion Hi Mark, I have renamed the discussion to make it more easy to track, I hope you are comfortable with this. I really hope we can together find if there is any problem and fix it. >Question 1: >a) a user establishes a Secondary PDP Context - this causes a new DCC >session to be established Yes. >b) the user sends packets matching 2 separate charging rules at the >client with different charging keys/rating groups (i.e. that need to be >rated >differently) >c) the client establishes a new DCC sub-session within the existing session >and asks for Service Units for both rating groups (rg1 and rg2) Not necessarily, sub-sessions may be used only in case you want independent quotas (Chris requirement). Otherwise, the client sends a CCR(UPD) to request service units for both the rating groups (rg1 and rg2) within the same DCC session. >d) server returns 10mb for rg1 and 10 minutes for rg2. This is within >one sub-session, so I understand that this means that the user can have >10mb of rg1 traffic OR 10 minutes of rg2 traffic OR some combination >(e.g. 5MB + 5minutes - I will omit to mention combinations below for >brevity). (btw - the fact that this is OR and not AND is far from clear >in the draft and is rather important!). Assuming the server maintains a single credit reservation and derives the service units from it considering that each rating group consumes the whole amount, this would be an OR. In other words, server reserves credit M and then determines rating R1 for rg1 and rating R2 for rg2. The two service units are M/R1=5MB and M/R2=5min. For instance the reservation is $10, R1 is $2/MB and R2 is $2/min. If the client keeps track of the fraction of reserved credit M that is consumed by each of the rating groups and report when the sum of the fractions >= 1 (i.e. 100% of the reserved credit is consumed), the reserved credit is always being used no matter what rg uses it and what portion a rg uses. There is no credit fragmentation at all. >e) the user sends packets matching a 3rd charging rule for a 3rd rating >group (rg3). > >Question: is the client *required* to establish a new sub-session for >this flow ? If so, I understand the quota returned will be completely >independent from that provided in (d) above. So, the if the server >returns 20mb then the >user is now entitled to 10MB of rg1 OR 10 min of rg2) AND (20mb of rg3) and >we have credit fragmentation. > The client would send a CCR(UPD) reporting the units used by each of the rating groups and request units for rg1, rg2 and rg3. For example, let assume that 10% of the reservation of (d) was consumed by rg1 and 30% was consumed by rg2 when the request is sent. The client reports 0.5MB of used units by rg1 and 1.5min used units by rg2. The server may: 1- debit used units and make new reservation, or 2- work on the existing reservation if there is enough money left Anyway, the result is that there will be some credit M from which service units are derived as in (d) (M/R1, M/R2 and M/R3). In this example the server determines that rg1 consumed $1.5 (0.5MB*$2) and rg2 consumed $3 (1.5min*$2), for a total of $4.5. The server decides to work on the existing reservation and re-allocate the credit left that is $5.5. The server also determines that R3 is $1/MB. The three service units are then 2.75MB for rg1, 2.75min for rg2 and 5.5MB for rg3. Here is the flow for the above scenario. I didn't use total-octets and seconds for simplicity. Service Element End-User (CC client) CC Server |(1)PDP Act. Req. | | |------------------>|(2)CCR(initial) | | |---------------------------------------->| | | (3)CCA(Success) | | (4)PDP Act. Res. |<----------------------------------------| |<------------------| | : : : |(5)Service-Requests (match RG1 and RG2) | |------------------>|(6)CCR(update, | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) | | |---------------------------------------->| | |(7)CCA(Granted-Units(RG1, 5MB), | | | Granted-Units(RG2, 5min)) | | |<----------------------------------------| : : : |(8)Service-Request (match RG3) | |------------------>| | | |(9)CCR(update, Used-Units(RG1, 0.5MB), | | | Used-Units(RG2, 1.5min), | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2), | | | Requested-Units(Rating-Group 3)) | | |---------------------------------------->| | |(10)CCA(Granted-Units(RG1, 2.75MB), | | | Granted-Units(RG2, 2.75min), | | | Granted-Units(RG3, 5.5MB)) | | |<----------------------------------------| >If not, then the client must send a new request for the existing >subsession. >Does it include all three rating groups and receive one quota covering all >three (in an OR fashion) ? or does it send a request just for rg3, in which >case how is the returned quota interpreted ? > >Question 2: >(a) to (c) as Question 1: >(d) the server determines that it cannot allocate a pool across rg1 and >rg2 because they are to be funded out of different accounts. > >Question: How does the server indicate this to the client ? Is this to >do with the 'Credit-Pool-ID' AVP I saw mentioned in one of the emails. >I didn't find this in the draft - is it defined somewhere else ? > The Credit-Pool-ID AVP I think was proposed by Harri in http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00021.html, it is not defined in the draft at all. In the current draft the Credit-Pool-Id is not used, the server would reserve the same amount from account #1 and account #2, the amount to be reserved would be determined based on the account with smaller amount of credit. We have now two reservations M1 and M2 with the same amount of credit M. The server derives the service units as if there was only one credit reservation M (it can do it because M1==M2), so M/R1 and M/R2 are returned to the client. However, if you feel that credit-pool information is better option I guess Harri could clarify how it is supposed to work. For instance, account #1 hold $10 and account #2 hold $5.5. The server reserves $5 from account #1 and $5 from account #2, it calculates then the service units for rg1 and rg2 as if there was only single reservation. The server then grants 2.5MB to rg1 and 2.5min to rg2. The client keeps track of the fraction of reserved credit M that is consumed by each of the rating groups and report when the sum of the fractions >= 1 as in (d). The client reports back the used units by each of the rating groups, the server then debits on the appropriate account (units used by rg1 to account #1 and units used by rg2 to account #2). Continuing the numeric example, let assume that 10% of the reservation was consumed by rg1 and 90% was consumed by rg2 when the request is sent. The client reports 0.25MB of used units by rg1 and 2.25min of used units by rg2. The server determines that rg1 consumed $0.5 (0.25MB*$2) and rg2 consumed $4.5 (2.25min*$2), it then deducts $0.5 from account #1 and $4.5 from account #2. Now there is $9.5 letf in account #1 and $1 in account #2. Let assume the credit left on account #2 is below the threshold limit, the server will then only reserve money from account #1 and will deny traffic for rg2. Credit reserved is now $5 from account #1 only, thus units granted to rg1 are 2.5MB. Here is the flow for the above scenario. I didn't use total-octets and seconds for simplicity. Service Element End-User (CC client) CC Server |(1)PDP Act. Req. | | |------------------>|(2)CCR(initial) | | |---------------------------------------->| | | (3)CCA(Success) | | (4)PDP Act. Res. |<----------------------------------------| |<------------------| | : : : |(5)Service-Requests (match RG1 and RG2) | |------------------>|(6)CCR(update, | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) | | |---------------------------------------->| | |(7)CCA(Granted-Units(RG1,2.5MB), | | | Granted-Units(RG2,2.5min)) | | |<----------------------------------------| : : : | (8) whole reservation used | | |(9)CCR(update, Used-Units(RG1, 0.25MB), | | | Used-Units(RG2, 2.25min), | | | Requested-Units(Rating-Group 1), | | | Requested-Units(Rating-Group 2)) | | |---------------------------------------->| | |(10)CCA(Granted-Units(RG1, 2.5MB), | | | Granted-Units(RG2, 0min(i.e. deny))), | |<----------------------------------------| >Question 3: >(a) to (d) as Question 1: >The server wants to indicate that the quota provided for rg1 is only >valid for 1 hour, after which re-authorisation must be sought. I guess >the server includes the Validity-Time AVP to indicate this. > >Question: The Validity-Time seems to be associated with the whole >CC-Answer, >not with one of the rating groups - so am I correct in assuming that all >the >rating groups within this sub-session need to be re-authorised at once ? Yes, the Validity-Time is per CC session. We thought that what really matter is the burning time of the credit reservation M. If the client keeps track of the fraction of M consumed by each of the rating groups and report when the sum of the fractions >= 1, the reserved credit is always being used no matter who use it. Then the reservation is not staying in the client in vain. The server would set the Validity-Time to 1 hour. If it expires is because no rg1 nor rg2 consumed the allotted credit. In case both rg1 and rg2 have a validity time, the Validity-Time AVP would be set to the lowest value. When Validity-Time expires the client reports the units used by rg 1 and rg2 and requests units for rg1 and rg2. Since we assume that the server derives service units from a single credit reservation as explained in (d), even though you would associate the timer to rg1 you would need to report both rg1 and rg2 in the CCR(UPD). This is because you cannot leave service units running in the client while the server is doing operations on the credit reservation from which these units are derived. Regards Marco ------_=_NextPart_001_01C3E1CB.F9D83454 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussion

HI Marco,

Thanks for these explanations - I think I understand = how the mechanism is supposed to work now, but just to check, assuming = a single sub-session within a session:

When the client needs authorisation for a new flow, = or re-authorisation of an existing one (Validity-time timeout etc.) it = must always return a CCR(UPD) containing the units used for all ongoing = flows. Then the server will re-authorise all of these, potentially = making a new credit reservation. Right ?

"This is because you cannot leave service units = running in the client while the
server is doing operations on the credit reservation = from which these units are derived."

Secondly, parameters such as Validity-Time are = associated with the whole sub-session, so if different flows have = different Validity-Times then server uses the lowest one.

Thirdly, when flows within a sub-session are funded = from separate accounts, the server must make reservations 'of = equivalent value' from each accounts. The client will request = re-authorisation when a total of one times this value have been used by = the user.

Finally, the client has a choice of requesting a = single reservation shared across multiple flows, or a separate = reservation for each flow. It does this by establishing a single = subsession  in the former case of separate sub-sessions for each = flow in the latter case.

Let me know if I've got it right!

Harri,

I'd be interested learning more about the = Credit-Pool-ID that you referred to in your earlier mail.

Regards...Mark

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 23 January 2004 14:18
To: Watson, Mark [MOP:EP10:EXCH]
Cc: john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; = aaa-wg@merit.edu; Karl-Heinz.Nenner@t-mobile.de; = Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; = juha-pekka.koskinen@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; = Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; = harri.hakala@ericsson.com

Subject: [AAA-WG]: multiple services in a user = session, tech. discussion


Hi Mark,

I have renamed the discussion to make it more easy to = track, I hope you are
comfortable with this.
I really hope we can together find if there is any = problem and fix it.

>Question 1:
>a) a user establishes a Secondary PDP Context - = this causes a new DCC
>session to be established

Yes.

>b) the user sends packets matching 2 separate = charging rules at the
>client with different charging keys/rating = groups (i.e. that need to be
>rated
>differently)
>c) the client establishes a new DCC sub-session = within the existing session
>and asks for Service Units for both rating = groups (rg1 and rg2)

Not necessarily, sub-sessions may be used only in = case you want independent quotas (Chris requirement). Otherwise, the = client sends a CCR(UPD) to request

service units for both the rating groups (rg1 and = rg2) within the same DCC session.

>d) server returns 10mb for rg1 and 10 minutes for = rg2. This is within
>one sub-session, so I understand that this means = that the user can have
>10mb of rg1 traffic OR 10 minutes of rg2 traffic = OR some combination
>(e.g. 5MB + 5minutes - I will omit to mention = combinations below for
>brevity). (btw - the fact that this is OR and = not AND is far from clear
>in the draft and is rather important!).

Assuming the server maintains a single credit = reservation and derives the
service units from it considering that each rating = group consumes the whole
amount, this would be an OR. In other words, server = reserves credit M and
then determines rating R1 for rg1 and rating R2 for = rg2. The two service
units are M/R1=3D5MB and M/R2=3D5min.
For instance the reservation is $10, R1 is $2/MB and = R2 is $2/min.

If the client keeps track of the fraction of reserved = credit M that is
consumed by each of the rating groups and report = when the sum of the
fractions >=3D 1 (i.e. 100% of the reserved = credit is consumed), the reserved
credit is always being used no matter what rg uses = it and what portion
a rg uses. There is no credit fragmentation at = all.

>e) the user sends packets matching a 3rd charging = rule for a 3rd rating
>group (rg3).
>
>Question: is the client *required* to establish = a new sub-session for
>this flow ? If so, I understand the quota = returned will be completely
>independent from that provided in (d) above. So, = the if the server
>returns 20mb then the
>user is now entitled to 10MB of rg1 OR 10 min of = rg2) AND (20mb of rg3) and
>we have credit fragmentation.
>

The client would send a CCR(UPD) reporting the units = used by each of the
rating groups and request units for rg1, rg2 and = rg3.
For example, let assume that 10% of the reservation = of (d) was consumed by rg1 and 30% was consumed by rg2 when the request = is sent. The client reports 0.5MB of used units by rg1 and 1.5min used = units by rg2.

 
The server may:

1- debit used units and make new reservation, = or

2- work on the existing reservation if there is = enough money left

Anyway, the result is that there will be some credit = M from which service
units are derived as in (d) (M/R1, M/R2 and = M/R3).

In this example the server determines that rg1 = consumed $1.5 (0.5MB*$2) and rg2 consumed $3 (1.5min*$2), for a total = of $4.5. The server decides to work on the existing reservation and = re-allocate the credit left that is $5.5. The server also determines = that R3 is $1/MB. The three service units are then 2.75MB for rg1, = 2.75min for rg2 and 5.5MB for rg3.

Here is the flow for the above scenario. I didn't use = total-octets and
seconds for simplicity.


          &nb= sp;     Service Element
 End-User        &= nbsp;  (CC = client)           = ;            = ;       CC Server
 |(1)PDP Act. Req.   = |            = ;            = ;            = ;     |
 |------------------>|(2)CCR(initial)   =             =            |  =
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |            = ;          = (3)CCA(Success)    |
 |  (4)PDP Act. Res. = |<----------------------------------------|
 |<------------------|     &nb= sp;           &nb= sp;           &nb= sp;           = |
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(5)Service-Requests (match RG1 and = RG2)           &n= bsp;          |
 |------------------>|(6)CCR(update,   &= nbsp;           &= nbsp;           = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1),  |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 2))  |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(7)CCA(Granted-Units(RG1, = 5MB),          |
 |         &n= bsp;         = |       Granted-Units(RG2, = 5min))         |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(8)Service-Request (match = RG3)           &n= bsp;           &n= bsp;       |
 |------------------>|     &nb= sp;           &nb= sp;           &nb= sp;           = |
 |         &n= bsp;         |(9)CCR(update, = Used-Units(RG1, 0.5MB),   |
 |         &n= bsp;         = |          Used-Units(RG2, = 1.5min),       |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1),  |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 2),  |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 3))  |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(10)CCA(Granted-Units(RG1, 2.75MB),      = |
 |         &n= bsp;         = |       Granted-Units(RG2, = 2.75min),      |
 |         &n= bsp;         = |       Granted-Units(RG3, = 5.5MB))        |
 |         &n= bsp;         = |<----------------------------------------|
 

>If not, then the client must send a new request = for the existing
>subsession.
>Does it include all three rating groups and = receive one quota covering all
>three (in an OR fashion) ? or does it send a = request just for rg3, in which
>case how is the returned quota interpreted = ?
>
>Question 2:
>(a) to (c) as Question 1:
>(d) the server determines that it cannot = allocate a pool across rg1 and
>rg2 because they are to be funded out of = different accounts.
>
>Question: How does the server indicate this to = the client ? Is this to
>do with the 'Credit-Pool-ID' AVP I saw mentioned = in one of the emails.
>I didn't find this in the draft - is it defined = somewhere else ?
>

The Credit-Pool-ID AVP I think was proposed by Harri = in http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg0= 0021.html,

it is not defined in the draft at all. In the current = draft the
Credit-Pool-Id is not used, the server would reserve = the same amount
from account #1 and account #2, the amount to be = reserved would be
determined based on the account with smaller amount = of credit.
We have now two reservations M1 and M2 with the same = amount of credit M.
The server derives the service units as if there was = only one credit
reservation M (it can do it because M1=3D=3DM2), so = M/R1 and M/R2 are
returned to the client.
However, if you feel that credit-pool information is = better option I
guess Harri could clarify how it is supposed to = work.

For instance, account #1 hold $10 and account #2 hold = $5.5. The server reserves $5 from account #1 and $5 from account #2, it = calculates then the service units for rg1 and rg2 as if there was only = single reservation. The server then grants 2.5MB to rg1 and 2.5min to = rg2.

The client keeps track of the fraction of reserved = credit M that is consumed
by each of the rating groups and report when the sum = of the fractions >=3D 1 as
in (d). The client reports back the used units by = each of the rating groups, the
server then debits on the appropriate account (units = used by rg1 to account #1
and units used by rg2 to account #2).

Continuing the numeric example, let assume that 10% = of the reservation was
consumed by rg1 and 90% was consumed by rg2 when the = request is sent.
The client reports 0.25MB of used units by rg1 and = 2.25min of used units by
rg2. The server determines that rg1 consumed $0.5 = (0.25MB*$2) and rg2 consumed $4.5 (2.25min*$2), it then deducts $0.5 = from account #1 and $4.5 from account #2. Now there is $9.5 letf in = account #1 and $1 in account #2. Let assume the credit left on account = #2 is below the threshold limit, the server will then only reserve = money from account #1 and will deny traffic for rg2. Credit reserved is = now $5 from account #1 only, thus units granted to rg1 are = 2.5MB.

Here is the flow for the above scenario. I didn't use = total-octets and
seconds for simplicity.


          &nb= sp;     Service Element
 End-User        &= nbsp;  (CC = client)           = ;            = ;       CC Server
 |(1)PDP Act. Req.   = |            = ;            = ;            = ;     |
 |------------------>|(2)CCR(initial)   =             =            |  =
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |            = ;          = (3)CCA(Success)    |
 |  (4)PDP Act. Res. = |<----------------------------------------|
 |<------------------|     &nb= sp;           &nb= sp;           &nb= sp;           = |
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(5)Service-Requests (match RG1 and = RG2)           &n= bsp;          |
 |------------------>|(6)CCR(update,   &= nbsp;           &= nbsp;           = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1),  |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 2))  |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(7)CCA(Granted-Units(RG1,2.5MB),      &nb= sp;  |
 |         &n= bsp;         = |       = Granted-Units(RG2,2.5min))        = |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |       (8) = whole reservation = used           &n= bsp;           &n= bsp;    |
 |         &n= bsp;         |(9)CCR(update, = Used-Units(RG1, 0.25MB),  |
 |         &n= bsp;         = |          Used-Units(RG2, = 2.25min),      |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1),  |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 2))  |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(10)CCA(Granted-Units(RG1, 2.5MB),       = |
 |         &n= bsp;         = |       Granted-Units(RG2, 0min(i.e. = deny))),
 |         &n= bsp;         = |<----------------------------------------|

>Question 3:
>(a) to (d) as Question 1:
>The server wants to indicate that the quota = provided for rg1 is only
>valid for 1 hour, after which re-authorisation = must be sought. I guess
>the server includes the Validity-Time AVP to = indicate this.
>
>Question: The Validity-Time seems to be = associated with the whole
>CC-Answer,
>not with one of the rating groups - so am I = correct in assuming that all
>the
>rating groups within this sub-session need to be = re-authorised at once ?

Yes, the Validity-Time is per CC session.
We thought that what really matter is the burning = time of the credit
reservation M. If the client keeps track of the = fraction of M consumed by
each of the rating groups and report when the sum of = the fractions >=3D 1, the
reserved credit is always being used no matter who = use it. Then the reservation is not staying in the client in vain. The = server would set the Validity-Time to 1 hour. If it expires is because =

no rg1 nor rg2 consumed the allotted credit. In case = both rg1 and rg2 have a
validity time, the Validity-Time AVP would be set to = the lowest value.

When Validity-Time expires the client reports the = units used by rg 1 and rg2
and requests units for rg1 and rg2.

Since we assume that the server derives service units = from a single credit
reservation as explained in (d), even though you = would associate the timer
to rg1 you would need to report both rg1 and rg2 in = the CCR(UPD). This is
because you cannot leave service units running in = the client while the
server is doing operations on the credit reservation = from which these units are derived.

Regards
Marco

------_=_NextPart_001_01C3E1CB.F9D83454-- From aaa-admin@ietf.org Fri Jan 23 19:54:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05510 for ; Fri, 23 Jan 2004 19:54:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkC3l-0003eX-8B; Fri, 23 Jan 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkC3i-0003e8-Vy for aaa@optimus.ietf.org; Fri, 23 Jan 2004 19:53:59 -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 TAA05495 for ; Fri, 23 Jan 2004 19:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkC3h-0000Vu-00 for aaa@ietf.org; Fri, 23 Jan 2004 19:53:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkC2p-0000Ut-00 for aaa@ietf.org; Fri, 23 Jan 2004 19:53:04 -0500 Received: from ool-44c62626.dyn.optonline.net ([68.198.38.38] helo=68.198.38.38) by ietf-mx with smtp (Exim 4.12) id 1AkC2D-0000Tc-00 for aaa@ietf.org; Fri, 23 Jan 2004 19:52:25 -0500 From: orders@avahost.net To: aaa@ietf.org Date: Fri, 23 Jan 2004 16:55:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=5.5 required=5.0 tests=FORGED_MUA_OUTLOOK, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO 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 * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [Aaa] Welcome to www.dumpsmarket.com 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: 7bit Welcome to www.dumpsmarket.com the site of stolen credit cards,child porno, fake money, passports and complete info about any US citizen! You can get fresh stolen dumps here: http://www.dumpsmarket.com/forum/viewtopic.php?t=77 Only using our site you can get every detail of any US citizen including SSN number: http://www.dumpsmarket.com/forum/viewtopic.php?t=192 Credit cards with cvv2 information are available here: http://www.dumpsmarket.com/forum/viewtopic.php?t=57 Our site will be usefull for the those who want to wash their money also. If you don't want to pay taxes or you need to buy something illegal like weapons or drugs. Quick contacts: Panther 44007777 Graph 146191522 You can order by phone: 5092757151. Best regards, Vladimir V Panfilovich. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Jan 23 19:55:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05571 for ; Fri, 23 Jan 2004 19:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkC4o-0003jh-BT for aaa-archive@odin.ietf.org; Fri, 23 Jan 2004 19:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O0t6kh014357 for aaa-archive@odin.ietf.org; Fri, 23 Jan 2004 19:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkC4o-0003jU-7P for aaa-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 19:55:06 -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 TAA05564 for ; Fri, 23 Jan 2004 19:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkC4m-0000ZO-00 for aaa-web-archive@ietf.org; Fri, 23 Jan 2004 19:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkC3u-0000XQ-00 for aaa-web-archive@ietf.org; Fri, 23 Jan 2004 19:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkC3l-0003eX-8B; Fri, 23 Jan 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkC3i-0003e8-Vy for aaa@optimus.ietf.org; Fri, 23 Jan 2004 19:53:59 -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 TAA05495 for ; Fri, 23 Jan 2004 19:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkC3h-0000Vu-00 for aaa@ietf.org; Fri, 23 Jan 2004 19:53:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkC2p-0000Ut-00 for aaa@ietf.org; Fri, 23 Jan 2004 19:53:04 -0500 Received: from ool-44c62626.dyn.optonline.net ([68.198.38.38] helo=68.198.38.38) by ietf-mx with smtp (Exim 4.12) id 1AkC2D-0000Tc-00 for aaa@ietf.org; Fri, 23 Jan 2004 19:52:25 -0500 From: orders@avahost.net To: aaa@ietf.org Date: Fri, 23 Jan 2004 16:55:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=5.5 required=5.0 tests=FORGED_MUA_OUTLOOK, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO 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 * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [Aaa] Welcome to www.dumpsmarket.com 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: 7bit Content-Transfer-Encoding: 7bit Welcome to www.dumpsmarket.com the site of stolen credit cards,child porno, fake money, passports and complete info about any US citizen! You can get fresh stolen dumps here: http://www.dumpsmarket.com/forum/viewtopic.php?t=77 Only using our site you can get every detail of any US citizen including SSN number: http://www.dumpsmarket.com/forum/viewtopic.php?t=192 Credit cards with cvv2 information are available here: http://www.dumpsmarket.com/forum/viewtopic.php?t=57 Our site will be usefull for the those who want to wash their money also. If you don't want to pay taxes or you need to buy something illegal like weapons or drugs. Quick contacts: Panther 44007777 Graph 146191522 You can order by phone: 5092757151. Best regards, Vladimir V Panfilovich. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Mon Jan 26 00:09:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05200 for ; Mon, 26 Jan 2004 00:09: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 1Akyzd-0006Ve-Ap; Mon, 26 Jan 2004 00:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkyzK-0006VB-Tx for aaa@optimus.ietf.org; Mon, 26 Jan 2004 00:08: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 AAA05160 for ; Mon, 26 Jan 2004 00:08:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkyzI-0003hG-00 for aaa@ietf.org; Mon, 26 Jan 2004 00:08:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkyyO-0003fA-00 for aaa@ietf.org; Mon, 26 Jan 2004 00:07:44 -0500 Received: from c-24-13-178-56.client.comcast.net ([24.13.178.56]) by ietf-mx with smtp (Exim 4.12) id 1Akyxt-0003cw-00 for aaa@ietf.org; Mon, 26 Jan 2004 00:07:13 -0500 Received: from 230.20.156.97 by web969.mail.yahoo.com; Mon, 26 Jan 2004 09:59:13 +0500 Message-ID: From: "Salvador Stern" To: aaa@ietf.org Date: Sun, 25 Jan 2004 23:02:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--96818361727375889694" X-CS-IP: 4.196.158.130 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=7.8 required=5.0 tests=FORGED_YAHOO_RCVD,HTML_60_70, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 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.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] turkish allentown 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: , ----96818361727375889694 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable








accretion epidemic caraway emporium performanc= e toroidal

----96818361727375889694-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Jan 26 00:10:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05256 for ; Mon, 26 Jan 2004 00:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akz0P-0006cA-Tj for aaa-archive@odin.ietf.org; Mon, 26 Jan 2004 00:09:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q59noN025420 for aaa-archive@odin.ietf.org; Mon, 26 Jan 2004 00:09:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akz0P-0006bv-P4 for aaa-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 00:09: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 AAA05248 for ; Mon, 26 Jan 2004 00:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Akz0N-0003lx-00 for aaa-web-archive@ietf.org; Mon, 26 Jan 2004 00:09:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Akyzk-0003j7-00 for aaa-web-archive@ietf.org; Mon, 26 Jan 2004 00:09:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akyzd-0006Ve-Ap; Mon, 26 Jan 2004 00:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkyzK-0006VB-Tx for aaa@optimus.ietf.org; Mon, 26 Jan 2004 00:08: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 AAA05160 for ; Mon, 26 Jan 2004 00:08:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkyzI-0003hG-00 for aaa@ietf.org; Mon, 26 Jan 2004 00:08:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkyyO-0003fA-00 for aaa@ietf.org; Mon, 26 Jan 2004 00:07:44 -0500 Received: from c-24-13-178-56.client.comcast.net ([24.13.178.56]) by ietf-mx with smtp (Exim 4.12) id 1Akyxt-0003cw-00 for aaa@ietf.org; Mon, 26 Jan 2004 00:07:13 -0500 Received: from 230.20.156.97 by web969.mail.yahoo.com; Mon, 26 Jan 2004 09:59:13 +0500 Message-ID: From: "Salvador Stern" To: aaa@ietf.org Date: Sun, 25 Jan 2004 23:02:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--96818361727375889694" X-CS-IP: 4.196.158.130 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=7.8 required=5.0 tests=FORGED_YAHOO_RCVD,HTML_60_70, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 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.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Subject: [Aaa] turkish allentown 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: , ----96818361727375889694 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable








accretion epidemic caraway emporium performanc= e toroidal

----96818361727375889694-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Jan 26 01:02:34 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 BAA07392 for ; Mon, 26 Jan 2004 01:02:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4535091248; Mon, 26 Jan 2004 01:02:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E991091249; Mon, 26 Jan 2004 01:02: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 A9A3B91248 for ; Mon, 26 Jan 2004 01:02:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 811145DDF3; Mon, 26 Jan 2004 01:02:14 -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 CC0125DDA4 for ; Mon, 26 Jan 2004 01:02:13 -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 i0Q627V15400 for ; Mon, 26 Jan 2004 08:02:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 26 Jan 2004 08:02:06 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 08:02:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Issue: DCC typing issues Date: Mon, 26 Jan 2004 08:02:05 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C392F@esebe023.ntc.nokia.com> Thread-Topic: Issue: DCC typing issues Thread-Index: AcPj0e1CL7kUahBSQKGMLYZQ3QHu/g== From: To: X-OriginalArrivalTime: 26 Jan 2004 06:02:06.0090 (UTC) FILETIME=[ED07FEA0:01C3E3D1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable DCC typing issues Submitter name: Pasi Eronen Date first submitted: 26.1.2004 Reference:=20 Document: cc-02 Comment type: T/E Priority: 1 Section: various Rationale/Explanation of issues:=20 I have to admit that I haven't fully read and understood the document (it's long and quite complicated...), but here are=20 anyway some nits: - 4.1: RFC3588 says that unrecognized AVPs with 'M' bit cause=20 DIAMETER_AVP_UNSUPPORTED error, not DIAMETER_RATING_FAILED. If the intent is to override RFC3588, please say so explicitly. - 8.8: Cost-Unit is specified as UTF8String without any guidance to its contents. Will this lead to interoperability (or other)=20 problems if e.g. one implementation uses "kilobyte" and=20 another "kB"? (hmm, is this 1000 or 1024 bytes... :-) - 8.17: Should specify whether IPv4/IPv6 addresses are just octets or textual representation (and for IPv6, which=20 textual representation). - 8.24: Service-Parameter-Type should probably specify how these values are allocated, or who is responsible for selecting them=20 (and ensuring that they are unique within some context). - 8.25: Service-Parameter-Value should be OctetString rather than UTF8String if it's going to be used for BER-encoded ASN.1. - 8.36: "The CC-Service-Specific-Units AVP (AVP Code 417) is of type=20 OctetString, and specifies the number of service specific units=20 (e.g. number of events, points) given in a selected service." IMHO "a number" would hint that OctetString is not probably the best choice here (and is e.g. 1 packet encoded as "0x01", "0x31" or perhaps "0x00 0x00 0x00 0x01"?). However, I'm not sure if this needs to be an integer or floating point (can we assume that service-specific units are scaled so that floats are not necessary?) (8.16 also says that "...the value of the CC-Service-Specific-Units AVP is set to FFFFFFFF to indicate free-of-charge.", which is=20 a bit strange if it's an OctetString.) - A.7 "..with Unit-Type set to CREDIT_TYPE_SERVICE_SPECIFIC and Unit-Value set to the number of points..."; the spec doesn't=20 define a Unit-Type AVP (anymore?) Best regards, Pasi From owner-aaa-wg@merit.edu Mon Jan 26 01:03: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 BAA07412 for ; Mon, 26 Jan 2004 01:03:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADB8D91249; Mon, 26 Jan 2004 01:03:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7968B9124A; Mon, 26 Jan 2004 01:03: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 3275F91249 for ; Mon, 26 Jan 2004 01:03:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 229A25DDDF; Mon, 26 Jan 2004 01:03:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 61B605DE21 for ; Mon, 26 Jan 2004 01:02:59 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0Q62wY21110 for ; Mon, 26 Jan 2004 08:02:58 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 26 Jan 2004 08:02:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 08:02:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 08:02:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Issue: DCC editorial issues Date: Mon, 26 Jan 2004 08:02:56 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3930@esebe023.ntc.nokia.com> Thread-Topic: Issue: DCC editorial issues Thread-Index: AcPj0gufLjalOpBTQOOg37bTlyfODA== From: To: X-OriginalArrivalTime: 26 Jan 2004 06:02:57.0261 (UTC) FILETIME=[0B8811D0:01C3E3D2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable DCC editorial issues Submitter name: Pasi Eronen Date first submitted: 26.1.2004 Reference:=20 Document: cc-02 Comment type: E Priority: 1 Section: various Rationale/Explanation of issues:=20 5.6: s/buffering of messages MAY NOT/...may not/ (this is not a=20 requirement and "MAY NOT" is not a RFC 2119 keyword) 8: AVP flag rule table has some "-":s in it; should instead=20 list the "M" bit in appropriate (MAY/SHOULD NOT/MUST NOT) column. 8: suggest changing section order so that AVPs that are only used=20 inside a Grouped AVP are always listed after the container. E.g. move Redirect-Address-Type after Redirect-Server,=20 Value-Digits/Exponent after Unit-Value, and so on. 8.11: should have a normative reference to ISO 4217 9: s/which MAY indicate that an error/...may.../=20 15.2: KEYWORDS is normative 15.2: This specification uses an AVP defined in NASREQ (Filter-Id), so this might make NASREQ reference normative? 15: References that are cited in the text, but not listed here: AAATRANS, RFC791, RFC2373, RFC1738 (and 2373 is obsoleted by 3513) 15: References listed in Section 15 but not cited anywhere: ACCMGMT Typos/grammar: 1.2 s/Sip proxy/SIP proxy/ 2 s/accounts can locate/accounts can be located/ 4 s/reserve a suitable amount/reserves a suitable amount/ 4 s/return the corresponding/returns the corresponding/ 4 s/start monitoring/starts monitoring/ 4 s/also support for/also supports/ 4 s/own credit risk/its own credit risk/ 4.1 s/this generic mechanisms/this generic mechanism/ 5.1 s/service element send/service element sends/ 5.1.2 s:authenticate/authorize:authenticates/authorizes: 5.1.2 s/determine whether/determines whether/ 6.3 s/Request-Service-Unit/Requested-Service-Unit/ 8.8 s/pe rminute/per minute/ 10.1 Redirect-Host/Host-Usage/Max-Cache-Time change "-" to "0" 10.1 non-ASCII character=20 11.2 non-ASCII character=20 A.3 s/Sip proxy/SIP proxy/ A.6 s/accetp/accept/ A.7 s/Conrol-Request/Control-Request/ Best regards, Pasi From owner-aaa-wg@merit.edu Mon Jan 26 02: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 CAA23564 for ; Mon, 26 Jan 2004 02:49:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 948D09124F; Mon, 26 Jan 2004 02:49:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E733D91250; Mon, 26 Jan 2004 02:49: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 A67799124F for ; Mon, 26 Jan 2004 02:49:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92E935DE4A; Mon, 26 Jan 2004 02:49:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id BFECF5DE21 for ; Mon, 26 Jan 2004 02:49:18 -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 i0Q7nHY27764 for ; Mon, 26 Jan 2004 09:49:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 26 Jan 2004 09:49:17 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 09:49:15 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 09:49:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: DCC editorial issues Date: Mon, 26 Jan 2004 09:49:15 +0200 Message-ID: Thread-Topic: Issue: DCC editorial issues Thread-Index: AcPj0gufLjalOpBTQOOg37bTlyfODAADtUUw From: To: , X-OriginalArrivalTime: 26 Jan 2004 07:49:16.0533 (UTC) FILETIME=[E5DFBA50:01C3E3E0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned issue 13. thanks, John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 26 January, 2004 08:03 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue: DCC editorial issues >=20 >=20 > DCC editorial issues > Submitter name: Pasi Eronen > Date first submitted: 26.1.2004 > Reference:=20 > Document: cc-02 > Comment type: E > Priority: 1 > Section: various > Rationale/Explanation of issues:=20 >=20 > 5.6: s/buffering of messages MAY NOT/...may not/ (this is not a=20 > requirement and "MAY NOT" is not a RFC 2119 keyword) > 8: AVP flag rule table has some "-":s in it; should instead=20 > list the "M" bit in appropriate (MAY/SHOULD NOT/MUST NOT) column. > 8: suggest changing section order so that AVPs that are only used=20 > inside a Grouped AVP are always listed after the container. > E.g. move Redirect-Address-Type after Redirect-Server,=20 > Value-Digits/Exponent after Unit-Value, and so on. > 8.11: should have a normative reference to ISO 4217 > 9: s/which MAY indicate that an error/...may.../=20 > 15.2: KEYWORDS is normative > 15.2: This specification uses an AVP defined in NASREQ (Filter-Id), > so this might make NASREQ reference normative? > 15: References that are cited in the text, but not listed here: > AAATRANS, RFC791, RFC2373, RFC1738 (and 2373 is obsoleted by 3513) > 15: References listed in Section 15 but not cited anywhere: ACCMGMT >=20 > Typos/grammar: >=20 > 1.2 s/Sip proxy/SIP proxy/ > 2 s/accounts can locate/accounts can be located/ > 4 s/reserve a suitable amount/reserves a suitable amount/ > 4 s/return the corresponding/returns the corresponding/ > 4 s/start monitoring/starts monitoring/ > 4 s/also support for/also supports/ > 4 s/own credit risk/its own credit risk/ > 4.1 s/this generic mechanisms/this generic mechanism/ > 5.1 s/service element send/service element sends/ > 5.1.2 s:authenticate/authorize:authenticates/authorizes: > 5.1.2 s/determine whether/determines whether/ > 6.3 s/Request-Service-Unit/Requested-Service-Unit/ > 8.8 s/pe rminute/per minute/ > 10.1 Redirect-Host/Host-Usage/Max-Cache-Time change "-" to "0" > 10.1 non-ASCII character=20 > 11.2 non-ASCII character=20 > A.3 s/Sip proxy/SIP proxy/ > A.6 s/accetp/accept/ > A.7 s/Conrol-Request/Control-Request/ >=20 > Best regards, > Pasi >=20 From owner-aaa-wg@merit.edu Mon Jan 26 02:51: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 CAA23683 for ; Mon, 26 Jan 2004 02:50:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A764191250; Mon, 26 Jan 2004 02:50:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 750C691252; Mon, 26 Jan 2004 02:50: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 343F991250 for ; Mon, 26 Jan 2004 02:50:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1FD215DE39; Mon, 26 Jan 2004 02:50:47 -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 3D1625DE57 for ; Mon, 26 Jan 2004 02:50:46 -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 i0Q7oiV18371 for ; Mon, 26 Jan 2004 09:50:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 26 Jan 2004 09:50:43 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 09:50:42 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 09:50:42 +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]: Issue: DCC typing issues Date: Mon, 26 Jan 2004 09:50:41 +0200 Message-ID: Thread-Topic: Issue: DCC typing issues Thread-Index: AcPj0e1CL7kUahBSQKGMLYZQ3QHu/gADyUlg From: To: , X-OriginalArrivalTime: 26 Jan 2004 07:50:42.0786 (UTC) FILETIME=[1948E420:01C3E3E1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned issue 14. thanks, John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 26 January, 2004 08:02 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue: DCC typing issues >=20 >=20 > DCC typing issues > Submitter name: Pasi Eronen > Date first submitted: 26.1.2004 > Reference:=20 > Document: cc-02 > Comment type: T/E > Priority: 1 > Section: various > Rationale/Explanation of issues:=20 >=20 > I have to admit that I haven't fully read and understood the > document (it's long and quite complicated...), but here are=20 > anyway some nits: >=20 > - 4.1: RFC3588 says that unrecognized AVPs with 'M' bit cause=20 > DIAMETER_AVP_UNSUPPORTED error, not DIAMETER_RATING_FAILED. > If the intent is to override RFC3588, please say so explicitly. >=20 > - 8.8: Cost-Unit is specified as UTF8String without any guidance > to its contents. Will this lead to interoperability (or other)=20 > problems if e.g. one implementation uses "kilobyte" and=20 > another "kB"? (hmm, is this 1000 or 1024 bytes... :-) >=20 > - 8.17: Should specify whether IPv4/IPv6 addresses are just > octets or textual representation (and for IPv6, which=20 > textual representation). >=20 > - 8.24: Service-Parameter-Type should probably specify how these > values are allocated, or who is responsible for selecting them=20 > (and ensuring that they are unique within some context). >=20 > - 8.25: Service-Parameter-Value should be OctetString rather than > UTF8String if it's going to be used for BER-encoded ASN.1. >=20 > - 8.36: "The CC-Service-Specific-Units AVP (AVP Code 417) is of type=20 > OctetString, and specifies the number of service specific units=20 > (e.g. number of events, points) given in a selected service." >=20 > IMHO "a number" would hint that OctetString is not probably the best > choice here (and is e.g. 1 packet encoded as "0x01", "0x31" or > perhaps "0x00 0x00 0x00 0x01"?). However, I'm not sure if this needs > to be an integer or floating point (can we assume that > service-specific units are scaled so that floats are not necessary?) >=20 > (8.16 also says that "...the value of the CC-Service-Specific-Units > AVP is set to FFFFFFFF to indicate free-of-charge.", which is=20 > a bit strange if it's an OctetString.) >=20 > - A.7 "..with Unit-Type set to CREDIT_TYPE_SERVICE_SPECIFIC and > Unit-Value set to the number of points..."; the spec doesn't=20 > define a Unit-Type AVP (anymore?) >=20 > Best regards, > Pasi >=20 From owner-aaa-wg@merit.edu Mon Jan 26 08:59: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 IAA06146 for ; Mon, 26 Jan 2004 08:59:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9436F9125C; Mon, 26 Jan 2004 08:59:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61DFD9125D; Mon, 26 Jan 2004 08:59: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 2112A9125C for ; Mon, 26 Jan 2004 08:59:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B8DC5DDA3; Mon, 26 Jan 2004 08:59:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (unknown [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 45F1B5DD9E for ; Mon, 26 Jan 2004 08:59:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0QDxLqY002711; Mon, 26 Jan 2004 14:59:21 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jan 2004 15:01:34 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "Leena Mattila (TU/LMF)" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'juha-pekka.koskinen@nokia.com'" , Christopher Richards , Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Mon, 26 Jan 2004 14:59:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Mark, >I'd be interested learning more about the Credit-Pool-ID that >you referred to in your earlier mail. Marco illustrated in previous mail how multiple accounts are supported in draft 02 in a way transparently to the client. Another option may be to let the server indicate to the client what are the flows that are funded from different accounts in the answer to the first CCR(initial) request. This can be seen as enhancement to the "Multiple services in a user's session, independent quotas" issue which we sent: http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00003.html It is stated in the draft that all the services subject to the same rate are part of the same rating group. On the other hand, user can have several accounts for different services and in which case reservation should be done from the right account based on Service-Id. So it can be happen, that the server can notice that two services belonging same rating group should funded out of different accounts and thus own sub-session would be needed for both services, if independent control of allocated quotas are required. To avoid this happen, The Credit-Pool-Id AVP might help. In CCA[initial] Credit-Pool-Id AVP can be included in the G-S-U to point out which Rating-Group/Services requires own sub-sessions. The client would then open a sub-session for each of these pools whenever a service request matching the relevant filter is met. An example of this method is shown in figure below: End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time), | | | Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Service-Id 2, | | | Credit-Pool 1), | | | Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Credit-Pool 2), | | | Granted-Units(Rating-Group 2, | | | Service-Id 4, | | | Service-Id 5, | | | Credit-Pool 3)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(initial,sub-session 1, | | | Requested-Units(Rating-Group 1, | | | Service-Id 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 3) | |------------------>|(8)CCR(initial,sub-session 2, | | | Requested-Units(Rating-Group 1, | | | Service-Id 3)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Total-Octets)) | | |<----------------------------------------| : : : Regards........Harri From owner-aaa-wg@merit.edu Mon Jan 26 09:04: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 JAA06340 for ; Mon, 26 Jan 2004 09:04:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58C9A9125B; Mon, 26 Jan 2004 09:04:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 267239125D; Mon, 26 Jan 2004 09:04: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 CFA299125B for ; Mon, 26 Jan 2004 09:04:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA99D5DDAC; Mon, 26 Jan 2004 09:04:03 -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 82ED75DDA1 for ; Mon, 26 Jan 2004 09:04:02 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QE41V13328 for ; Mon, 26 Jan 2004 16:04:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 16:03:57 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 16:03:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussion Date: Mon, 26 Jan 2004 16:03:56 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8311@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: multiple services in a user session, tech. discussion Thread-Index: AcPhzOWdBtBmK9hDTEC+yoU2yiKY+QCR/D4g From: To: Cc: , , , , , , , , , , X-OriginalArrivalTime: 26 Jan 2004 14:03:58.0008 (UTC) FILETIME=[3DE09380:01C3E415] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mark, >Thanks for these explanations - I think I understand how the mechanism = is >supposed to work now, but just to check, assuming a single sub-session >within a session: > >When the client needs authorisation for a new flow, or re-authorisation = of >an existing one (Validity-time timeout etc.) it must always return a >CCR(UPD) containing the units used for all ongoing flows. Then the = server >will re-authorise all of these, potentially making a new credit=20 >reservation. >Right ? > >"This is because you cannot leave service units running in the client = while >the >server is doing operations on the credit reservation from which these = units >are derived." Yes, within a DCC session/sub-session when the client need to authorize = a=20 new service flow or re-authorize an existing one it must return CCR(UPD) = containing the units used for all ongoing service flows. Note that re-authorization of already authorized service flows doesn't = imply=20 service interruption since the new received service units apply from the = point=20 when the CCR(UPD) was sent, as stated in section 5.2: "When the used units are reported to the credit-control server the credit-control client will not have any units in its possession = before new granted units are received from the credit-control server. When the new granted units are received from the credit-control server these units apply from the point where the measurement of the = reported used units stopped." >Secondly, parameters such as Validity-Time are associated with the = whole >sub-session, so if different flows have different Validity-Times then=20 >server >uses the lowest one. Correct. This is equivalent to set Validity-Time associated to each of = the=20 service flows, since the first that expires will cause all the others to = be=20 reported. >Thirdly, when flows within a sub-session are funded from separate = accounts, >the server must make reservations 'of equivalent value' from each = accounts. >The client will request re-authorisation when a total of one times this >value have been used by the user. Correct. Of course the client may also request re-authorization upon = other events as well e.g. Validity-Time expires etc. >Finally, the client has a choice of requesting a single reservation = shared >across multiple flows, or a separate reservation for each flow. It does = >this >by establishing a single subsession in the former case of separate >sub-sessions for each flow in the latter case. Correct. In the former case the client can even not use a sub-session at = all=20 as in the example I sent. The client would establish one DCC session per = each=20 of the PDP context a subscriber open to a given APN, no need of = sub-sessions. Alternatively secondary PDP context may cause DCC sub-session, this=20 sub-session controls all the service flows carried in that PDP context. In the latter case the client establishes a single sub-session for each = flow=20 by requesting authorization/re-authorization only for a single = rating-group or=20 service-identifier within the sub-session. Question to you Mark: we thought that would be enough to integrate some text in existing sections to address the multiple services in a user's session feature, but apparently it is not clear how things are supposed to work. Do you think this feature should have its own sub-section=20 under e.g. section 5 where all the aspects we discussed would be somehow included? Regards Marco From owner-aaa-wg@merit.edu Mon Jan 26 09:26: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 JAA06780 for ; Mon, 26 Jan 2004 09:26:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 639DB9125F; Mon, 26 Jan 2004 09:23:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26BA891262; Mon, 26 Jan 2004 09:23: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 4EF429125F for ; Mon, 26 Jan 2004 09:23:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0ABF5DDC3; Mon, 26 Jan 2004 09:23: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 091955DDB6 for ; Mon, 26 Jan 2004 09:23: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 i0QEN2Z07908; Mon, 26 Jan 2004 14:23:03 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jan 2004 14:23:02 -0000 Message-ID: From: "Mark Watson" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'Patrik Teppo (KA/EAB)'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Mon, 26 Jan 2004 14:23:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E417.E6D5C67A" 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_01C3E417.E6D5C67A Content-Type: text/plain Harri, Yes, something like this would address one of our concerns. Any reason why the client needs to establish new sub-sessions for the separate pools ? Why can't they be managed as separate pools within a single (sub-)session ? Regards...Mark -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: 26 January 2004 13:59 To: Watson, Mark [MOP:EP10:EXCH]; 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Mark, >I'd be interested learning more about the Credit-Pool-ID that you >referred to in your earlier mail. Marco illustrated in previous mail how multiple accounts are supported in draft 02 in a way transparently to the client. Another option may be to let the server indicate to the client what are the flows that are funded from different accounts in the answer to the first CCR(initial) request. This can be seen as enhancement to the "Multiple services in a user's session, independent quotas" issue which we sent: http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00003.html It is stated in the draft that all the services subject to the same rate are part of the same rating group. On the other hand, user can have several accounts for different services and in which case reservation should be done from the right account based on Service-Id. So it can be happen, that the server can notice that two services belonging same rating group should funded out of different accounts and thus own sub-session would be needed for both services, if independent control of allocated quotas are required. To avoid this happen, The Credit-Pool-Id AVP might help. In CCA[initial] Credit-Pool-Id AVP can be included in the G-S-U to point out which Rating-Group/Services requires own sub-sessions. The client would then open a sub-session for each of these pools whenever a service request matching the relevant filter is met. An example of this method is shown in figure below: End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time), | | | Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Service-Id 2, | | | Credit-Pool 1), | | | Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Credit-Pool 2), | | | Granted-Units(Rating-Group 2, | | | Service-Id 4, | | | Service-Id 5, | | | Credit-Pool 3)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(initial,sub-session 1, | | | Requested-Units(Rating-Group 1, | | | Service-Id 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 3) | |------------------>|(8)CCR(initial,sub-session 2, | | | Requested-Units(Rating-Group 1, | | | Service-Id 3)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Total-Octets)) | | |<----------------------------------------| : : : Regards........Harri ------_=_NextPart_001_01C3E417.E6D5C67A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussi on

Harri,

Yes, something like this would address one of our = concerns. Any reason why the client needs to establish new sub-sessions = for the separate pools ? Why can't they be managed as separate pools = within a single (sub-)session ?

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: 26 January 2004 13:59
To: Watson, Mark [MOP:EP10:EXCH]; = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Richards, Christopher = [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


Hi Mark,

>I'd be interested learning more about the = Credit-Pool-ID that you
>referred to in your earlier mail.

Marco illustrated in previous mail how multiple = accounts are supported in draft 02 in a way transparently to the = client.

Another option may be to let the server indicate to = the client what are the flows
that are funded from different accounts in the = answer to the first CCR(initial) request. This can be seen as = enhancement to the "Multiple services in a user's session, = independent quotas" issue which we sent: http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg0= 0003.html

It is stated in the draft that all the services = subject to the same rate are
part of the same rating group. On the other hand, = user can have several accounts for different services and in which case = reservation should be done from the right account based on Service-Id. = So it can be happen, that the server can notice that two services = belonging same rating group should funded out of different accounts =

and thus own sub-session would be needed for both = services, if independent control of allocated quotas are = required.

To avoid this happen, The Credit-Pool-Id AVP might = help. In CCA[initial] Credit-Pool-Id AVP can be included in the G-S-U = to point out which Rating-Group/Services requires own sub-sessions. The = client would then open a sub-session for each of these pools =

whenever a service request matching the relevant = filter is met. An example of this method is shown in figure = below:


End-User         &= nbsp; (CC = client)           = ;            = ;       CC Server
 |(1)User logon      = |            = ;            = ;            = ;     |
 |------------------>|(2)CCR(initial, = Service-Id(access))      |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(3)CCA(Granted-Units(Time),       &n= bsp;      |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 1,       |
 |         &n= bsp;         = |            = ;         Service-Id = 2,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 1),     |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 3,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 2),     |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 2,     |
 |         &n= bsp;         = |            = ;         Service-Id = 4,       |
 |         &n= bsp;         = |            = ;         Service-Id = 5,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 3))     |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(4)Service-Request (Service = 1)           &nbs= p;           &nbs= p;       |
 |------------------>|(5)CCR(initial,sub-session = 1,            = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1,   |
 |         &n= bsp;         = |            = ;           = Service-Id 1))    |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(6)CCA(Granted-Units(Rating-Group 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 1,       |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(7)Service-Request (Service = 3)           &nbs= p;           &nbs= p;       |
 |------------------>|(8)CCR(initial,sub-session = 2,            = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1,   |
 |         &n= bsp;         = |            = ;           = Service-Id 3))    |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(9)CCA(Granted-Units(Rating-Group 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 3,       |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
:          &n= bsp;        = :            = ;            = ;            = ;     :

Regards........Harri

------_=_NextPart_001_01C3E417.E6D5C67A-- From owner-aaa-wg@merit.edu Mon Jan 26 09:26: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 JAA06798 for ; Mon, 26 Jan 2004 09:26:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD02F91290; Mon, 26 Jan 2004 09:26:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D08A912B1; Mon, 26 Jan 2004 09:26: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 C7ADB91290 for ; Mon, 26 Jan 2004 09:26:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id B17625DDBF; Mon, 26 Jan 2004 09:26:10 -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 29BDA5DDB3 for ; Mon, 26 Jan 2004 09:26:10 -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 i0QEPHZ08345; Mon, 26 Jan 2004 14:25:17 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jan 2004 14:25:16 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'leena.mattila@ericsson.com'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'patrik.teppo@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" , "'harri.hakala@ericsson.com'" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Mon, 26 Jan 2004 14:25:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E418.324F378A" 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_01C3E418.324F378A Content-Type: text/plain Hi Marco, Thanks. To answer your question, then yes, I think a clearer description in its own section would probably be useful. However, if I were you I'd hold off on drafting anything until you have seen our promised detailed last call issues/proposals. Regards, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 26 January 2004 14:04 To: Watson, Mark [MOP:EP10:EXCH] Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; harri.hakala@ericsson.com Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussion Hi Mark, >Thanks for these explanations - I think I understand how the mechanism >is supposed to work now, but just to check, assuming a single >sub-session within a session: > >When the client needs authorisation for a new flow, or re-authorisation >of an existing one (Validity-time timeout etc.) it must always return a >CCR(UPD) containing the units used for all ongoing flows. Then the >server will re-authorise all of these, potentially making a new credit >reservation. Right ? > >"This is because you cannot leave service units running in the client >while the server is doing operations on the credit reservation from >which these units are derived." Yes, within a DCC session/sub-session when the client need to authorize a new service flow or re-authorize an existing one it must return CCR(UPD) containing the units used for all ongoing service flows. Note that re-authorization of already authorized service flows doesn't imply service interruption since the new received service units apply from the point when the CCR(UPD) was sent, as stated in section 5.2: "When the used units are reported to the credit-control server the credit-control client will not have any units in its possession before new granted units are received from the credit-control server. When the new granted units are received from the credit-control server these units apply from the point where the measurement of the reported used units stopped." >Secondly, parameters such as Validity-Time are associated with the >whole sub-session, so if different flows have different Validity-Times >then server uses the lowest one. Correct. This is equivalent to set Validity-Time associated to each of the service flows, since the first that expires will cause all the others to be reported. >Thirdly, when flows within a sub-session are funded from separate >accounts, the server must make reservations 'of equivalent value' from >each accounts. The client will request re-authorisation when a total of >one times this value have been used by the user. Correct. Of course the client may also request re-authorization upon other events as well e.g. Validity-Time expires etc. >Finally, the client has a choice of requesting a single reservation >shared across multiple flows, or a separate reservation for each flow. >It does this by establishing a single subsession in the former case of >separate sub-sessions for each flow in the latter case. Correct. In the former case the client can even not use a sub-session at all as in the example I sent. The client would establish one DCC session per each of the PDP context a subscriber open to a given APN, no need of sub-sessions. Alternatively secondary PDP context may cause DCC sub-session, this sub-session controls all the service flows carried in that PDP context. In the latter case the client establishes a single sub-session for each flow by requesting authorization/re-authorization only for a single rating-group or service-identifier within the sub-session. Question to you Mark: we thought that would be enough to integrate some text in existing sections to address the multiple services in a user's session feature, but apparently it is not clear how things are supposed to work. Do you think this feature should have its own sub-section under e.g. section 5 where all the aspects we discussed would be somehow included? Regards Marco ------_=_NextPart_001_01C3E418.324F378A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussion

Hi Marco,

Thanks.

To answer your question, then yes, I think a clearer = description in its own section would probably be useful.

However, if I were you I'd hold off on drafting = anything until you have seen our promised detailed last call = issues/proposals.

Regards,

Mark

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 26 January 2004 14:04
To: Watson, Mark [MOP:EP10:EXCH]
Cc: john.loughney@nokia.com; = juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; = aaa-wg@merit.edu; Karl-Heinz.Nenner@t-mobile.de; = Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; = juha-pekka.koskinen@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; = Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; = harri.hakala@ericsson.com

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussion


Hi Mark,

>Thanks for these explanations - I think I = understand how the mechanism
>is supposed to work now, but just to check, = assuming a single
>sub-session within a session:
>
>When the client needs authorisation for a new = flow, or re-authorisation
>of an existing one (Validity-time timeout etc.) = it must always return a
>CCR(UPD) containing the units used for all = ongoing flows. Then the
>server will re-authorise all of these, = potentially making a new credit
>reservation. Right ?
>
>"This is because you cannot leave service = units running in the client
>while the server is doing operations on the = credit reservation from
>which these units are derived."

Yes, within a DCC session/sub-session when the client = need to authorize a
new service flow or re-authorize an existing one it = must return CCR(UPD)
containing the units used for all ongoing service = flows.
Note that re-authorization of already authorized = service flows doesn't imply
service interruption since the new received service = units apply from the point
when the CCR(UPD) was sent, as stated in section = 5.2:

   "When the used units are reported = to the credit-control server the
   credit-control client will not have any = units in its possession before
   new granted units are received from the = credit-control server. When
   the new granted units are received from = the credit-control server
   these units apply from the point where = the measurement of the reported
   used units stopped."

>Secondly, parameters such as Validity-Time are = associated with the
>whole sub-session, so if different flows have = different Validity-Times
>then server uses the lowest one.

Correct. This is equivalent to set Validity-Time = associated to each of the
service flows, since the first that expires will = cause all the others to be
reported.

>Thirdly, when flows within a sub-session are = funded from separate
>accounts, the server must make reservations 'of = equivalent value' from
>each accounts. The client will request = re-authorisation when a total of
>one times this value have been used by the = user.

Correct. Of course the client may also request = re-authorization upon other events as well e.g. Validity-Time expires = etc.

>Finally, the client has a choice of requesting a = single reservation
>shared across multiple flows, or a separate = reservation for each flow.
>It does this by establishing a single = subsession  in the former case of
>separate sub-sessions for each flow in the = latter case.

Correct. In the former case the client can even not = use a sub-session at all
as in the example I sent. The client would establish = one DCC session per each
of the PDP context a subscriber open to a given APN, = no need of sub-sessions. Alternatively secondary PDP context may cause = DCC sub-session, this

sub-session controls all the service flows carried in = that PDP context.

In the latter case the client establishes a single = sub-session for each flow
by requesting authorization/re-authorization only = for a single rating-group or
service-identifier within the sub-session.

Question to you Mark: we thought that would be enough = to integrate some text in existing sections to address the multiple = services in a user's session feature, but apparently it is not clear = how things are supposed to work. Do you think this feature should have = its own sub-section

under e.g. section 5 where all the aspects we = discussed would be somehow included?

Regards
Marco

------_=_NextPart_001_01C3E418.324F378A-- From owner-aaa-wg@merit.edu Mon Jan 26 09:46: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 JAA07347 for ; Mon, 26 Jan 2004 09:46:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6867E91261; Mon, 26 Jan 2004 09:45:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D5C191262; Mon, 26 Jan 2004 09:45: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 E8BFC91261 for ; Mon, 26 Jan 2004 09:45:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id C46175DD8F; Mon, 26 Jan 2004 09:45:24 -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 21BB05DD9C for ; Mon, 26 Jan 2004 09:45:23 -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 i0QEjLV05755 for ; Mon, 26 Jan 2004 16:45:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 16:45:21 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 16:45: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_01C3E41B.04F75F2B" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussion Date: Mon, 26 Jan 2004 16:45:19 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8314@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: multiple services in a user session, tech. discussion Thread-Index: AcPkGFf9IkkwhLc5QjeN2nTVUfA4dAAAjc9A From: To: Cc: , , , , , , , , , , X-OriginalArrivalTime: 26 Jan 2004 14:45:20.0163 (UTC) FILETIME=[055B5F30:01C3E41B] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E41B.04F75F2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >However, if I were you I'd hold off on drafting anything until you have = seen our promised detailed last call issues/proposals. =20 Yes of course. =20 Marco -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 26 January, 2004 16:25 To: Stura Marco (Nokia-NET/Helsinki) Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka = (Nokia-NET/Tampere); 'leena.mattila@ericsson.com'; 'aaa-wg@merit.edu'; = 'Karl-Heinz.Nenner@t-mobile.de'; Alexander Benni (Nokia-NET/Espoo); = 'patrik.teppo@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); = Christopher Richards; Javier Gonzalez Gallego; = 'harri.hakala@ericsson.com' Subject: RE: [AAA-WG]: multiple services in a user session, tech. = discussion Hi Marco,=20 Thanks.=20 To answer your question, then yes, I think a clearer description in its = own section would probably be useful.=20 However, if I were you I'd hold off on drafting anything until you have = seen our promised detailed last call issues/proposals. Regards,=20 Mark=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: 26 January 2004 14:04=20 To: Watson, Mark [MOP:EP10:EXCH]=20 Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; = leena.mattila@ericsson.com; aaa-wg@merit.edu; = Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; = patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com; Richards, = Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; = harri.hakala@ericsson.com Subject: RE: [AAA-WG]: multiple services in a user session, tech. = discussion=20 Hi Mark,=20 >Thanks for these explanations - I think I understand how the mechanism=20 >is supposed to work now, but just to check, assuming a single=20 >sub-session within a session:=20 >=20 >When the client needs authorisation for a new flow, or re-authorisation = >of an existing one (Validity-time timeout etc.) it must always return a = >CCR(UPD) containing the units used for all ongoing flows. Then the=20 >server will re-authorise all of these, potentially making a new credit=20 >reservation. Right ?=20 >=20 >"This is because you cannot leave service units running in the client=20 >while the server is doing operations on the credit reservation from=20 >which these units are derived."=20 Yes, within a DCC session/sub-session when the client need to authorize = a=20 new service flow or re-authorize an existing one it must return CCR(UPD) = containing the units used for all ongoing service flows.=20 Note that re-authorization of already authorized service flows doesn't = imply=20 service interruption since the new received service units apply from the = point=20 when the CCR(UPD) was sent, as stated in section 5.2:=20 "When the used units are reported to the credit-control server the=20 credit-control client will not have any units in its possession = before=20 new granted units are received from the credit-control server. When=20 the new granted units are received from the credit-control server=20 these units apply from the point where the measurement of the = reported=20 used units stopped."=20 >Secondly, parameters such as Validity-Time are associated with the=20 >whole sub-session, so if different flows have different Validity-Times=20 >then server uses the lowest one.=20 Correct. This is equivalent to set Validity-Time associated to each of = the=20 service flows, since the first that expires will cause all the others to = be=20 reported.=20 >Thirdly, when flows within a sub-session are funded from separate=20 >accounts, the server must make reservations 'of equivalent value' from=20 >each accounts. The client will request re-authorisation when a total of = >one times this value have been used by the user.=20 Correct. Of course the client may also request re-authorization upon = other events as well e.g. Validity-Time expires etc. >Finally, the client has a choice of requesting a single reservation=20 >shared across multiple flows, or a separate reservation for each flow.=20 >It does this by establishing a single subsession in the former case of = >separate sub-sessions for each flow in the latter case.=20 Correct. In the former case the client can even not use a sub-session at = all=20 as in the example I sent. The client would establish one DCC session per = each=20 of the PDP context a subscriber open to a given APN, no need of = sub-sessions. Alternatively secondary PDP context may cause DCC = sub-session, this=20 sub-session controls all the service flows carried in that PDP context.=20 In the latter case the client establishes a single sub-session for each = flow=20 by requesting authorization/re-authorization only for a single = rating-group or=20 service-identifier within the sub-session.=20 Question to you Mark: we thought that would be enough to integrate some = text in existing sections to address the multiple services in a user's = session feature, but apparently it is not clear how things are supposed = to work. Do you think this feature should have its own sub-section=20 under e.g. section 5 where all the aspects we discussed would be somehow = included?=20 Regards=20 Marco=20 ------_=_NextPart_001_01C3E41B.04F75F2B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussion
>However, = if I were=20 you I'd hold off on drafting anything until you have seen our promised = detailed=20 last call issues/proposals.
 
Yes of=20 course.
 
Marco
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 26 January, 2004=20 16:25
To: Stura Marco (Nokia-NET/Helsinki)
Cc: = Loughney=20 John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere);=20 'leena.mattila@ericsson.com'; 'aaa-wg@merit.edu';=20 'Karl-Heinz.Nenner@t-mobile.de'; Alexander Benni (Nokia-NET/Espoo);=20 'patrik.teppo@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere);=20 Christopher Richards; Javier Gonzalez Gallego;=20 'harri.hakala@ericsson.com'
Subject: RE: [AAA-WG]: multiple = services=20 in a user session, tech. discussion

Hi Marco,

Thanks.

To answer your question, then yes, I think a clearer = description in its own section would probably be useful.

However, if I were you I'd hold off on drafting = anything until=20 you have seen our promised detailed last call = issues/proposals.

Regards,

Mark

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: 26 January 2004 14:04
To: Watson, Mark [MOP:EP10:EXCH]
Cc:=20 john.loughney@nokia.com; juha-pekka.koskinen@nokia.com;=20 leena.mattila@ericsson.com; aaa-wg@merit.edu; = Karl-Heinz.Nenner@t-mobile.de;=20 Benni.Alexander@nokia.com; patrik.teppo@ericsson.com;=20 juha-pekka.koskinen@nokia.com; Richards, Christopher = [RICH2:2Q40:EXCH];=20 Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; = harri.hakala@ericsson.com

Subject: RE: [AAA-WG]: multiple services in a user = session,=20 tech. discussion


Hi Mark,

>Thanks for these explanations - I think I = understand how=20 the mechanism
>is supposed to work now, = but just to=20 check, assuming a single
>sub-session = within a=20 session:
>
>When the=20 client needs authorisation for a new flow, or re-authorisation=20
>of an existing one (Validity-time = timeout etc.) it=20 must always return a
>CCR(UPD) containing = the units=20 used for all ongoing flows. Then the
>server will=20 re-authorise all of these, potentially making a new credit =
>reservation. Right ?
>
>"This is because you cannot leave service units running = in the=20 client
>while the server is doing = operations on the=20 credit reservation from
>which these = units are=20 derived."

Yes, within a DCC session/sub-session when the = client need to=20 authorize a
new service flow or re-authorize = an=20 existing one it must return CCR(UPD)
containing the=20 units used for all ongoing service flows.
Note that=20 re-authorization of already authorized service flows doesn't imply=20
service interruption since the new received = service=20 units apply from the point
when the CCR(UPD) = was sent,=20 as stated in section 5.2:

   "When the used units are reported to = the=20 credit-control server the
   = credit-control=20 client will not have any units in its possession before =
   new granted units are received from the = credit-control=20 server. When
   the new granted = units are=20 received from the credit-control server
  =20 these units apply from the point where the measurement of the = reported=20
   used units stopped."

>Secondly, parameters such as Validity-Time are = associated=20 with the
>whole sub-session, so if = different flows=20 have different Validity-Times
>then = server uses the=20 lowest one.

Correct. This is equivalent to set Validity-Time = associated to=20 each of the
service flows, since the first = that=20 expires will cause all the others to be
reported.

>Thirdly, when flows within a sub-session are = funded from=20 separate
>accounts, the server must make=20 reservations 'of equivalent value' from
>each=20 accounts. The client will request re-authorisation when a total of=20
>one times this value have been used by = the=20 user.

Correct. Of course the client may also request=20 re-authorization upon other events as well e.g. Validity-Time expires=20 etc.

>Finally, the client has a choice of requesting a = single=20 reservation
>shared across multiple = flows, or a=20 separate reservation for each flow.
>It = does this=20 by establishing a single subsession  in the former case of=20
>separate sub-sessions for each flow in = the latter=20 case.

Correct. In the former case the client can even not = use a=20 sub-session at all
as in the example I sent. = The=20 client would establish one DCC session per each
of the=20 PDP context a subscriber open to a given APN, no need of sub-sessions. = Alternatively secondary PDP context may cause DCC sub-session, this=20

sub-session controls all the service flows carried = in that PDP=20 context.

In the latter case the client establishes a single = sub-session=20 for each flow
by requesting=20 authorization/re-authorization only for a single rating-group or=20
service-identifier within the = sub-session.

Question to you Mark: we thought that would be = enough to=20 integrate some text in existing sections to address the multiple = services in a=20 user's session feature, but apparently it is not clear how things are = supposed=20 to work. Do you think this feature should have its own sub-section =

under e.g. section 5 where all the aspects we = discussed would=20 be somehow included?

Regards
Marco=20

------_=_NextPart_001_01C3E41B.04F75F2B-- From owner-aaa-wg@merit.edu Tue Jan 27 10:33:58 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 KAA09776 for ; Tue, 27 Jan 2004 10:33:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2E25B91210; Tue, 27 Jan 2004 10:33:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F027291284; Tue, 27 Jan 2004 10:33:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6819491210 for ; Tue, 27 Jan 2004 10:33:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 516C65DDD3; Tue, 27 Jan 2004 10:33:35 -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 A21E95DDF4 for ; Tue, 27 Jan 2004 10:33:34 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0RFXUqZ019949; Tue, 27 Jan 2004 16:33:31 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 16:33:19 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "Leena Mattila (TU/LMF)" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'juha-pekka.koskinen@nokia.com'" , Christopher Richards , Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Tue, 27 Jan 2004 15:32:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Mark, >Any reason why the client needs to establish new sub-sessions for the separate pools ? >Why can't they be managed as separate pools within a single (sub-)session ? To manage separate pools within a single (sub-)session it would require it's own CCR/CCA pair and it's own instance of the DCC state machine as well as it's own Tx timer. This way we have created sort of implicit sub-sessions multiplexed within a (sub-)session, but it makes more complex the failure handling, setting correct combination of failure handling AVPs and handle functionalities such as the GST. What we would eventually save as compared to explicit sub-session are couple of messages to close the sub-session when the user logoff (or the PDP context is closed). However, it is always possible to send only the CCR(termination) for the main session including multiple instances of the U-S-U. This would implicitly close all the sub- sessions, the server is always able to deduct used credit from the right account because we have associated service-id to the U-S-U. There is no difference in signaling load, but much cleaner failure handling etc. if we explicitly signal sub-sessions. The sequence below shows that same signalling load is needed both implicit and explicit sub-session handling cases, but having explicit sub-session simplify the failure handling etc. Flow example with implicit sub-sessions: End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time), | | | Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Service-Id 2, | | | Credit-Pool 1), | | | Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Credit-Pool 2), | | | Granted-Units(Rating-Group 2, | | | Service-Id 4, | | | Service-Id 5, | | | Credit-Pool 3)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(update, | | | Requested-Units(Rating-Group 1, | | | Service-Id 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 3) | |------------------>|(8)CCR(update, | | | Requested-Units(Rating-Group 1, | | | Service-Id 3)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Total-Octets)) | | |<----------------------------------------| : : : |(10)User logoff | | |------------------>|(11)CCR(termination, U-S-U(Service-Id(access)), | | U-S-U(RG1, Service-Id 3), | | | U-S-U(RG1, Service-Id 1), | | |---------------------------------------->| Flow example with explicit sub-sessions: End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time), | | | Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Service-Id 2, | | | Credit-Pool 1), | | | Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Credit-Pool 2), | | | Granted-Units(Rating-Group 2, | | | Service-Id 4, | | | Service-Id 5, | | | Credit-Pool 3)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(initial,sub-session 1, | | | Requested-Units(Rating-Group 1, | | | Service-Id 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 3) | |------------------>|(8)CCR(initial,sub-session 2, | | | Requested-Units(Rating-Group 1, | | | Service-Id 3)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Total-Octets)) | | |<----------------------------------------| : : : |(10)User logoff | | |------------------>|(11)CCR(termination, U-S-U(Service-Id(access)), | | U-S-U(RG1, Service-Id 3), | | | U-S-U(RG1, Service-Id 1)) | | |---------------------------------------->| From owner-aaa-wg@merit.edu Tue Jan 27 10:34: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 KAA09798 for ; Tue, 27 Jan 2004 10:34:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D8CD691284; Tue, 27 Jan 2004 10:33:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7138191293; Tue, 27 Jan 2004 10:33: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 3920991284 for ; Tue, 27 Jan 2004 10:33:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 144AA5DE10; Tue, 27 Jan 2004 10:33:47 -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 88F025DDF3 for ; Tue, 27 Jan 2004 10:33:46 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0RFXiYJ002724; Tue, 27 Jan 2004 16:33:45 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 16:33:30 +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: Tue, 27 Jan 2004 15:40:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pasi, Thank you very much for reviewing the draft. Inline some answers to your comments. Regards.......Harri > - 8.24: Service-Parameter-Type should probably specify how these > values are allocated, or who is responsible for selecting them > (and ensuring that they are unique within some context). Yes, that is intention. The previous AVP, 8.23 Service-Parameter-Info AVP, defines: ....The Service-Parameter-Type AVP defines the service parameter type and the Service-Parameter-Value AVP contains the parameter value. The actual contents of these AVPs are not within the scope of this document and SHOULD be defined in another Diameter application, standards written by other standardization bodies, or service specific documentation..... Is this enough, or do you think that we need more specific statements how to values of Service-Parameter-Type should be specified? > > - 8.25: Service-Parameter-Value should be OctetString rather than > UTF8String if it's going to be used for BER-encoded ASN.1. OK. DCC issue 11 should fix this: http://danforsberg.info:8080/draft-ietf-aaa-diameter-cc/issue11 > - 8.36: "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." > > IMHO "a number" would hint that OctetString is not probably the best > choice here (and is e.g. 1 packet encoded as "0x01", "0x31" or > perhaps "0x00 0x00 0x00 0x01"?). However, I'm not sure if this needs > to be an integer or floating point (can we assume that > service-specific units are scaled so that floats are not necessary?) > > (8.16 also says that "...the value of the CC-Service-Specific-Units > AVP is set to FFFFFFFF to indicate free-of-charge.", which is > a bit strange if it's an OctetString.) OK, the same DCC issue should fix this as well. > > - A.7 "..with Unit-Type set to CREDIT_TYPE_SERVICE_SPECIFIC and > Unit-Value set to the number of points..."; the spec doesn't > define a Unit-Type AVP (anymore?) OK. Should be: ...with CC-Service-Specific-Units containing the number of points... > > Best regards, > Pasi > From owner-aaa-wg@merit.edu Tue Jan 27 11:14: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 LAA11420 for ; Tue, 27 Jan 2004 11:14:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C7259128D; Tue, 27 Jan 2004 11:14:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FE899128F; Tue, 27 Jan 2004 11:14: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 911FD9128D for ; Tue, 27 Jan 2004 11:14:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 643145DE85; Tue, 27 Jan 2004 11:14:12 -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 D88B65DE74 for ; Tue, 27 Jan 2004 11:14:10 -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 i0RGE0802877; Tue, 27 Jan 2004 16:14:00 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jan 2004 16:14:00 -0000 Message-ID: From: "Mark Watson" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'Patrik Teppo (KA/EAB)'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Tue, 27 Jan 2004 16:13:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E4F0.8D98FDE6" 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_01C3E4F0.8D98FDE6 Content-Type: text/plain HI Harri, Ok, so you flows show no actual units being provided to the client in the answer to the initial request. So the client is just learning the Service/Rating-Group <> Credit Pool mapping at this stage. Then it handles each Credit Pool in a separate sub-session. Would it also be possible to return actual Service Units in this initial response ? How are those then 'transferred' into the new per Credit Pool sub-sessions ? I'm thinking of the case where the client does not indicate the required Service/Rating-Groups to the server until they are actually used. And it has no information about Service/Rating <> Credit Pool mapping when it requests the units. I wasn't sure why you would need a separate CC state machine for each credit pool - presumably we can shut off/redirect traffic within one credit pool without closing the (sub-)session by returning zero units and attaching the appropriate redirect AVPs etc. to the G-S-U, right ? Regards...Mark -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: 27 January 2004 14:33 To: Watson, Mark [MOP:EP10:EXCH]; 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Mark, >Any reason why the client needs to establish new sub-sessions for the >separate pools ? Why can't they be managed as separate pools within a >single (sub-)session ? To manage separate pools within a single (sub-)session it would require it's own CCR/CCA pair and it's own instance of the DCC state machine as well as it's own Tx timer. This way we have created sort of implicit sub-sessions multiplexed within a (sub-)session, but it makes more complex the failure handling, setting correct combination of failure handling AVPs and handle functionalities such as the GST. What we would eventually save as compared to explicit sub-session are couple of messages to close the sub-session when the user logoff (or the PDP context is closed). However, it is always possible to send only the CCR(termination) for the main session including multiple instances of the U-S-U. This would implicitly close all the sub- sessions, the server is always able to deduct used credit from the right account because we have associated service-id to the U-S-U. There is no difference in signaling load, but much cleaner failure handling etc. if we explicitly signal sub-sessions. The sequence below shows that same signalling load is needed both implicit and explicit sub-session handling cases, but having explicit sub-session simplify the failure handling etc. Flow example with implicit sub-sessions: End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time), | | | Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Service-Id 2, | | | Credit-Pool 1), | | | Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Credit-Pool 2), | | | Granted-Units(Rating-Group 2, | | | Service-Id 4, | | | Service-Id 5, | | | Credit-Pool 3)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(update, | | | Requested-Units(Rating-Group 1, | | | Service-Id 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 3) | |------------------>|(8)CCR(update, | | | Requested-Units(Rating-Group 1, | | | Service-Id 3)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Total-Octets)) | | |<----------------------------------------| : : : |(10)User logoff | | |------------------>|(11)CCR(termination, U-S-U(Service-Id(access)), | | U-S-U(RG1, Service-Id 3), | | | U-S-U(RG1, Service-Id 1), | | |---------------------------------------->| Flow example with explicit sub-sessions: End-User (CC client) CC Server |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id(access)) | | |---------------------------------------->| | |(3)CCA(Granted-Units(Time), | | | Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Service-Id 2, | | | Credit-Pool 1), | | | Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Credit-Pool 2), | | | Granted-Units(Rating-Group 2, | | | Service-Id 4, | | | Service-Id 5, | | | Credit-Pool 3)) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(initial,sub-session 1, | | | Requested-Units(Rating-Group 1, | | | Service-Id 1)) | | |---------------------------------------->| | |(6)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 1, | | | Total-Octets)) | | |<----------------------------------------| : : : |(7)Service-Request (Service 3) | |------------------>|(8)CCR(initial,sub-session 2, | | | Requested-Units(Rating-Group 1, | | | Service-Id 3)) | | |---------------------------------------->| | |(9)CCA(Granted-Units(Rating-Group 1, | | | Service-Id 3, | | | Total-Octets)) | | |<----------------------------------------| : : : |(10)User logoff | | |------------------>|(11)CCR(termination, U-S-U(Service-Id(access)), | | U-S-U(RG1, Service-Id 3), | | | U-S-U(RG1, Service-Id 1)) | | |---------------------------------------->| ------_=_NextPart_001_01C3E4F0.8D98FDE6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussi on

HI Harri,

Ok, so you flows show no actual units being provided = to the client in the answer to the initial request. So the client is = just learning the Service/Rating-Group <> Credit Pool mapping at = this stage. Then it handles each Credit Pool in a separate = sub-session.

Would it also be possible to return actual Service = Units in this initial response ? How are those then 'transferred' into = the new per Credit Pool sub-sessions ?

I'm thinking of the case where the client does not = indicate the required Service/Rating-Groups to the server until they = are actually used. And it has no information about Service/Rating = <> Credit Pool mapping when it requests the units.

I wasn't sure why you would need a separate CC state = machine for each credit pool - presumably we can shut off/redirect = traffic within one credit pool without closing the (sub-)session by = returning zero units and attaching the appropriate redirect AVPs etc. = to the G-S-U, right ?

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: 27 January 2004 14:33
To: Watson, Mark [MOP:EP10:EXCH]; = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Richards, Christopher = [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


Hi Mark,

>Any reason why the client needs to establish new = sub-sessions for the
>separate pools ? Why can't they be managed as = separate pools within a
>single (sub-)session ?

To manage separate pools within a single = (sub-)session it would require it's own
CCR/CCA pair and it's own instance of the DCC state = machine as well as it's own Tx
timer. This way we have created sort of implicit = sub-sessions multiplexed within a (sub-)session, but it makes more = complex the failure handling, setting correct

combination of failure handling AVPs and handle = functionalities such as the GST.

What we would eventually save as compared to explicit = sub-session are couple of
messages to close the sub-session when the user = logoff (or the PDP context is closed). However, it is always possible = to send only the CCR(termination) for the main session including = multiple instances of the U-S-U. This would implicitly close all the = sub- sessions, the server is always able to deduct used credit from the = right account because we have associated service-id to the U-S-U. There = is no difference in signaling load, but much cleaner failure handling = etc. if we explicitly signal sub-sessions.

The sequence below shows that same signalling load is = needed both implicit and explicit sub-session handling cases, but = having explicit sub-session simplify the failure handling

etc.

Flow example with implicit sub-sessions:
End-User         &= nbsp; (CC = client)           = ;            = ;       CC Server
 |(1)User logon      = |            = ;            = ;            = ;     |
 |------------------>|(2)CCR(initial, = Service-Id(access))      |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(3)CCA(Granted-Units(Time),       &n= bsp;      |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 1,       |
 |         &n= bsp;         = |            = ;         Service-Id = 2,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 1),     |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 3,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 2),     |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 2,     |
 |         &n= bsp;         = |            = ;         Service-Id = 4,       |
 |         &n= bsp;         = |            = ;         Service-Id = 5,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 3))     |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(4)Service-Request (Service = 1)           &nbs= p;           &nbs= p;       |
 |------------------>|(5)CCR(update,   &= nbsp;           &= nbsp;           = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1,   |
 |         &n= bsp;         = |            = ;           = Service-Id 1))    |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(6)CCA(Granted-Units(Rating-Group 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 1,       |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(7)Service-Request (Service = 3)           &nbs= p;           &nbs= p;       |
 |------------------>|(8)CCR(update,   &= nbsp;           &= nbsp;           = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1,   |
 |         &n= bsp;         = |            = ;           = Service-Id 3))    |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(9)CCA(Granted-Units(Rating-Group 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 3,       |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(10)User logoff    = |            = ;            = ;            = ;     |
 |------------------>|(11)CCR(termination, = U-S-U(Service-Id(access)),
 |         &n= bsp;         = |            = ;   U-S-U(RG1, Service-Id 3), |
 |         &n= bsp;         = |            = ;   U-S-U(RG1, Service-Id 1), |
 |         &n= bsp;         = |---------------------------------------->|

Flow example with explicit sub-sessions:
End-User         &= nbsp; (CC = client)           = ;            = ;       CC Server
 |(1)User logon      = |            = ;            = ;            = ;     |
 |------------------>|(2)CCR(initial, = Service-Id(access))      |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(3)CCA(Granted-Units(Time),       &n= bsp;      |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 1,       |
 |         &n= bsp;         = |            = ;         Service-Id = 2,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 1),     |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 3,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 2),     |
 |         &n= bsp;         = |       Granted-Units(Rating-Group = 2,     |
 |         &n= bsp;         = |            = ;         Service-Id = 4,       |
 |         &n= bsp;         = |            = ;         Service-Id = 5,       |
 |         &n= bsp;         = |            = ;         Credit-Pool = 3))     |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(4)Service-Request (Service = 1)           &nbs= p;           &nbs= p;       |
 |------------------>|(5)CCR(initial,sub-session = 1,            = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1,   |
 |         &n= bsp;         = |            = ;           = Service-Id 1))    |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(6)CCA(Granted-Units(Rating-Group 1,     |
 |         &n= bsp;         = |            = ;         Service-Id = 1,       |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(7)Service-Request (Service = 3)           &nbs= p;           &nbs= p;       |
 |------------------>|(8)CCR(initial,sub-session = 2,            = |
 |         &n= bsp;         = |       Requested-Units(Rating-Group = 1,   |
 |         &n= bsp;         = |            = ;           = Service-Id 3))    |
 |         &n= bsp;         = |---------------------------------------->|
 |         &n= bsp;         = |(9)CCA(Granted-Units(Rating-Group 1,     |
 |       &nbs= p;           = |            = ;         Service-Id = 3,       |
 |         &n= bsp;         = |            = ;         = Total-Octets))      |
 |         &n= bsp;         = |<----------------------------------------|
 :         &n= bsp;         = :            = ;            = ;            = ;     :
 |(10)User logoff    = |            = ;            = ;            = ;     |
 |------------------>|(11)CCR(termination, = U-S-U(Service-Id(access)),
 |         &n= bsp;         = |            = ;   U-S-U(RG1, Service-Id 3), |
 |         &n= bsp;         = |            = ;   U-S-U(RG1, Service-Id 1)) |
 |         &n= bsp;         = |---------------------------------------->|

------_=_NextPart_001_01C3E4F0.8D98FDE6-- From aaa-admin@ietf.org Tue Jan 27 19:09:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02406 for ; Tue, 27 Jan 2004 19:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldFj-0000dQ-Kw; Tue, 27 Jan 2004 19:08:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlC0o-0001pS-SG for aaa@optimus.ietf.org; Mon, 26 Jan 2004 14:03:06 -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 OAA16230 for ; Mon, 26 Jan 2004 14:03:04 -0500 (EST) From: sweepstakelotto@netscape.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlC0m-0006Mm-00 for aaa@ietf.org; Mon, 26 Jan 2004 14:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlBzp-0006Kv-00 for aaa@ietf.org; Mon, 26 Jan 2004 14:02:05 -0500 Received: from 106.red-80-35-172.pooles.rima-tde.net ([80.35.172.106] helo=WINDOWS-K7VM2) by ietf-mx with esmtp (Exim 4.12) id 1AlBzh-0006J0-00 for aaa@ietf.org; Mon, 26 Jan 2004 14:01:57 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: sweepstakelotto@netscape.net Date: Mon, 26 Jan 2004 20:02:19 +0100 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail 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.2 required=5.0 tests=AWL,LINES_OF_YELLING, MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2,NO_REAL_NAME, PLING_PLING,SUBJ_ALL_CAPS,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.3 PLING_PLING Subject has lots of exclamation marks * 0.0 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] WINNING NOTIFICATION!!!(CONGRATULATION). 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: , ELGORDO LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,117 MADRID - ESPANA. TEL:0034 696 026 500 FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: EGS/JRG 7540876/01 BATCH: SLP280097/1MD RE: AWARD NOTIFICATION FINAL NOTICE. We are pleased to inform you of the announcement,of winners of the end of year LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMMES held on 2OTH December,2003. Your name is attached to ticket number 01-11-15-29-with serial number-0187654 drew the lucky numbers 3-11-20-24-37-44, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of €1,735,810.00(One Million Seven Hundred And Thirty Five Thousand Eight Hundred And Ten Euros Zero Cents Only) in cash credited to file Ref:No:EGS/JRG7540876/01 This is from total prize money of €31,244,580.00(Thirty One Million Two Hundred And Fourty-Four Thousand Five Hundred And Eighty Euros And Zero Cents Only) shared among the Eighteen international winners in this category. CONGRATULATION !!. Your fund is now deposited with a security company insured to your name. Due to the mixed up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your nominated account.This is part of our security protocol to avoid double claiming or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from 32,000 names from America,Asia, Australia,New Zealand, Europe and North America,as part of International Promotions Programme, which we conduct once every last month of the year.We hope that with a part of your prize,you will take part in our next year US$1.9Billion International lottery Program.CONGRATULATIONS!!! To begin your winning prize, please contact your claims agent,Foreign Operations Manager Mr JOSE MARIA GONZALEZ (Operations Manager) SANTA LUZ SEGUROS S.A on Tel:+34 654 023 046, Fax:+34 645 497 693 Email:( claimsagentgonzalez@netster.com) For due processing and remittance of your prize money to a designated account.Remember, all prize money must be claimed not later than 27th February 2004. After this date all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every correspondences with us or your claims agent. Furthermore, should there be any change of your address,do inform your claims agent as soon as possible.Congratulations once again from all our staff and thank you for being part of our promotions programme. Sincerely, CARLOS FERNANDO . _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Jan 27 19:37:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05375 for ; Tue, 27 Jan 2004 19:37: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 1AldhH-0006qz-VH for aaa-archive@odin.ietf.org; Tue, 27 Jan 2004 19:36:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0ale4026345 for aaa-archive@odin.ietf.org; Tue, 27 Jan 2004 19:36:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldhH-0006qq-SU for aaa-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:36:47 -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 TAA05330 for ; Tue, 27 Jan 2004 19:36:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldhG-0002Ao-00 for aaa-web-archive@ietf.org; Tue, 27 Jan 2004 19:36:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AldeL-0001TP-00 for aaa-web-archive@ietf.org; Tue, 27 Jan 2004 19:33:45 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRg-00062U-Ha for aaa-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldFj-0000dQ-Kw; Tue, 27 Jan 2004 19:08:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlC0o-0001pS-SG for aaa@optimus.ietf.org; Mon, 26 Jan 2004 14:03:06 -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 OAA16230 for ; Mon, 26 Jan 2004 14:03:04 -0500 (EST) From: sweepstakelotto@netscape.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlC0m-0006Mm-00 for aaa@ietf.org; Mon, 26 Jan 2004 14:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlBzp-0006Kv-00 for aaa@ietf.org; Mon, 26 Jan 2004 14:02:05 -0500 Received: from 106.red-80-35-172.pooles.rima-tde.net ([80.35.172.106] helo=WINDOWS-K7VM2) by ietf-mx with esmtp (Exim 4.12) id 1AlBzh-0006J0-00 for aaa@ietf.org; Mon, 26 Jan 2004 14:01:57 -0500 To: aaa@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: sweepstakelotto@netscape.net Date: Mon, 26 Jan 2004 20:02:19 +0100 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail 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.2 required=5.0 tests=AWL,LINES_OF_YELLING, MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2,NO_REAL_NAME, PLING_PLING,SUBJ_ALL_CAPS,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.3 PLING_PLING Subject has lots of exclamation marks * 0.0 AWL AWL: Auto-whitelist adjustment Subject: [Aaa] WINNING NOTIFICATION!!!(CONGRATULATION). 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: , ELGORDO LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,117 MADRID - ESPANA. TEL:0034 696 026 500 FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: EGS/JRG 7540876/01 BATCH: SLP280097/1MD RE: AWARD NOTIFICATION FINAL NOTICE. We are pleased to inform you of the announcement,of winners of the end of year LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMMES held on 2OTH December,2003. Your name is attached to ticket number 01-11-15-29-with serial number-0187654 drew the lucky numbers 3-11-20-24-37-44, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of €1,735,810.00(One Million Seven Hundred And Thirty Five Thousand Eight Hundred And Ten Euros Zero Cents Only) in cash credited to file Ref:No:EGS/JRG7540876/01 This is from total prize money of €31,244,580.00(Thirty One Million Two Hundred And Fourty-Four Thousand Five Hundred And Eighty Euros And Zero Cents Only) shared among the Eighteen international winners in this category. CONGRATULATION !!. Your fund is now deposited with a security company insured to your name. Due to the mixed up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your nominated account.This is part of our security protocol to avoid double claiming or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from 32,000 names from America,Asia, Australia,New Zealand, Europe and North America,as part of International Promotions Programme, which we conduct once every last month of the year.We hope that with a part of your prize,you will take part in our next year US$1.9Billion International lottery Program.CONGRATULATIONS!!! To begin your winning prize, please contact your claims agent,Foreign Operations Manager Mr JOSE MARIA GONZALEZ (Operations Manager) SANTA LUZ SEGUROS S.A on Tel:+34 654 023 046, Fax:+34 645 497 693 Email:( claimsagentgonzalez@netster.com) For due processing and remittance of your prize money to a designated account.Remember, all prize money must be claimed not later than 27th February 2004. After this date all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every correspondences with us or your claims agent. Furthermore, should there be any change of your address,do inform your claims agent as soon as possible.Congratulations once again from all our staff and thank you for being part of our promotions programme. Sincerely, CARLOS FERNANDO . _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Jan 28 03:08: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 DAA18592 for ; Wed, 28 Jan 2004 03:08:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 793AF91206; Wed, 28 Jan 2004 03:08:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFF8D91207; Wed, 28 Jan 2004 03:08: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 D8F8E91206 for ; Wed, 28 Jan 2004 03:07:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7EC15DDCA; Wed, 28 Jan 2004 03:07:56 -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 CB28F5DDBB for ; Wed, 28 Jan 2004 03:07:55 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0S87oqY002200; Wed, 28 Jan 2004 09:07:50 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 09:07:53 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "Leena Mattila (TU/LMF)" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'juha-pekka.koskinen@nokia.com'" , Christopher Richards , Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Wed, 28 Jan 2004 09:07:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Mark, To answer right things, I would like to ask first from you a few questions to be sure that I have read your scenario in right way. I assume that you would like to have solution, where: CCR[intial] is used to open and reserve units for main session as well as for sub-session(s). Then the CCA[intial] carries G-S-U for main session and sub-session(s). CCR[terminate] closes and reports units related both the main session and sub-session(s), right? I've understood that one credit pool would correspond to one independent quota. i.e. with one CCR one would report used units for one credit pool. Do you mean that there could be several credit pools within one sub-session? I.e. what's your definition for 'independent quota', one service, one pool(account) or one (sub)-session, or something else? Regards............Harri -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 27. tammikuuta 2004 18:14 To: Harri Hakala (TU/LMF); 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Christopher Richards; Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on HI Harri, Ok, so you flows show no actual units being provided to the client in the answer to the initial request. So the client is just learning the Service/Rating-Group <> Credit Pool mapping at this stage. Then it handles each Credit Pool in a separate sub-session. Would it also be possible to return actual Service Units in this initial response ? How are those then 'transferred' into the new per Credit Pool sub-sessions ? I'm thinking of the case where the client does not indicate the required Service/Rating-Groups to the server until they are actually used. And it has no information about Service/Rating <> Credit Pool mapping when it requests the units. I wasn't sure why you would need a separate CC state machine for each credit pool - presumably we can shut off/redirect traffic within one credit pool without closing the (sub-)session by returning zero units and attaching the appropriate redirect AVPs etc. to the G-S-U, right ? Regards...Mark From owner-aaa-wg@merit.edu Wed Jan 28 04:04: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 EAA21624 for ; Wed, 28 Jan 2004 04:04:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC15C91209; Wed, 28 Jan 2004 04:04:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A00319120A; Wed, 28 Jan 2004 04:04: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 610F691209 for ; Wed, 28 Jan 2004 04:04:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51D725DDC1; Wed, 28 Jan 2004 04:04: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 5B8E35DDA2 for ; Wed, 28 Jan 2004 04:04: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 i0S94JV22273 for ; Wed, 28 Jan 2004 11:04:19 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 10:52:37 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 10:52:28 +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]: Issue 14: DCC typing issues Date: Wed, 28 Jan 2004 10:52:29 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612236D@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC typing issues Thread-Index: AcPk6vX+3w5YbbskTBOsCj+dv21hFwAjosAg From: To: , X-OriginalArrivalTime: 28 Jan 2004 08:52:28.0708 (UTC) FILETIME=[0F033640:01C3E57C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Harri Hakala wrote: >=20 > > - 8.24: Service-Parameter-Type should probably specify how these > > values are allocated, or who is responsible for selecting them=20 > > (and ensuring that they are unique within some context). > Yes, that is intention. The previous AVP, 8.23=20 > Service-Parameter-Info AVP, defines: > ....The Service-Parameter-Type AVP defines the service parameter=20 > type and the Service-Parameter-Value AVP contains the=20 > parameter value.=20 > The actual contents of these AVPs are not within the scope of this=20 > document and SHOULD be defined in another Diameter application,=20 > standards written by other standardization bodies, or service=20 > specific documentation..... >=20 > Is this enough, or do you think that we need more specific statements > how to values of Service-Parameter-Type should be specified? I think we need something more... the values of Service-Parameter-Type=20 need to be unique within some context (if they don't, the value is=20 probably unnecessary?) If we just say that the values are defined in=20 "some other document", two documents could use the same value for completely different types of Service-Parameter-Value contents. I guess the relevant question here is how widely the mapping from Service-Parameter-Type values to Service-Parameter-Value types=20 needs to be unique. If we want global uniqueness, IANA allocation=20 (perhaps on First Come First Served basis) would be a good idea. But perhaps uniqueness within Service-Identifier is enough? (In that case, we should say so; meaning that whoever assigns a = Service-Identifier is also responsible for assigning Service-Parameter-Type values for that service and ensuring their uniqueness.) Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jan 28 04:14: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 EAA21837 for ; Wed, 28 Jan 2004 04:14:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79BF49120A; Wed, 28 Jan 2004 04:14:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D6769120D; Wed, 28 Jan 2004 04:14: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 F29FE9120A for ; Wed, 28 Jan 2004 04:14:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF4635DDD3; Wed, 28 Jan 2004 04:14:07 -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 3FB1E5DDD2 for ; Wed, 28 Jan 2004 04:14:07 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0S9E1qY019316; Wed, 28 Jan 2004 10:14:06 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 10:14:02 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 14: DCC typing issues Date: Wed, 28 Jan 2004 10:13:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pasi, > But perhaps uniqueness within Service-Identifier is enough? (In that > case, we should say so; meaning that whoever assigns a > Service-Identifier > is also responsible for assigning Service-Parameter-Type values > for that service and ensuring their uniqueness.) I think this is good principle. We will update the Service-Parameter-Type AVP according to your suggestion. Thanks.......Harri From owner-aaa-wg@merit.edu Wed Jan 28 05:56: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 FAA24840 for ; Wed, 28 Jan 2004 05:56:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13C8C9120D; Wed, 28 Jan 2004 05:56:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDD9C9120E; Wed, 28 Jan 2004 05: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 B33C79120D for ; Wed, 28 Jan 2004 05:55:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99CA95DDE3; Wed, 28 Jan 2004 05:55:59 -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 EB28C5DDE9 for ; Wed, 28 Jan 2004 05:55:58 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0SAtvYG027162; Wed, 28 Jan 2004 11:55:57 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 11:56:01 +0100 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 14: DCC typing issues Date: Wed, 28 Jan 2004 11:55:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pasi, thanks for the comments. See the answer for the IP address part below. BR, Leena > - 8.17: Should specify whether IPv4/IPv6 addresses are just > octets or textual representation (and for IPv6, which > textual representation). > The IP address itself is carried in the Redirect-Server-Address AVP which is of type UTF8String. So, it will be the textual representation that will be used. The Redirect-Address-Type AVP just specifies whether the UTF8String contains an IP address, URL or SIP URI. However, I agree, there is room for clarification in the description as you pointed out. Would the following make it clearer? Section 8.17 FROM: The address type can be one of the following: IPv4 Address 0 The address type is in form of IPv4 address, as defined in [RFC 791]. IPv6 Address 1 The address type is in form of IPv6 address, as defined in [RFC 2373]. TO: The address type can be one of the following: IPv4 Address 0 The address type is in form of "dotted-decimal" IPv4 address, as defined in [IPv4]. IPv6 Address 1 The address type is in form of IPv6 address, as defined in [IPv6Addr]. The address is a text representation of the address in either the preferred or alternate text form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support the alternate text form for IPv6 addresses. Section 15.1 ADD: [IPv4] J. Postel. "Internet Protocol", STD 5, RFC 791, September 1981. [IPv6Addr] R. Hinden, S. Deering. "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. From owner-aaa-wg@merit.edu Wed Jan 28 07:07: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 HAA27328 for ; Wed, 28 Jan 2004 07:07:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7DC3591210; Wed, 28 Jan 2004 07:07:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51B4B9120F; Wed, 28 Jan 2004 07:07: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 5648F91210 for ; Wed, 28 Jan 2004 07:07:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 337A25DDFA; Wed, 28 Jan 2004 07:07: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 7C2E35DE0A for ; Wed, 28 Jan 2004 07:07:36 -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 i0SC7TQ24537; Wed, 28 Jan 2004 12:07:29 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jan 2004 12:07:30 -0000 Message-ID: From: "Mark Watson" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'Patrik Teppo (KA/EAB)'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Wed, 28 Jan 2004 12:07:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E597.48C5238C" 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_01C3E597.48C5238C Content-Type: text/plain Hi Harri, I am thinking of the case where the client requests units for several Rating-Groups in a single CCR[initial] for the session and the server determines that these groups cannot share a single pool of credit. You show this in your flow, but you do not show any actual *units* being returns in the CCA[initial] - just the information about which Rating-Group goes with which Credit-Pool. So, then it is necessary for the client to make a new sub-session for each Credit-Pool. The question is whether units for all these Rating-Groups can be returned in the CCA[initial] ? And if these units are returned, do they continue to be managed within the main session, or are they 'transferred' to separate sub-sessions for each credit pool. In my understanding a 'quota' is a unit of granularity corresponding to a bundle of identially metered and rated services (i.e. a Rating-Group). Clearly it is desirable that the credit used by multiple such bundles of services is pooled to avoid credit fragmentation. Equally clearly, the separate bundles of services need to be handled independently in terms of termination/redirect action etc. As a preference, I would have these handled independently in terms of re-authorisation and addition of new services. Although the draft allows for re-authorisation without service interruption, some of our customers see this as a fraud window and would like to drop/buffer packets during re-authorisation. Finally, the association of Rating-Groups into credit pools needs to be under control of the server, not the client. Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' AVP(s) is what we need to work out - I don't have a strong opinion about that as long as it works, but we will make a concrete proposal as promised. Regards...Mark -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: 28 January 2004 08:07 To: Watson, Mark [MOP:EP10:EXCH]; 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Mark, To answer right things, I would like to ask first from you a few questions to be sure that I have read your scenario in right way. I assume that you would like to have solution, where: CCR[intial] is used to open and reserve units for main session as well as for sub-session(s). Then the CCA[intial] carries G-S-U for main session and sub-session(s). CCR[terminate] closes and reports units related both the main session and sub-session(s), right? I've understood that one credit pool would correspond to one independent quota. i.e. with one CCR one would report used units for one credit pool. Do you mean that there could be several credit pools within one sub-session? I.e. what's your definition for 'independent quota', one service, one pool(account) or one (sub)-session, or something else? Regards............Harri -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 27. tammikuuta 2004 18:14 To: Harri Hakala (TU/LMF); 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Christopher Richards; Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on HI Harri, Ok, so you flows show no actual units being provided to the client in the answer to the initial request. So the client is just learning the Service/Rating-Group <> Credit Pool mapping at this stage. Then it handles each Credit Pool in a separate sub-session. Would it also be possible to return actual Service Units in this initial response ? How are those then 'transferred' into the new per Credit Pool sub-sessions ? I'm thinking of the case where the client does not indicate the required Service/Rating-Groups to the server until they are actually used. And it has no information about Service/Rating <> Credit Pool mapping when it requests the units. I wasn't sure why you would need a separate CC state machine for each credit pool - presumably we can shut off/redirect traffic within one credit pool without closing the (sub-)session by returning zero units and attaching the appropriate redirect AVPs etc. to the G-S-U, right ? Regards...Mark ------_=_NextPart_001_01C3E597.48C5238C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussi on

Hi Harri,

I am thinking of the case where the client requests = units for several Rating-Groups in a single CCR[initial] for the = session and the server determines that these groups cannot share a = single pool of credit.

You show this in your flow, but you do not show any = actual *units* being returns in the CCA[initial] - just the information = about which Rating-Group goes with which Credit-Pool.

So, then it is necessary for the client to make a new = sub-session for each Credit-Pool.

The question is whether units for all these = Rating-Groups can be returned in the CCA[initial] ? And if these units = are returned, do they continue to be managed within the main session, = or are they 'transferred' to separate sub-sessions for each credit = pool.

In my understanding a 'quota' is a unit of = granularity corresponding to a bundle of identially metered and rated = services (i.e. a Rating-Group). Clearly it is desirable that the credit = used by multiple such bundles of services is pooled to avoid credit = fragmentation.

Equally clearly, the separate bundles of services = need to be handled independently in terms of termination/redirect = action etc.

As a preference, I would have these handled = independently in terms of re-authorisation and addition of new = services. Although the draft allows for re-authorisation without = service interruption, some of our customers see this as a fraud window = and would like to drop/buffer packets during = re-authorisation.

Finally, the association of Rating-Groups into credit = pools needs to be under control of the server, not the client.

Now, how this maps to sessions, sub-sessions and any = new 'Credit-Pool' AVP(s) is what we need to work out - I don't have a = strong opinion about that as long as it works, but we will make a = concrete proposal as promised.

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: 28 January 2004 08:07
To: Watson, Mark [MOP:EP10:EXCH]; = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Richards, Christopher = [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


Hi Mark,

To answer right things, I would like to ask first = from you
a few questions to be sure that I have read your = scenario
in right way.

I assume that you would like to have solution, = where:

CCR[intial] is used to open and reserve units for = main
session as well as for sub-session(s). Then the = CCA[intial] carries G-S-U for main session and sub-session(s).
CCR[terminate] closes and reports units related both = the
main session and sub-session(s), right?

I've understood that one credit pool would correspond = to one
independent quota. i.e. with one CCR one would = report used
units for one credit pool.
Do you mean that there could be several credit pools = within one sub-session? I.e. what's your definition for 'independent = quota', one service, one pool(account) or one (sub)-session, or = something

else?

Regards............Harri

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
Sent: 27. tammikuuta 2004 18:14
To: Harri Hakala (TU/LMF); = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Christopher Richards; Javier Gonzalez = Gallego

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


HI Harri,
Ok, so you flows show no actual units being provided = to the client in the answer to the initial request. So the client is = just learning the Service/Rating-Group <> Credit Pool mapping at = this stage. Then it handles each Credit Pool in a separate sub-session. = Would it also be possible to return actual Service Units in this = initial response ? How are those then 'transferred' into the new per = Credit Pool sub-sessions ? I'm thinking of the case where the client = does not indicate the required Service/Rating-Groups to the server = until they are actually used. And it has no information about = Service/Rating <> Credit Pool mapping when it requests the units. = I wasn't sure why you would need a separate CC state machine for each = credit pool - presumably we can shut off/redirect traffic within one = credit pool without closing the (sub-)session by returning zero units = and attaching the appropriate redirect AVPs etc. to the G-S-U, right ? = Regards...Mark

 

------_=_NextPart_001_01C3E597.48C5238C-- From owner-aaa-wg@merit.edu Wed Jan 28 09:04: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 JAA01329 for ; Wed, 28 Jan 2004 09:04:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C01BF91213; Wed, 28 Jan 2004 09:04:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E65C91216; Wed, 28 Jan 2004 09:04: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 BD2CE91213 for ; Wed, 28 Jan 2004 09:04:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E1105DD9A; Wed, 28 Jan 2004 09:04:29 -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 C64A65DDB7 for ; Wed, 28 Jan 2004 09:04:28 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0SE4RqY027028; Wed, 28 Jan 2004 15:04:27 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 15:04:31 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "Leena Mattila (TU/LMF)" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'juha-pekka.koskinen@nokia.com'" , Christopher Richards , Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Wed, 28 Jan 2004 15:04:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Mark, >The question is whether units for all these Rating-Groups can be returned in the CCA[initial] ? >And if these units are returned, do they continue to be managed within the main session, or are >they 'transferred' to separate sub-sessions for each credit pool. The challenge may be how to 'transfer' each credit pool to sub-session. Basically sub-sessions are initiated and sub-session Ids are created by client, but in this case the server would implicitly open sub-sessions with Answer message. But It would be rather difficult also handle several credit pools within one session. >I wasn't sure why you would need a separate CC state machine for each credit >pool - presumably we can shut off/redirect traffic within one credit pool without >closing the (sub-)session by returning zero units and attaching the appropriate >redirect AVPs etc. to the G-S-U, right ? If there is a need to report used units per credit pool within one (sub)-session, and there are several credit pools in the (sub)-session, then on reason is the failure handling, another reason is that when in the session you are in pending state waiting for an answer you cannot send a new CCR[update]) until the session move to open state (i.e. until the answer is received). This means that if a credit-pool need to be re-authorized while another credit-pool re-authorization is ongoing, you cannot do it in real-time and you need to queue the request. What happen if the answer is delayed for some reason? If you really want to treat the pools independently, than you need an instance of the DCC state machine for each credit pool. >Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' AVP(s) is >what we need to work out - I don't have a strong opinion about that as long as it >works, but we will make a concrete proposal as promised. I think it will be easier to discuss this and provide comments once we have seen your proposal. Regards........Harri -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 28. tammikuuta 2004 14:07 To: Harri Hakala (TU/LMF); 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Christopher Richards; Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Harri, I am thinking of the case where the client requests units for several Rating-Groups in a single CCR[initial] for the session and the server determines that these groups cannot share a single pool of credit. You show this in your flow, but you do not show any actual *units* being returns in the CCA[initial] - just the information about which Rating-Group goes with which Credit-Pool. So, then it is necessary for the client to make a new sub-session for each Credit-Pool. The question is whether units for all these Rating-Groups can be returned in the CCA[initial] ? And if these units are returned, do they continue to be managed within the main session, or are they 'transferred' to separate sub-sessions for each credit pool. In my understanding a 'quota' is a unit of granularity corresponding to a bundle of identially metered and rated services (i.e. a Rating-Group). Clearly it is desirable that the credit used by multiple such bundles of services is pooled to avoid credit fragmentation. Equally clearly, the separate bundles of services need to be handled independently in terms of termination/redirect action etc. As a preference, I would have these handled independently in terms of re-authorisation and addition of new services. Although the draft allows for re-authorisation without service interruption, some of our customers see this as a fraud window and would like to drop/buffer packets during re-authorisation. Finally, the association of Rating-Groups into credit pools needs to be under control of the server, not the client. Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' AVP(s) is what we need to work out - I don't have a strong opinion about that as long as it works, but we will make a concrete proposal as promised. Regards...Mark From owner-aaa-wg@merit.edu Wed Jan 28 09:53: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 JAA02583 for ; Wed, 28 Jan 2004 09:53:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0DB691212; Wed, 28 Jan 2004 09:52:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88DDC91214; Wed, 28 Jan 2004 09:52: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 8D70591212 for ; Wed, 28 Jan 2004 09:52:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EF345DDB3; Wed, 28 Jan 2004 09:52:53 -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 8A0585DDCC for ; Wed, 28 Jan 2004 09:52:52 -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 i0SEqjG10293; Wed, 28 Jan 2004 14:52:45 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jan 2004 14:52:45 -0000 Message-ID: From: "Mark Watson" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'Patrik Teppo (KA/EAB)'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Wed, 28 Jan 2004 14:52:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E5AE.62A67172" 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_01C3E5AE.62A67172 Content-Type: text/plain Hi Harri, Thanks for the continued clarifications... You wrote: >I think it will be easier to discuss this and provide comments once we have seen your proposal. However, I am trying to modify our proposal to accommodate the opinions expressed in this discussion, so if I may, I will ask one further question: Is to your opinion that in order to handle re-authorisation for separate Rating-Groups independently then separate sub-sessions/state machines are needed (either client or server initiated) ? Is the same true if I want to provide different handling on credit exhaustion - for example one Rating-Group is terminated, another redirected and a further one allowed to continue 'into the red'. Both the above are assuming that the separate Rating-Groups all draw from the same credit pool. Regards...Mark -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: 28 January 2004 14:04 To: Watson, Mark [MOP:EP10:EXCH]; 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Mark, >The question is whether units for all these Rating-Groups can be >returned in the CCA[initial] ? And if these units are returned, do they >continue to be managed within the main session, or are they >'transferred' to separate sub-sessions for each credit pool. The challenge may be how to 'transfer' each credit pool to sub-session. Basically sub-sessions are initiated and sub-session Ids are created by client, but in this case the server would implicitly open sub-sessions with Answer message. But It would be rather difficult also handle several credit pools within one session. >I wasn't sure why you would need a separate CC state machine for each >credit pool - presumably we can shut off/redirect traffic within one >credit pool without closing the (sub-)session by returning zero units >and attaching the appropriate redirect AVPs etc. to the G-S-U, right ? If there is a need to report used units per credit pool within one (sub)-session, and there are several credit pools in the (sub)-session, then on reason is the failure handling, another reason is that when in the session you are in pending state waiting for an answer you cannot send a new CCR[update]) until the session move to open state (i.e. until the answer is received). This means that if a credit-pool need to be re-authorized while another credit-pool re-authorization is ongoing, you cannot do it in real-time and you need to queue the request. What happen if the answer is delayed for some reason? If you really want to treat the pools independently, than you need an instance of the DCC state machine for each credit pool. >Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' >AVP(s) is >what we need to work out - I don't have a strong opinion about that as long as it >works, but we will make a concrete proposal as promised. I think it will be easier to discuss this and provide comments once we have seen your proposal. Regards........Harri -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 28. tammikuuta 2004 14:07 To: Harri Hakala (TU/LMF); 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Christopher Richards; Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Harri, I am thinking of the case where the client requests units for several Rating-Groups in a single CCR[initial] for the session and the server determines that these groups cannot share a single pool of credit. You show this in your flow, but you do not show any actual *units* being returns in the CCA[initial] - just the information about which Rating-Group goes with which Credit-Pool. So, then it is necessary for the client to make a new sub-session for each Credit-Pool. The question is whether units for all these Rating-Groups can be returned in the CCA[initial] ? And if these units are returned, do they continue to be managed within the main session, or are they 'transferred' to separate sub-sessions for each credit pool. In my understanding a 'quota' is a unit of granularity corresponding to a bundle of identially metered and rated services (i.e. a Rating-Group). Clearly it is desirable that the credit used by multiple such bundles of services is pooled to avoid credit fragmentation. Equally clearly, the separate bundles of services need to be handled independently in terms of termination/redirect action etc. As a preference, I would have these handled independently in terms of re-authorisation and addition of new services. Although the draft allows for re-authorisation without service interruption, some of our customers see this as a fraud window and would like to drop/buffer packets during re-authorisation. Finally, the association of Rating-Groups into credit pools needs to be under control of the server, not the client. Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' AVP(s) is what we need to work out - I don't have a strong opinion about that as long as it works, but we will make a concrete proposal as promised. Regards...Mark ------_=_NextPart_001_01C3E5AE.62A67172 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussi on

Hi Harri,

Thanks for the continued clarifications...

You wrote:
>I think it will be easier to discuss this and = provide comments once we have seen your proposal.

However, I am trying to modify our proposal to = accommodate the opinions expressed in this discussion, so if I may, I = will ask one further question:

Is to your opinion that in order to handle = re-authorisation for separate Rating-Groups independently then separate = sub-sessions/state machines are needed (either client or server = initiated) ?

Is the same true if I want to provide different = handling on credit exhaustion - for example one Rating-Group is = terminated, another redirected and a further one allowed to continue = 'into the red'.

Both the above are assuming that the separate = Rating-Groups all draw from the same credit pool.

Regards...Mark


-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: 28 January 2004 14:04
To: Watson, Mark [MOP:EP10:EXCH]; = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Richards, Christopher = [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


Hi Mark,

>The question is whether units for all these = Rating-Groups can be
>returned in the CCA[initial] ? And if these = units are returned, do they
>continue to be managed within the main session, = or are they
>'transferred' to separate sub-sessions for each = credit pool.
The challenge may be how to 'transfer' each credit = pool to sub-session. Basically sub-sessions are initiated and = sub-session Ids are created by client, but in this case the server = would implicitly open sub-sessions with Answer message. But It would be = rather difficult also handle several credit pools within one = session.

>I wasn't sure why you would need a separate CC = state machine for each
>credit pool - presumably we can shut = off/redirect traffic within one
>credit pool without closing the (sub-)session by = returning zero units
>and attaching the appropriate redirect AVPs etc. = to the G-S-U, right ?
If there is a need to report used units per credit = pool within one (sub)-session, and there are several credit pools in = the (sub)-session, then on reason is the failure handling, another = reason is that when in the session you are in pending state waiting for = an answer you cannot send a new CCR[update]) until the session move to = open state (i.e. until the answer is received). This means that if a = credit-pool need to be re-authorized while

another credit-pool re-authorization is ongoing, you = cannot do it in real-time and you need to queue the request. What = happen if the answer is delayed for some reason? If you really want to = treat the pools independently, than you need an instance of the DCC = state machine for each credit pool.

>Now, how this maps to sessions, sub-sessions and = any new 'Credit-Pool'
>AVP(s) is
>what we need to work out - I don't have a strong = opinion about that as long as it
>works, but we will make a concrete proposal as = promised.
I think it will be easier to discuss this and = provide comments once we have seen your proposal.

Regards........Harri


-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
Sent: 28. tammikuuta 2004 14:07
To: Harri Hakala (TU/LMF); = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Christopher Richards; Javier Gonzalez = Gallego

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


Hi Harri,
I am thinking of the case where the client requests = units for several Rating-Groups in a single CCR[initial] for the = session and the server determines that these groups cannot share a = single pool of credit. You show this in your flow, but you do not show = any actual *units* being returns in the CCA[initial] - just the = information about which Rating-Group goes with which Credit-Pool. So, = then it is necessary for the client to make a new sub-session for each = Credit-Pool.

The question is whether units for all these = Rating-Groups can be returned in the CCA[initial] ? And if these units = are returned, do they continue to be managed within the main session, = or are they 'transferred' to separate sub-sessions for each credit = pool. In my understanding a 'quota' is a unit of granularity = corresponding to a bundle of identially metered and rated services = (i.e. a Rating-Group). Clearly it is desirable that the credit used by = multiple such bundles of services is pooled to avoid credit = fragmentation. Equally clearly, the separate bundles of services need = to be handled independently in terms of termination/redirect action = etc. As a preference, I would have these handled independently in terms = of re-authorisation and addition of new services. Although the draft = allows for re-authorisation without service interruption, some of our = customers see this as a fraud window and would like to drop/buffer = packets during re-authorisation. Finally, the association of = Rating-Groups into credit pools needs to be under control of the = server, not the client.

Now, how this maps to sessions, sub-sessions and any = new 'Credit-Pool' AVP(s) is what we need to work out - I don't have a = strong opinion about that as long as it works, but we will make a = concrete proposal as promised. Regards...Mark

 

------_=_NextPart_001_01C3E5AE.62A67172-- From owner-aaa-wg@merit.edu Wed Jan 28 12:08: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 MAA13278 for ; Wed, 28 Jan 2004 12:08:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D3219125D; Wed, 28 Jan 2004 12:04:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0ED491249; Wed, 28 Jan 2004 12:04: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 9B5D29125D for ; Wed, 28 Jan 2004 12:03:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 84FCB5DD95; Wed, 28 Jan 2004 12:03:55 -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 D10F45DDA4 for ; Wed, 28 Jan 2004 12:03:49 -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 i0SH3g601459 for ; Wed, 28 Jan 2004 17:03:42 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jan 2004 17:03:42 -0000 Message-ID: From: "Mark Watson" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Issue: Unnecessary service assumptions Date: Wed, 28 Jan 2004 17:03:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E5C0.AD845BC0" 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_01C3E5C0.AD845BC0 Content-Type: text/plain ...not the one you are waiting for - this in uncontraversial, I hope. ...Mark 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'. 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 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. - 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_01C3E5C0.AD845BC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Issue: Unnecessary service assumptions

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

...Mark


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'.


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

- 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_01C3E5C0.AD845BC0-- From owner-aaa-wg@merit.edu Wed Jan 28 13:55: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 NAA19848 for ; Wed, 28 Jan 2004 13:55:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E42B891225; Wed, 28 Jan 2004 13:55:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B409D91227; Wed, 28 Jan 2004 13:55: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 404F291225 for ; Wed, 28 Jan 2004 13:55:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 298F85DDDA; Wed, 28 Jan 2004 13:55:23 -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 DF0715DDCC for ; Wed, 28 Jan 2004 13:55:22 -0500 (EST) Received: from zrc2c010.us.nortel.com (zrc2c010.us.nortel.com [47.103.120.50]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0SItDl21787; Wed, 28 Jan 2004 12:55:13 -0600 (CST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c010.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C6CH4ZF0; Wed, 28 Jan 2004 12:55:14 -0600 Received: from nortelnetworks.com (harvell-3.us.nortel.com [47.102.209.53]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C0CLNTGH; Wed, 28 Jan 2004 12:55:14 -0600 Message-ID: <4018054D.1020302@nortelnetworks.com> Date: Wed, 28 Jan 2004 12:54:05 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell Organization: Nortel Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 StumbleUpon/1.89 X-Accept-Language: en MIME-Version: 1.0 To: mikko.aittola@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Client request routing References: <9B95641F3AE80F4C8CD5B288FE8C9631C1B239@esebe012.ntc.nokia.com> In-Reply-To: <9B95641F3AE80F4C8CD5B288FE8C9631C1B239@esebe012.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mikko: I have read this section. There is a good description of how request forwarding and routing work for Diameter Agents. However, a Diameter Client is not a Diameter Agent. I did find an example in section 2.8.2 that suggests that Diameter Clients performs a "routing lookup." The example provided in Figure 2 depicts a request issued from a NAS [Diameter Client], which is an access device, for the user bob@example.com. Prior to issuing th erequest, NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to DRL, which is a Diameter Relay. To me, this sounds like a Diameter Client following step 3 on page 72 in 6.1. However, this procedure describes how to process a received message; and this doesn't apply to messages originated by a Diameter Client. Also, the following description of request routing from 6.1 only applies to Diameter Agents: Note that an agent can forward a request to a host described in the Destination-Host AVP only if the host in question is included in its peer table (see Section 2.7). Otherwise, the request is routed based on the Destination-Realm only (see Sections 6.1.6). mikko.aittola@nokia.com wrote: > Hi, > > May I suggest reading also Section 6.1, 'Diameter Request Routing Overview'? :) > > It should be noted that according to the spec if Destination-Host matches > the value of Destination-Realm can be ignored. > > > BR, > Mikko > > > >>-----Original Message----- >>From: owner-aaa-wg@merit.edu >>[mailto:owner-aaa-wg@merit.edu]On Behalf Of >>ext Joe Harvell >>Sent: 19 January, 2004 21:13 >>To: aaa-wg@merit.edu >>Subject: [AAA-WG]: Diameter Client request routing >> >> >>I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based Routing >>Table), 5.1 (Peer Connections), and 5.2 (Diameter Peer >>Discovery) of Diameter Base Protocol, and I am a little >>confused about how a Diameter Peer is to be selected for >>sending a request from a Diameter Client. >> >>Consider the case of a Diameter Client that does not >>implement Diameter Peer Discovery. This means that Diameter >>Peers are statically configured. The Capabilities Exchange >>process will definitely identify the Realm and Host of each >>Diameter Peer. However, the only cases in which a peer can >>be identified as a candidate next hop for sending a >>particular request are as follows: >> >> 1) when its Realm matches the Destination-Realm of a >>message with Destination-Realm only; and >> 2) when its Realm and Host match the Destination-Realm >>and Destination-Host of a message with a Destination-Realm >>and Destination-Host. >> >>So how does a Diameter Client identify a candidate peer for >>sending messages in the other cases? >> >>Section 5.1 indicates that a Diameter Node should have >>established connections with a minimum of two (a primary and >>possibly multiple secondary) peers per realm. Does the >>"realm" in this context mean that both peers are members of >>the same realm, or that both peers can route messages to a >>given Destination-Realm? Can Diameter Agents forward >>requests for a Destination-Realm that is not their Realm? >> >>When a Diameter Client has a request with a Destination-Realm >>and Destination-Host, will all the primary and secondary >>peers described in 5.1 be able to route the request to that >>Destination-Host in that Destination-Realm? >> >>--- >>Joe Harvell >>Shasta GGSN Development >>Nortel Networks >>+1 972.685.4886 >> >> > > From aaa-admin@ietf.org Wed Jan 28 17:09:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02577 for ; Wed, 28 Jan 2004 17:09: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 1Alxrp-0005mP-AJ; Wed, 28 Jan 2004 17:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alxrd-0005lg-D4 for aaa@optimus.ietf.org; Wed, 28 Jan 2004 17:08: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 RAA02536 for ; Wed, 28 Jan 2004 17:08:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alxrb-000324-00 for aaa@ietf.org; Wed, 28 Jan 2004 17:08:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alxqh-0002x7-00 for aaa@ietf.org; Wed, 28 Jan 2004 17:07:51 -0500 Received: from ip3e830e13.speed.planet.nl ([62.131.14.19] helo=62.131.14.19) by ietf-mx with smtp (Exim 4.12) id 1Alxpv-0002s3-00 for aaa@ietf.org; Wed, 28 Jan 2004 17:07:03 -0500 From: lisa82@yahoo.com To: aaa@ietf.org Date: Thu, 29 Jan 2004 01:17:02 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C3E4EE.94DC22B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=8.9 required=5.0 tests=DATE_IN_FUTURE_06_12, FORGED_MUA_OUTLOOK,FORGED_YAHOO_RCVD,FROM_ENDS_IN_NUMS, MICROSOFT_EXECUTABLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 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 * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] here is the file you asked for 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_0022_01C3E4EE.94DC22B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hi, here is the file you asked for! ------=_NextPart_000_0022_01C3E4EE.94DC22B0 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document.txt.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0022_01C3E4EE.94DC22B0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Jan 28 18:05: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 SAA05728 for ; Wed, 28 Jan 2004 18:05:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6826991230; Wed, 28 Jan 2004 18:05:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35FC691232; Wed, 28 Jan 2004 18:05: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 0339591230 for ; Wed, 28 Jan 2004 18:05:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id E07585DDBA; Wed, 28 Jan 2004 18:05:07 -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 855185DDB1 for ; Wed, 28 Jan 2004 18:05:07 -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 i0SN54d13711 for ; Wed, 28 Jan 2004 15:05:05 -0800 (PST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXNNJM0V; Wed, 28 Jan 2004 17:05:05 -0600 Received: from nortelnetworks.com (harvell-3.us.nortel.com [47.102.209.53]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C0CLNTNZ; Wed, 28 Jan 2004 17:05:05 -0600 Message-ID: <40183FDF.7070408@nortelnetworks.com> Date: Wed, 28 Jan 2004 17:03:59 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell Organization: Nortel Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 StumbleUpon/1.89 X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: realm based routing table clarification 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 2.7 of "Diameter Base Protocol" says that each entry in the realm-based routing table contains (among other fields) a Server Identifier. The description actually says that this can be one or more servers the message is to be routed to. My question is, what identifies a server? Is it the value the server would send in the Origin-Host field in and CER messages it would send? Or is it a combination of the values it would send for Origin-Realm and Origin-Host? Another question: Are Diameter Host identifers (values sent in Origin-Host in CER messages) required/expected to be unique, or just unique within their Realm? From aaa-admin@ietf.org Wed Jan 28 19:13:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08509 for ; Wed, 28 Jan 2004 19:13:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alznn-00042s-Io; Wed, 28 Jan 2004 19:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alzne-00042Y-2x for aaa@optimus.ietf.org; Wed, 28 Jan 2004 19:12:50 -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 TAA08486 for ; Wed, 28 Jan 2004 19:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alznc-0007iU-00 for aaa@ietf.org; Wed, 28 Jan 2004 19:12:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alzme-0007cC-00 for aaa@ietf.org; Wed, 28 Jan 2004 19:11:48 -0500 Received: from 200-180-009-086.fnsce7006.dsl.brasiltelecom.net.br ([200.180.9.86] helo=200.180.9.86) by ietf-mx with smtp (Exim 4.12) id 1Alzkn-0007PC-00 for aaa@ietf.org; Wed, 28 Jan 2004 19:09:54 -0500 From: lisa82@delphi.com To: aaa@ietf.org Date: Thu, 29 Jan 2004 03:19:53 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C3E4EE.94DC22B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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=8.4 required=5.0 tests=DATE_IN_FUTURE_06_12, FORGED_MUA_OUTLOOK,FROM_ENDS_IN_NUMS,MICROSOFT_EXECUTABLE, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 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 * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Subject: [Aaa] here is the file you asked for 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_0022_01C3E4EE.94DC22B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hi, here is the file you asked for! ------=_NextPart_000_0022_01C3E4EE.94DC22B0 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document.txt.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0022_01C3E4EE.94DC22B0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Jan 29 02:48: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 CAA06854 for ; Thu, 29 Jan 2004 02:48:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0140F91248; Thu, 29 Jan 2004 02:48:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6CD19124F; Thu, 29 Jan 2004 02:48: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 35AF391248 for ; Thu, 29 Jan 2004 02:48:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BAB35DDBA; Thu, 29 Jan 2004 02:48:29 -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 AD0F55DDC5 for ; Thu, 29 Jan 2004 02:48:27 -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 i0T7mQ209692 for ; Thu, 29 Jan 2004 09:48:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 09:48:25 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 09:48:25 +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_01C3E63C.46356BB1" Subject: RE: [AAA-WG]: Issue: Unnecessary service assumptions Date: Thu, 29 Jan 2004 09:48:24 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03F1@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Unnecessary service assumptions Thread-Index: AcPlwcZ8BzMeio+HSYizkWVSTXUDvAAegoRQ From: To: Cc: X-OriginalArrivalTime: 29 Jan 2004 07:48:25.0709 (UTC) FILETIME=[46D1D9D0:01C3E63C] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E63C.46356BB1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 I agree with all the changes you propose. =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Mark Watson Sent: 28 January, 2004 19: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.=20 ...Mark=20 Description of issue: Unnecessary service assumptions=20 Submitter name: Mark Watson/Chris Richards=20 Date first submitted: 28.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 Section: Various=20 Rationale/Explanation of issues:=20 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'. Requested change:=20 - Section 5.5, first paragraph:=20 FROM:=20 When the user's account runs out of money the user must be denied to=20 compile additional chargeable events. However, the home service=20 provider may offer free access services, for instance access to a=20 service portal where it is possible to top-up the account, for which=20 the user is allowed to benefit for a limited amount of time. This = time=20 is usually dependant on the home service provider policy.=20 TO:=20 When the user's account runs out of money the user must be denied to=20 compile additional chargeable events. However, the home service=20 provider may offer some services, for instance access to a=20 service portal where it is possible to top-up the account, for which=20 the user is allowed to benefit for a limited amount of time. This = time=20 is usually dependant on the home service provider policy.=20 - Section 5.5, third paragraph:=20 FROM:=20 =20 In some service environments (e.g. NAS) the graceful service=20 termination may be used to redirect the subscriber to a service = portal=20 for online balance top-up or other zero-rated services offered by the = home service provider. In this case the graceful termination process=20 installs a set of packet filters to restrict the user's access=20 capability only to/from the specified destinations, all the IP = packets=20 not matching the filters will be dropped or possibly re-directed to=20 the service portal. The user may also be displayed an appropriate=20 notification why the access has been limited.=20 TO:=20 In some service environments (e.g. NAS) the graceful service=20 termination may be used to redirect the subscriber to a service = portal=20 for online balance top-up or other services offered by the=20 home service provider. In this case the graceful termination process=20 installs a set of packet filters to restrict the user's access=20 capability only to/from the specified destinations, all the IP = packets=20 not matching the filters will be dropped or possibly re-directed to=20 the service portal. The user may also be displayed an appropriate=20 notification why the access has been limited.=20 - Section 5.5.2, third paragraph:=20 FROM:=20 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-=20 Id AVP in the Credit-Control-Answer message in order to enable the=20 user to access other zero-rated services. In such a case the access=20 device MUST drop all the packets not matching the IP filters = specified=20 in the Credit-Control-Answer message and redirect the user to the=20 destination specified in the Redirect-Server AVP, if possible.=20 TO:=20 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-=20 Id AVP in the Credit-Control-Answer message in order to enable the=20 user to access other services (for example zero-rated services). In = such a=20 case the access device MUST drop all the packets not matching the IP=20 filters specified in the Credit-Control-Answer message and redirect = the=20 user to the destination specified in the Redirect-Server AVP, if = possible.=20 - Section 5.5.2, sixth paragraph:=20 FROM:=20 At the expiry of Validity-Time the credit control client sends a=20 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does=20 not include the Used-Service-Unit AVP since there is no allotted = quota=20 to report. The credit control server processes the request and MUST=20 perform the credit reservation. If during this time the subscriber = did=20 not replenish his/her account whether he/she will be disconnected or=20 will be granted access to zero-rated services for unlimited time is=20 dependent on the home service provider policy (note: the latter = option=20 implies that the service element should not remove the restriction=20 filters upon termination of the credit control session). The server=20 will return the appropriate Result-Code (see section 9.1) in the=20 Credit-Control-Answer message in order to close the credit control=20 session and implement the policy-defined action. Otherwise new quota=20 will be returned, the service element MUST remove all the possible=20 restrictions activated by the graceful service termination process = and=20 continue the credit control session and the service session as usual. = TO:=20 At the expiry of Validity-Time the credit control client sends a=20 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does=20 not include the Used-Service-Unit AVP since there is no allotted = quota=20 to report. The credit control server processes the request and MUST=20 perform the credit reservation. If during this time the subscriber = did=20 not replenish his/her account whether he/she will be disconnected or=20 will be granted access to services not controlled by the credit = control=20 server for unlimited time is dependent on the home service provider = policy=20 (note: the latter option implies that the service element should not = remove=20 the restriction filters upon termination of the credit control = session).=20 The server will return the appropriate Result-Code (see section 9.1) = in the=20 Credit-Control-Answer message in order to close the credit control=20 session and implement the policy-defined action. Otherwise new quota=20 will be returned, the service element MUST remove all the possible=20 restrictions activated by the graceful service termination process = and=20 continue the credit control session and the service session as usual. = - section 5.5.3, second paragraph:=20 FROM:=20 Another entity than the credit control server may provision the = access=20 device with appropriate IP packet filters to be used in conjunction=20 with the Diameter credit control application. Such an entity, for=20 instance, may configure the access device with "zero-rated" IP flows=20 that are to be passed when the Diameter credit control application=20 indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP=20 packets according to the filter rules possibly received in the = Credit-=20 Control-Answer message in addition to the filter rules possibly=20 configured by the other entity. However, the action to be taken when=20 the user's account cannot cover the cost of the requested service is=20 the responsibility of the credit control server that controls the=20 prepaid subscriber.=20 TO:=20 Another entity than the credit control server may provision the = access=20 device with appropriate IP packet filters to be used in conjunction=20 with the Diameter credit control application. Such an entity, for=20 example, may configure the access device with IP flows=20 that are to be passed when the Diameter credit control application=20 indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP=20 packets according to the filter rules possibly received in the = Credit-=20 Control-Answer message in addition to the filter rules possibly=20 configured by the other entity. However, the action to be taken when=20 the user's account cannot cover the cost of the requested service is=20 the responsibility of the credit control server that controls the=20 prepaid subscriber.=20 - Section 8.15, sixth paragraph:=20 FROM:=20 If the Final-Unit-Action AVP is set to REDIRECT at least the = Redirect-=20 Server AVP MUST be present. The Restriction-Filter-Rule AVP or the=20 Filter-Id AVP MAY be present in the Credit-Control-Answer message if=20 the user is allowed to access also other zero-rated services not=20 accessible through the address given in the Redirect-Server AVP.=20 TO:=20 If the Final-Unit-Action AVP is set to REDIRECT at least the = Redirect-=20 Server AVP MUST be present. The Restriction-Filter-Rule AVP or the=20 Filter-Id AVP MAY be present in the Credit-Control-Answer message if=20 the user is allowed to access also other services not=20 accessible through the address given in the Redirect-Server AVP.=20 - Section 8.16, fifth paragraph:=20 FROM:=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=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 FFFFFFFF to indicate free-of-charge.=20 TO:=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 usage of the corresponding traffic is = unlimited.=20 With unit type money, the value of the Exponent AVP is set to=20 0 (zero) when unlimited usage is indicated. With unit type service=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 FFFFFFFF to indicate unlimited usage.=20 - Section 8.22, first paragraph:=20 FROM:=20 The Restriction-Filter-Rule AVP (AVP Code 438) is of type = IPFilterRule=20 and provides filter rules corresponding to zero-rated services = offered=20 by the home service provider. The access device need to configure the = specified filter rules for the subscriber and MUST drop all the=20 packets not matching these filters. Zero, one or more such AVPs MAY = be=20 present in a Credit-Control-Answer message or in an AA answer = message.=20 TO:=20 The Restriction-Filter-Rule AVP (AVP Code 438) is of type = IPFilterRule=20 and provides filter rules corresponding to services which are to = remain=20 accessible despite there being no more service units granted. The = access=20 device need to configure the specified filter rules for the = subscriber and=20 MUST drop all the packets not matching these filters. Zero, one or = more=20 such AVPs MAY be present in a Credit-Control-Answer message or in an = AA=20 answer message.=20 - end of changes=20 ------_=_NextPart_001_01C3E63C.46356BB1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Issue: Unnecessary service assumptions
Hi=20 Mark,
 
I=20 agree with all the changes you propose.
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Mark=20 Watson
Sent: 28 January, 2004 19:04
To:=20 'aaa-wg@merit.edu'
Subject: [AAA-WG]: Issue: Unnecessary = service=20 assumptions

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

...Mark


Description of issue: Unnecessary service = assumptions=20
Submitter name: Mark Watson/Chris Richards =
Date first submitted: 28.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 ]
Section:=20 Various

Rationale/Explanation of issues:

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


Requested change:

- Section 5.5, first paragraph:

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


- Section 5.5, third paragraph:

FROM:

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

TO:

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

- Section 5.5.2, third paragraph:

FROM:

   In addition to the Redirect-Server AVP, = the=20 credit control server MAY
   = include one or=20 more Restriction-Filter-Rule AVP or one or more Filter- =
   Id AVP in the Credit-Control-Answer message in = order to=20 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=20 filters specified
   in the=20 Credit-Control-Answer message and redirect the user to the =
   destination specified in the Redirect-Server = AVP, if=20 possible.

TO:

   In addition to the Redirect-Server AVP, = the=20 credit control server MAY
   = include one or=20 more Restriction-Filter-Rule AVP or one or more Filter- =
   Id AVP in the Credit-Control-Answer message in = order to=20 enable the
   user to access other = services=20 (for example zero-rated services). In such a
   case the access device MUST drop all the packets = not=20 matching the IP
   filters = specified in the=20 Credit-Control-Answer message and redirect the
   user to the destination specified in the = Redirect-Server=20 AVP, if possible.

- Section 5.5.2, sixth paragraph:

FROM:

   At the expiry of Validity-Time the = credit control=20 client sends a
   = Credit-Control-Request=20 (UPDATE_REQUEST) as usual. This message does
   not include the Used-Service-Unit AVP since = there is no=20 allotted quota
   to report. The = credit=20 control server processes the request and MUST
   perform the credit reservation. If during this = time the=20 subscriber did
   not replenish = his/her=20 account whether he/she will be disconnected or
   will be granted access to zero-rated services = for=20 unlimited time is
   dependent on = the home=20 service provider policy (note: the latter option
   implies that the service element should not = remove the=20 restriction
   filters upon = termination of=20 the credit control session). The server
  =20 will return the appropriate Result-Code (see section 9.1) in the=20
   Credit-Control-Answer message = in order to=20 close the credit control
   = session and=20 implement the policy-defined action. Otherwise new quota =
   will be returned, the service element MUST = remove all the=20 possible
   restrictions activated = by the=20 graceful service termination process and
  =20 continue the credit control session and the service session as = usual.=20

TO:
   At the = expiry of=20 Validity-Time the credit control client sends a
   Credit-Control-Request (UPDATE_REQUEST) as = usual. This=20 message does
   not include the=20 Used-Service-Unit AVP since there is no allotted quota =
   to report. The credit control server processes = the request=20 and MUST
   perform the credit = reservation.=20 If during this time the subscriber did
  =20 not replenish his/her account whether he/she will be disconnected or=20
   will be granted access to = services not=20 controlled by the credit control
   server=20 for unlimited time is dependent on the home service provider = policy=20
   (note: the latter option implies that = the=20 service element should not remove
   the=20 restriction filters upon termination of the credit control = session).=20
   The server will return the appropriate = Result-Code (see section 9.1) in the
  =20 Credit-Control-Answer message in order to close the credit control=20
   session and implement the = policy-defined=20 action. Otherwise new quota
   = will be=20 returned, the service element MUST remove all the possible =
   restrictions activated by the graceful service = termination=20 process and
   continue the credit = control=20 session and the service session as usual.

- section 5.5.3, second paragraph:

FROM:

   Another entity than the credit control = server may=20 provision the access
   device = with=20 appropriate IP packet filters to be used in conjunction =
   with the Diameter credit control application. = Such an=20 entity, for
   instance, may = configure the=20 access device with "zero-rated" IP flows
  =20 that are to be passed when the Diameter credit control application=20
   indicates RESTRICT_ACCESS or = REDIRECT.=20 The access device passes IP
   = packets=20 according to the filter rules possibly received in the Credit-=20
   Control-Answer message in addition to = the filter=20 rules possibly
   configured by = the other=20 entity. However, the action to be taken when
   the user's account cannot cover the cost of the = requested=20 service is
   the responsibility = of the=20 credit control server that controls the
  =20 prepaid subscriber.

TO:

   Another entity than the credit control = server may=20 provision the access
   device = with=20 appropriate IP packet filters to be used in conjunction =
   with the Diameter credit control application. = Such an=20 entity, for
   example, may = configure the=20 access device with IP flows
   = that are to=20 be passed when the Diameter credit control application =
   indicates RESTRICT_ACCESS or REDIRECT. The = access device=20 passes IP
   packets according to = the filter=20 rules possibly received in the Credit-
  =20 Control-Answer message in addition to the filter rules possibly=20
   configured by the other entity. = However,=20 the action to be taken when
   the = user's=20 account cannot cover the cost of the requested service is =
   the responsibility of the credit control server = that=20 controls the
   prepaid = subscriber.=20

- Section 8.15, sixth paragraph:

FROM:

   If the Final-Unit-Action AVP is set to = REDIRECT=20 at least the Redirect-
   Server = AVP MUST be=20 present. The Restriction-Filter-Rule AVP or the
   Filter-Id AVP MAY be present in the = Credit-Control-Answer=20 message if
   the user is allowed = to access=20 also other zero-rated services not
  =20 accessible through the address given in the Redirect-Server = AVP.

TO:

   If the Final-Unit-Action AVP is set to = REDIRECT=20 at least the Redirect-
   Server = AVP MUST be=20 present. The Restriction-Filter-Rule AVP or the
   Filter-Id AVP MAY be present in the = Credit-Control-Answer=20 message if
   the user is allowed = to access=20 also other services not
   = accessible=20 through the address given in the Redirect-Server AVP.

- Section 8.16, fifth paragraph:

FROM:
   In = contrast, a=20 value of max type granted service unit (e.g. max
   Unsigned 32 is FFFFFFFF) associated to a=20 Service-Identifier(s) or
   = Rating-Group=20 indicates that the corresponding traffic is free-of-
   charge. With unit type money, the value of the = Exponent=20 AVP is set to
   0 (zero) when=20 free-of-charge is indicated. With unit type service
   specific, the value of the = CC-Service-Specific-Units AVP=20 is set to
   FFFFFFFF to indicate=20 free-of-charge.

TO:
   In = contrast, a value=20 of max type granted service unit (e.g. max
   Unsigned 32 is FFFFFFFF) associated to a=20 Service-Identifier(s) or
   = Rating-Group=20 indicates that usage of the corresponding traffic is unlimited. =
   With unit type money, the value of the = Exponent=20 AVP is set to
   0 (zero) when = unlimited=20 usage is indicated. With unit type service
   specific, the value of the = CC-Service-Specific-Units AVP=20 is set to
   FFFFFFFF to indicate = unlimited=20 usage.


- Section 8.22, first paragraph:

FROM:

   The Restriction-Filter-Rule AVP (AVP = Code 438) is=20 of type IPFilterRule
   and = provides filter=20 rules corresponding to zero-rated services offered
   by the home service provider. The access device = need to=20 configure the
   specified filter = rules for=20 the subscriber and MUST drop all the
  =20 packets not matching these filters. Zero, one or more such AVPs MAY be =
   present in a = Credit-Control-Answer=20 message or in an AA answer message.

TO:

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


- end of changes=20




------_=_NextPart_001_01C3E63C.46356BB1-- From aaa-admin@ietf.org Thu Jan 29 03:35:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08095 for ; Thu, 29 Jan 2004 03:35: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 1Am7dd-00014j-TR; Thu, 29 Jan 2004 03:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7cw-00012U-4S for aaa@optimus.ietf.org; Thu, 29 Jan 2004 03:34: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 DAA08052 for ; Thu, 29 Jan 2004 03:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am7ct-0004My-00 for aaa@ietf.org; Thu, 29 Jan 2004 03:34:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am7bu-0004GF-00 for aaa@ietf.org; Thu, 29 Jan 2004 03:33:15 -0500 Received: from modemcable009.191-203-24.mc.videotron.ca ([24.203.191.9] helo=24.203.191.9) by ietf-mx with smtp (Exim 4.12) id 1Am7bS-00049t-00 for aaa@ietf.org; Thu, 29 Jan 2004 03:32:47 -0500 Date: Thu, 29 Jan 2004 10:28:40 -0600 From: delivery241987@email.com X-Mailer: The Bat! (v1.53d) Reply-To: delivery241987@earthlink.net Organization: 532307001 X-Priority: 3 (Normal) To: aaa@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1251 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=17.8 required=5.0 tests=DATE_IN_FUTURE_06_12, FORGED_MUA_THEBAT,FORGED_THEBAT_HTML,FROM_ENDS_IN_NUMS,HTML_20_30, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE,MILLION_EMAIL, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO, SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.6 MILLION_EMAIL BODY: Get a million email addresses * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 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.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 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 * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) Content-Transfer-Encoding: 8bit Subject: [Aaa] Mass e-mail delivery 551108598 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 Mass e-mail delivery
Hello!

We offer advertising of your goods and services through the Internet using mass e-mail delivery.

Nowadays e-mail delivery is one of the most effective, available and cheap ways of advertising. Having paid quite a small sum of money and only one day spent for a certain ads campaign - you get your advertising information delivered to hundreds thousands of people. E-mail marketing is spreading around the whole world because of its high effectiveness, speed and low cost.

Our company is in bulk e-mail business for more than 5 years. We got a variety of e-mail databases from USA and all over the world. We constantly update and replenish, harvest and validate our e-mail databases.

In our work we use the high-speed Internet connections, dedicated servers and the latest e-mail bulking technologies, which all is the guarantee of the top delivery quality.

We officially reside and work in Poland, we accept any kind of payments and able to give all the necessary documents.

The overall database quantity is about 250 million of e-mail addresses from all over the world.
1 million of messages sent costs $100. The more you order - the greater discounts you will receive.

To get all the details and order the bulk mailing you just have to e-mail us to sendermail@mail15.com.

We apologize for any inconveniences, caused by this e-mail to you. Your e-mail address had been taken from opened information sources.
_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Jan 29 03:36:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08147 for ; Thu, 29 Jan 2004 03:36: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 1Am7ej-0001BD-PA for aaa-archive@odin.ietf.org; Thu, 29 Jan 2004 03:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T8a9Zb004529 for aaa-archive@odin.ietf.org; Thu, 29 Jan 2004 03:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7ej-0001Ay-FE for aaa-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 03:36: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 DAA08131 for ; Thu, 29 Jan 2004 03:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am7eh-0004Yw-00 for aaa-web-archive@ietf.org; Thu, 29 Jan 2004 03:36:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Am7dm-0004T5-00 for aaa-web-archive@ietf.org; Thu, 29 Jan 2004 03:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7dd-00014j-TR; Thu, 29 Jan 2004 03:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7cw-00012U-4S for aaa@optimus.ietf.org; Thu, 29 Jan 2004 03:34: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 DAA08052 for ; Thu, 29 Jan 2004 03:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am7ct-0004My-00 for aaa@ietf.org; Thu, 29 Jan 2004 03:34:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am7bu-0004GF-00 for aaa@ietf.org; Thu, 29 Jan 2004 03:33:15 -0500 Received: from modemcable009.191-203-24.mc.videotron.ca ([24.203.191.9] helo=24.203.191.9) by ietf-mx with smtp (Exim 4.12) id 1Am7bS-00049t-00 for aaa@ietf.org; Thu, 29 Jan 2004 03:32:47 -0500 Date: Thu, 29 Jan 2004 10:28:40 -0600 From: delivery241987@email.com X-Mailer: The Bat! (v1.53d) Reply-To: delivery241987@earthlink.net Organization: 532307001 X-Priority: 3 (Normal) To: aaa@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1251 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=17.8 required=5.0 tests=DATE_IN_FUTURE_06_12, FORGED_MUA_THEBAT,FORGED_THEBAT_HTML,FROM_ENDS_IN_NUMS,HTML_20_30, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE,MILLION_EMAIL, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO, SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.6 MILLION_EMAIL BODY: Get a million email addresses * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 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.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 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 * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) Content-Transfer-Encoding: 8bit Subject: [Aaa] Mass e-mail delivery 551108598 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 Mass e-mail delivery
Hello!

We offer advertising of your goods and services through the Internet using mass e-mail delivery.

Nowadays e-mail delivery is one of the most effective, available and cheap ways of advertising. Having paid quite a small sum of money and only one day spent for a certain ads campaign - you get your advertising information delivered to hundreds thousands of people. E-mail marketing is spreading around the whole world because of its high effectiveness, speed and low cost.

Our company is in bulk e-mail business for more than 5 years. We got a variety of e-mail databases from USA and all over the world. We constantly update and replenish, harvest and validate our e-mail databases.

In our work we use the high-speed Internet connections, dedicated servers and the latest e-mail bulking technologies, which all is the guarantee of the top delivery quality.

We officially reside and work in Poland, we accept any kind of payments and able to give all the necessary documents.

The overall database quantity is about 250 million of e-mail addresses from all over the world.
1 million of messages sent costs $100. The more you order - the greater discounts you will receive.

To get all the details and order the bulk mailing you just have to e-mail us to sendermail@mail15.com.

We apologize for any inconveniences, caused by this e-mail to you. Your e-mail address had been taken from opened information sources.
_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Jan 29 07:02:47 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 HAA14204 for ; Thu, 29 Jan 2004 07:02:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D962991256; Thu, 29 Jan 2004 07:02:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD21391257; Thu, 29 Jan 2004 07:02:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51EF091256 for ; Thu, 29 Jan 2004 07:02:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36D145DDFE; Thu, 29 Jan 2004 07:02:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id AEFF25DDF4 for ; Thu, 29 Jan 2004 07:02:32 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0TC2UqY025081; Thu, 29 Jan 2004 13:02:31 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 13:02:38 +0100 Message-ID: From: "Harri Hakala (TU/LMF)" To: "'Mark Watson'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "Leena Mattila (TU/LMF)" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "Patrik Teppo (KA/EAB)" , "'juha-pekka.koskinen@nokia.com'" , Christopher Richards , Javier Gonzalez Gallego Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Thu, 29 Jan 2004 13:02:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Mark, >Is to your opinion that in order to handle re-authorisation for separate >Rating-Groups independently then separate sub-sessions/state machines are >needed (either client or server initiated) ? If there is a common credit pool for Rating-Groups/services, why RGs need to be reported independently? In other words isn't it enough to have one re-authorization request, where used units are reported and new units are required per RGs (compare flow X) and to have one re-authorization answer where the common quota associated with the RGs is returned? Anyhow, I think that if there is need for own re-authorization per RG within the (sub)-session, then separate state machines are needed per RG. >Is the same true if I want to provide different handling on credit exhaustion >- for example one Rating-Group is terminated, another redirected and a further >one allowed to continue 'into the red'. >Both the above are assuming that the separate Rating-Groups all draw from the >same credit pool. In my opinion, as long as there is no such situation where a credit re-authorization request is sent to allocate more quota for one service while indicating e.g. a redirect to refill server for another service then I don't see a big problem. If one CCR would contain different credit allocation requests for the same pool then this would require separate state machines. regards........harri From owner-aaa-wg@merit.edu Thu Jan 29 08:38: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 IAA16643 for ; Thu, 29 Jan 2004 08:38:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D59C91258; Thu, 29 Jan 2004 08:38:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64F349125A; Thu, 29 Jan 2004 08:38: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 9E7A891258 for ; Thu, 29 Jan 2004 08:38:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A2D25DE72; Thu, 29 Jan 2004 08:38:40 -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 BD8835DE6F for ; Thu, 29 Jan 2004 08:38:39 -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 i0TDcUl29139; Thu, 29 Jan 2004 13:38:31 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 13:38:31 -0000 Message-ID: From: "Mark Watson" To: "'Harri Hakala (TU/LMF)'" , "'marco.stura@nokia.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'Leena Mattila (TU/LMF)'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'Patrik Teppo (KA/EAB)'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Thu, 29 Jan 2004 13:38:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E66D.2D2712A8" 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_01C3E66D.2D2712A8 Content-Type: text/plain Hi Harri, Thanks - this makes things clearer. To answer your questions, it should not be necessary to re-authorise all quotas associated with a pool when a new one is to be added. The draft allows for packet flow to continue during re-auth, but this is an issue of service provider policy. If SP policy implies service interruption during re-auth, we need to minimise the re-auths. It's not the CCR which might contain different requests for different RGs, but the CCA. This might indicate that one RG should be terminated or redirected whilst another can continue. Clearer, service providers will have different policies for different services with respect to handling on credit exhaustion - e.g. some services can continue for a limited time. ...Mark -----Original Message----- From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.com] Sent: 29 January 2004 12:02 To: Watson, Mark [MOP:EP10:EXCH]; 'marco.stura@nokia.com' Cc: 'john.loughney@nokia.com'; 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); 'juha-pekka.koskinen@nokia.com'; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Mark, >Is to your opinion that in order to handle re-authorisation for >separate Rating-Groups independently then separate sub-sessions/state >machines are needed (either client or server initiated) ? If there is a common credit pool for Rating-Groups/services, why RGs need to be reported independently? In other words isn't it enough to have one re-authorization request, where used units are reported and new units are required per RGs (compare flow X) and to have one re-authorization answer where the common quota associated with the RGs is returned? Anyhow, I think that if there is need for own re-authorization per RG within the (sub)-session, then separate state machines are needed per RG. >Is the same true if I want to provide different handling on credit >exhaustion >- for example one Rating-Group is terminated, another redirected and a further >one allowed to continue 'into the red'. >Both the above are assuming that the separate Rating-Groups all draw from the >same credit pool. In my opinion, as long as there is no such situation where a credit re-authorization request is sent to allocate more quota for one service while indicating e.g. a redirect to refill server for another service then I don't see a big problem. If one CCR would contain different credit allocation requests for the same pool then this would require separate state machines. regards........harri ------_=_NextPart_001_01C3E66D.2D2712A8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. = discussi on

Hi Harri,

Thanks - this makes things clearer.

To answer your questions, it should not be necessary = to re-authorise all quotas associated with a pool when a new one is to = be added. The draft allows for packet flow to continue during re-auth, = but this is an issue of service provider policy. If SP policy implies = service interruption during re-auth, we need to minimise the = re-auths.

It's not the CCR which might contain different = requests for different RGs, but the CCA. This might indicate that one = RG should be terminated or redirected whilst another can continue. = Clearer, service providers will have different policies for different = services with respect to handling on credit exhaustion - e.g. some = services can continue for a limited time.

...Mark





-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:harri.hakala@ericsson.c= om]
Sent: 29 January 2004 12:02
To: Watson, Mark [MOP:EP10:EXCH]; = 'marco.stura@nokia.com'
Cc: 'john.loughney@nokia.com'; = 'juha-pekka.koskinen@nokia.com'; Leena Mattila (TU/LMF); = 'aaa-wg@merit.edu'; 'Karl-Heinz.Nenner@t-mobile.de'; = 'Benni.Alexander@nokia.com'; Patrik Teppo (KA/EAB); = 'juha-pekka.koskinen@nokia.com'; Richards, Christopher = [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]

Subject: RE: [AAA-WG]: multiple services in a user = session, tech. discussi on


Hi Mark,

>Is to your opinion that in order to handle = re-authorisation for
>separate Rating-Groups independently then = separate sub-sessions/state
>machines are needed (either client or server = initiated) ?
If there is a common credit pool for = Rating-Groups/services, why RGs need to be reported independently? In = other words isn't it enough to have one re-authorization request, where = used units are reported and new units are

required per RGs (compare flow X) and to have one = re-authorization answer
where the common quota associated with the RGs is = returned?

Anyhow, I think that if there is need for own = re-authorization per RG within the
(sub)-session, then separate state machines are = needed per RG.

>Is the same true if I want to provide different = handling on credit
>exhaustion
>- for example one Rating-Group is terminated, = another redirected and a further
>one allowed to continue 'into the red'.
>Both the above are assuming that the separate = Rating-Groups all draw from the
>same credit pool.
In my opinion, as long as there is no such situation = where a credit re-authorization request is sent to allocate more quota = for one service while indicating e.g. a redirect to refill server for = another service then I don't see a big problem. If one CCR would = contain different credit allocation requests for the same pool then = this would require separate state machines.

regards........harri






------_=_NextPart_001_01C3E66D.2D2712A8-- From owner-aaa-wg@merit.edu Thu Jan 29 09:44: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 JAA19534 for ; Thu, 29 Jan 2004 09:44:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4315891275; Thu, 29 Jan 2004 09:40:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E4F991270; Thu, 29 Jan 2004 09:40: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 6FC3791277 for ; Thu, 29 Jan 2004 09:38:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55A0B5DD90; Thu, 29 Jan 2004 09:38:09 -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 AC7745DD97 for ; Thu, 29 Jan 2004 09:38:07 -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 i0TEc1215119 for ; Thu, 29 Jan 2004 16:38:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 16:31:52 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 16:31:52 +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_01C3E674.A2B520E8" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Thu, 29 Jan 2004 16:31:51 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03F3@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: multiple services in a user session, tech. discussi on Thread-Index: AcPmbTYYhKfwa10/SNuIkiOxo128KwAAq4hw From: To: , Cc: , , , , , , , , , X-OriginalArrivalTime: 29 Jan 2004 14:31:52.0189 (UTC) FILETIME=[A30192D0:01C3E674] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E674.A2B520E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 >To answer your questions, it should not be necessary to re-authorise = all quotas associated with a pool when a new one is to be=20 >added.=20 =20 What you say implies a new credit reservation to the same pool (i.e. = account). Since the client doesn't report back the units used from the current reservation, these quotas are running in the = client and we cannot operate on the existing credit reservation. This = may lead to situations where all the available credit resources have = been allocated to the client, but not actually used (ok, you can control with an idle timer but its not = deterministic), when the server receives a request for a new service/rg. Also, high number of credit reservations may become a = burden for the server etc. Is that what we want? =20 >The draft allows for packet flow to continue during re-auth, but this = is an issue of service provider policy. If SP policy implies service > interruption during re-auth, we need to minimise the re-auths. =20 I guess you are thinking to the fraud window during the re-authorization = round-trip, right? In the DCC we can get the fraud window to zero, that's why we have the = final-unit-indication. If the client didn't receive the final-unit-indication it is because there still credit in that pool and = there is no risk of running out, otherwise it would have received the = final-units with the action to be taken in the last CCA.=20 =20 >It's not the CCR which might contain different requests for different = RGs, but the CCA. This might indicate that one RG should be=20 >terminated or redirected whilst another can continue. Clearer, service = providers will have different policies for different services with=20 >respect to handling on credit exhaustion - e.g. some services can = continue for a limited time. =20 I don't fully get your first statement "It's not the CCR which might = contain different requets...". We have been discussing that the client = may request quota only when the service/rg is actually used, how the = server would know this if not indicated by the client? So, what do you = exactly mean with that statement? Concerning the different policies for different services/rg, perhaps we = need to have finer granularity for the actions and we need to find a = solution for that. =20 Regards Marco ------_=_NextPart_001_01C3E674.A2B520E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: multiple services in a user session, tech. discussi = on
Hi=20 Mark,
 
>To answer your = questions,=20 it should not be necessary to re-authorise all quotas associated with a = pool=20 when a new one is to be
>added. =
 
What you say implies a new credit reservation = to the=20 same pool (i.e. account). Since the client doesn't report back=20 the
units used from the current reservation, = these quotas=20 are running in the client and we cannot operate on the existing credit=20 reservation. This may lead to situations where all the available credit=20 resources have been allocated to the client, but = not
actually used (ok, you can control with an = idle timer=20 but its not deterministic), when the server receives a request for a=20 new
service/rg.  Also, high number of credit = reservations may become a burden for the server etc. Is that what we=20 want?
 
>The draft allows for packet flow to = continue during=20 re-auth, but this is an issue of service provider policy. If SP policy = implies=20 service
> interruption during re-auth, we = need to=20 minimise the re-auths.
 
I guess you are thinking to the fraud window = during the=20 re-authorization round-trip, = right?
In the DCC we can get the fraud window to = zero, that's=20 why we have the final-unit-indication. If the client didn't receive=20 the
final-unit-indication it is because there = still credit=20 in that pool and there is no risk of running out, otherwise it would = have=20 received the = final-units with the=20 action to be taken in the last CCA. =
 
>It's not the CCR which might contain = different=20 requests for different RGs, but the CCA. This might indicate that one RG = should=20 be
>terminated or redirected whilst another = can=20 continue. Clearer, service providers will have different policies for = different=20 services with
>respect to handling on credit exhaustion = - e.g.=20 some services can continue for a limited=20 time.
 
I don't fully get your first statement "It's = not the=20 CCR which might contain different requets...". We have been discussing = that the=20 client may request quota only when the service/rg is actually used, how = the=20 server would know this if not indicated by the client? So, what do you = exactly=20 mean with that statement?
Concerning the different policies for = different=20 services/rg, perhaps  we need to have finer granularity for the = actions and=20 we need to find a solution = for=20 that.
 
Regards
Marco
------_=_NextPart_001_01C3E674.A2B520E8-- From owner-aaa-wg@merit.edu Thu Jan 29 13:18: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 NAA06151 for ; Thu, 29 Jan 2004 13:18:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E8C06912FB; Thu, 29 Jan 2004 13:15:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6067B912CA; Thu, 29 Jan 2004 13:15: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 A78F6912D3 for ; Thu, 29 Jan 2004 13:11:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E7F35DDD1; Thu, 29 Jan 2004 13:11:32 -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 3F7D65DDE4 for ; Thu, 29 Jan 2004 13:11:24 -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 i0TIB4W24176; Thu, 29 Jan 2004 18:11:04 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 18:11:04 -0000 Message-ID: From: "Mark Watson" To: "'marco.stura@nokia.com'" , "'harri.hakala@ericsson.com'" Cc: "'john.loughney@nokia.com'" , "'juha-pekka.koskinen@nokia.com'" , "'leena.mattila@ericsson.com'" , "'aaa-wg@merit.edu'" , "'Karl-Heinz.Nenner@t-mobile.de'" , "'Benni.Alexander@nokia.com'" , "'patrik.teppo@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "Christopher Richards" , "Javier Gonzalez Gallego" Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Date: Thu, 29 Jan 2004 18:11:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E693.41F77706" 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_01C3E693.41F77706 Content-Type: text/plain Hi Marco, Some comments below... -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 29 January 2004 14:32 To: Watson, Mark [MOP:EP10:EXCH]; harri.hakala@ericsson.com Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH] Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on Hi Mark, >To answer your questions, it should not be necessary to re-authorise all quotas associated with a pool when a new one is to be >added. What you say implies a new credit reservation to the same pool (i.e. account). Since the client doesn't report back the units used from the current reservation, these quotas are running in the client and we cannot operate on the existing credit reservation. MW> Why not ? The server could instruct the client that the new service should draw from the same pool as the existing ones, or it could supply an additional credit reservation to be 'added' to the pool already running in the client. Ok, so the *existing* mechanism in the draft cannot do this - that is one of our points! This may lead to situations where all the available credit resources have been allocated to the client, but not actually used (ok, you can control with an idle timer but its not deterministic), when the server receives a request for a new service/rg. Also, high number of credit reservations may become a burden for the server etc. Is that what we want? MW> No, the burden on the server is higher if all existing quotas need to be reported and re-authed/re-rated when a new service is added. We would prefer that the server could just auth & rate the one new service which is to be added. >The draft allows for packet flow to continue during re-auth, but this is an issue of service provider policy. If SP policy implies service > interruption during re-auth, we need to minimise the re-auths. I guess you are thinking to the fraud window during the re-authorization round-trip, right? In the DCC we can get the fraud window to zero, that's why we have the final-unit-indication. If the client didn't receive the final-unit-indication it is because there still credit in that pool and there is no risk of running out, otherwise it would have received the final-units with the action to be taken in the last CCA. MW> You are making an assumption that there are no other drains on the credit in the server. Certainly the server can refuse to re-authorise a service even if it didn't return the Final-Units-Indication. >It's not the CCR which might contain different requests for different RGs, but the CCA. This might indicate that one RG should be >terminated or redirected whilst another can continue. Clearer, service providers will have different policies for different services with >respect to handling on credit exhaustion - e.g. some services can continue for a limited time. I don't fully get your first statement "It's not the CCR which might contain different requets...". We have been discussing that the client may request quota only when the service/rg is actually used, how the server would know this if not indicated by the client? So, what do you exactly mean with that statement? MW> Sorry if it wasn't clear - this point was addressing a different question in Harri's email. The point is just that the server may want to indicate different handling for different Services/Rating-Groups. Some may be terminated, some re-directed and others allowed to continue (still under credit control). Concerning the different policies for different services/rg, perhaps we need to have finer granularity for the actions and we need to find a solution for that. MW> Yes, I think that is one point exactly. But from Harri's comments it seemed not possible to do that unless a separate state machine was associated with each quota, rather than with each (sub-)session. Anyway, proposals to address these points to follow by eod - we are not stuck on any single solution & I'm hopeful we can work out some agreeable soution between us. ...Mark Regards Marco ------_=_NextPart_001_01C3E693.41F77706 Content-Type: text/html Message
Hi Marco,
 
Some comments below...
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 29 January 2004 14:32
To: Watson, Mark [MOP:EP10:EXCH]; harri.hakala@ericsson.com
Cc: john.loughney@nokia.com; juha-pekka.koskinen@nokia.com; leena.mattila@ericsson.com; aaa-wg@merit.edu; Karl-Heinz.Nenner@t-mobile.de; Benni.Alexander@nokia.com; patrik.teppo@ericsson.com; juha-pekka.koskinen@nokia.com; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]
Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on

Hi Mark,
 
>To answer your questions, it should not be necessary to re-authorise all quotas associated with a pool when a new one is to be
>added.
 
What you say implies a new credit reservation to the same pool (i.e. account). Since the client doesn't report back the
units used from the current reservation, these quotas are running in the client and we cannot operate on the existing credit reservation. 
MW> Why not ? The server could instruct the client that the new service should draw from the same pool as the existing ones, or it could supply an additional credit reservation to be 'added' to the pool already running in the client. Ok, so the *existing* mechanism in the draft cannot do this - that is one of our points!
 
 This may lead to situations where all the available credit resources have been allocated to the client, but not
actually used (ok, you can control with an idle timer but its not deterministic), when the server receives a request for a new
service/rg.  Also, high number of credit reservations may become a burden for the server etc. Is that what we want? 
 
MW> No, the burden on the server is higher if all existing quotas need to be reported and re-authed/re-rated when a new service is added. We would prefer that the server could just auth & rate the one new service which is to be added.
 
>The draft allows for packet flow to continue during re-auth, but this is an issue of service provider policy. If SP policy implies service
> interruption during re-auth, we need to minimise the re-auths.
 
I guess you are thinking to the fraud window during the re-authorization round-trip, right?
In the DCC we can get the fraud window to zero, that's why we have the final-unit-indication. If the client didn't receive the
final-unit-indication it is because there still credit in that pool and there is no risk of running out, otherwise it would have received the final-units with the action to be taken in the last CCA.  
 
MW> You are making an assumption that there are no other drains on the credit in the server. Certainly the server can refuse to re-authorise a service even if it didn't return the Final-Units-Indication. 
 
>It's not the CCR which might contain different requests for different RGs, but the CCA. This might indicate that one RG should be
>terminated or redirected whilst another can continue. Clearer, service providers will have different policies for different services with
>respect to handling on credit exhaustion - e.g. some services can continue for a limited time.
 
I don't fully get your first statement "It's not the CCR which might contain different requets...". We have been discussing that the client may request quota only when the service/rg is actually used, how the server would know this if not indicated by the client? So, what do you exactly mean with that statement? 
 
MW> Sorry if it wasn't clear - this point was addressing a different question in Harri's email. The point is just that the server may want to indicate different handling for different Services/Rating-Groups. Some may be terminated, some re-directed and others allowed to continue (still under credit control).
 
Concerning the different policies for different services/rg, perhaps  we need to have finer granularity for the actions and we need to find a solution for that. 
 
MW> Yes, I think that is one point exactly. But from Harri's comments it seemed not possible to do that unless a separate state machine was associated with each quota, rather than with each (sub-)session.  
 
Anyway, proposals to address these points to follow by eod - we are not stuck on any single solution & I'm hopeful we can work out some agreeable soution between us.
 
...Mark
 
Regards
Marco
------_=_NextPart_001_01C3E693.41F77706-- From owner-aaa-wg@merit.edu Thu Jan 29 14:11: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 OAA09260 for ; Thu, 29 Jan 2004 14:11:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA1B091478; Thu, 29 Jan 2004 14:09:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA3069144F; Thu, 29 Jan 2004 14:04: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 3D00D91449 for ; Thu, 29 Jan 2004 14:03:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 25A285DDBA; Thu, 29 Jan 2004 14:03: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 5BA935DDCE for ; Thu, 29 Jan 2004 14:03:24 -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 i0TJ3MW02187 for ; Thu, 29 Jan 2004 19:03:22 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 19:03:23 -0000 Message-ID: From: "Mark Watson" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Issue: DCC: Credit pooling should be under server control Date: Thu, 29 Jan 2004 19:03:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E69A.90256DF0" 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_01C3E69A.90256DF0 Content-Type: text/plain All, Please find below the first of two issues for the DCC Working Group Last Call based on the various discussions on credit pooling and quota independence - I'd be grateful if someone could let me know if there is anything I need to do to get an issue number/agree on the priority. Regards...Mark Description of issue: Credit pooling should be under server control Submitter name: Mark Watson/Chris Richards 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 ] Section: Various Rationale/Explanation of issues: The current draft allocates credit as a 'pool' associated with a session or sub-session. All Services or Rating-Groups within the (sub-)session draw from the single pool. Mapping of Services and Rating-Groups to (sub-)sessions is under the control of the client. In particular: in Clause 5 of the draft we can read: "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). " The Requested-Service-Unit AVP is part of the CCR, and as said in 8.21: "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. " 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. This is directly opposite to 3GPP requirements stated in TR23.825 v.1.4.0 section 4.3.2. These requires the mapping of Services/Rating-Groups to credit pools to be under control of the server. Since 3GPP intend to pull this specification into 3GPP, it would be advisable to incorporate 3GPP requirements into the draft. So this work can be used by other standard bodies facilitating its adoption by the industry. Furthermore, the current draft identifies grouping for the purposes of 'credit pooling' with grouping for the purpose of state machine handling, re-authorisation and failure handling. There is no rationale for such an identification - just because credit can be pooled between two services does not mean they should be handled in the same way on credit exhaustion, for example. 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). Server control of credit pooling is equivalent to considering different services to be funded from different accounts. It can be approximated according to the current draft as described in http://www.merit.edu/mail.archives/aaa-wg/msg00117.html. In this proposal the server makes equivalent reservations in all necessary accounts and authorizes service units according to this amount. This has a number of drawbacks: (i) it assumes a notion of equivalence between the credit available in the different accounts. This is easy to understand where accounts contain monetary currency, but more difficult when they contain scrip or special one-time vouchers with various rules/restrictions attached. (ii) it restricts the value of the reservation for all flows based on the reservations allowed for each individual flow. However, the size of credit reservations may be related to the expected usage of different services or may vary depending on the account from which the service is funded. For example, credit may be reserved in large blocks from the users account in order to reduce re-authorisation traffic. But for a service which is wholly or partly funded by a 3rd party, the reservation may be a small amount. (iii) it is counter-intuitive since the same granted units appear to be funded multiple times from the different accounts. We propose that the grouping of services into credit pools should be under the control of the server and should be decoupled from state machine handling. We further propose to indicate which types of unit (time/volume/etc.) are considered 'pooled'. Others are to be metered independently for each quota. We do not have a strong preference as to how this is achieved. One proposal is given below. Requested change: Overview: 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). 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. The absence of a G-S-U-Pool-Reference for a particular unit type implies that the (sub-)session is to be considered a single pool, as per the existing draft. Detailed changes: - Change fifth paragraph of Section 5: 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 credit pool is explicitly identified in the Granted-Service- Units AVP. 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. 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). - Section 8, add to table: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| 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| | | | | | - Section 8.16 - amend as follows: FROM: 8.16 Granted-Service-Unit AVP Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 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 shall terminate credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group. In case both the Service-Identifier and the Rating-Group AVPs are included, the target of the granted units is always the service(s) indicated by the value of the Service-Identifier AVP. A value of 0 (zero) granted service unit associated to a Service- entifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in case the credit-control server want to disconnect the user and close the credit-control 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). 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. 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: 8.16 Granted-Service-Unit AVP Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 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 shall terminate credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group. In case both the Service-Identifier and the Rating-Group AVPs are included, the target of the granted units is always the service(s) indicated by the value of the Service-Identifier AVP. A value of 0 (zero) granted service unit associated to a Service- entifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in case the credit-control server want to disconnect the user and close the credit-control 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). 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. 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. 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. 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 ] - Add new Section 8.X: 8.X G-S-U-Pool-Identifier AVP The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type Unsigned32 and identifies a 'credit pool' within the session with which the Granted-Service-Units AVP is associated. 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. 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 ) 8.Z CC-Unit-Type AVP 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 MONEY 1 TOTAL-OCTETS 2 INPUT-OCTETS 3 OUTPUT-OCTETS 4 SERVICE-SPECIFIC-UNITS 5 - end of changes ------_=_NextPart_001_01C3E69A.90256DF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Issue: DCC: Credit pooling should be under server = control

All,

Please find below the first of two issues for the DCC = Working Group Last Call based on the various discussions on credit = pooling and quota independence - I'd be grateful if someone could let = me know if there is anything I need to do to get an issue number/agree = on the priority.

Regards...Mark


Description of issue: Credit pooling should be under = server control
Submitter name: Mark Watson/Chris Richards
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 ]
Section: Various

Rationale/Explanation of issues:

The current draft allocates credit as a 'pool' = associated with a session or sub-session. All Services or Rating-Groups = within the (sub-)session draw from the single pool.

Mapping of Services and Rating-Groups to = (sub-)sessions is under the control of the client.

In particular: in Clause 5 of the draft we can read: =
  "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). "

The Requested-Service-Unit AVP is part of the CCR, = and as said in 8.21:
"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.  "

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.

This is directly opposite to 3GPP requirements stated = in TR23.825 v.1.4.0 section 4.3.2. These requires the mapping of = Services/Rating-Groups to credit pools to be under control of the = server.

Since 3GPP intend to pull this specification into = 3GPP, it would be advisable to incorporate 3GPP requirements into the = draft. So this work can be used by other standard bodies facilitating = its adoption by the industry.

Furthermore, the current draft identifies grouping = for the purposes of 'credit pooling' with grouping for the purpose of = state machine handling, re-authorisation and failure handling. There is = no rationale for such an identification - just because credit can be = pooled between two services does not mean they should be handled in the = same way on credit exhaustion, for example.

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

Server control of credit pooling is equivalent to = considering different services to be funded from different accounts. It = can be approximated according to the current draft as described in http://www.merit.edu/mail.archives/aaa-wg/msg00117.htm= l. In this proposal the server makes equivalent reservations in all = necessary accounts and authorizes service units according to this = amount.

This has a number of drawbacks:
(i) it assumes a notion of equivalence between the = credit available in the different accounts. This is easy to understand = where accounts contain monetary currency, but more difficult when they = contain scrip or special one-time vouchers with various = rules/restrictions attached.

(ii) it restricts the value of the reservation for = all flows based on the reservations allowed for each individual flow. = However, the size of credit reservations may be related to the expected = usage of different services or may vary depending on the account from = which the service is funded. For example, credit may be reserved in = large blocks from the users account in order to reduce re-authorisation = traffic. But for a service which is wholly or partly funded by a 3rd = party, the reservation may be a small amount.

(iii) it is counter-intuitive since the same granted = units appear to be funded multiple times from the different = accounts.

We propose that the grouping of services into credit = pools should be under the control of the server and should be decoupled = from state machine handling. We further propose to indicate which types = of unit (time/volume/etc.) are considered 'pooled'. Others are to be = metered independently for each quota. We do not have a strong = preference as to how this is achieved. One proposal is given = below.



Requested change:

Overview:

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

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.

The absence of a G-S-U-Pool-Reference for a = particular unit type implies that the (sub-)session is to be considered = a single pool, as per the existing draft.

Detailed changes:


- Change fifth paragraph of Section 5:

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 credit pool is explicitly = identified in the Granted-Service-
   Units AVP. 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.

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



- Section 8, add to table:
          &nb= sp;           &nb= sp;           &nb= sp;         +-------------------= --+ 
          &nb= sp;           &nb= sp;           &nb= sp;         |    = AVP Flag rules   | 
          &nb= sp;           &nb= sp;           &nb= sp;         = |----+-----+----+-----|----+ 
          &nb= sp;          AVP  = Section           = |    |     |SHLD| = MUST|    | 
   Attribute Name    Code = Defined Data Type |MUST| MAY | NOT|  NOT|Encr| 
   = -----------------------------------------|----+-----+----+-----|----|&nb= sp;
   = G-S-U-Pool-      tbd  = 8.X      Unsigned32| M  | P   = |    |  V  |  Y |
      = Identifier          &n= bsp;           &n= bsp;     |    = |     |    |     = |    |
   = G-S-U-Pool-      tbd  = 8.Y      Grouped   | M  | = P   |    |  V  |  Y |
     = Reference          &nb= sp;           &nb= sp;       |    = |     |    |     = |    |
   CC-Unit-Type     = tbd  8.Z      = Enumerated|    |     = |    |     |    = |            = ;            = ;     
          &nb= sp;           &nb= sp;

- Section 8.16 - amend as follows:

FROM:

8.16 Granted-Service-Unit AVP 
       
   Granted-Service-Unit AVP (AVP Code 431) = is of type Grouped and
   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 shall terminate credit = control session and indicate in
   the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.
   
   The Service-Identifier and the = Rating-Group AVPs are used to associate
   the granted units to a given service or = rating group.
   In case both the Service-Identifier and = the Rating-Group AVPs are
   included, the target of the granted = units is always the service(s)
   indicated by the value of the = Service-Identifier AVP.
   A value of 0 (zero) granted service = unit associated to a Service-
   entifier(s) or Rating-Group indicates = that the corresponding traffic
   MUST be denied. Note that in case the = credit-control server want to
   disconnect the user and close the = credit-control 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). 
   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. =
   
   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:

8.16 Granted-Service-Unit AVP 
       
   Granted-Service-Unit AVP (AVP Code 431) = is of type Grouped and
   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 shall terminate credit = control session and indicate in
   the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.
   
   The Service-Identifier and the = Rating-Group AVPs are used to associate
   the granted units to a given service or = rating group.
   In case both the Service-Identifier and = the Rating-Group AVPs are
   included, the target of the granted = units is always the service(s)
   indicated by the value of the = Service-Identifier AVP.
   A value of 0 (zero) granted service = unit associated to a Service-
   entifier(s) or Rating-Group indicates = that the corresponding traffic
   MUST be denied. Note that in case the = credit-control server want to
   disconnect the user and close the = credit-control 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). 
   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.

   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.

   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.
   
   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;          *[ = G-S-U-Pool-Reference ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]
          &nb= sp;           &nb= sp;           [ = Validity-Time ]
          &nb= sp;           &nb= sp;           [ = Final-Unit-Indication ]

- Add new Section 8.X:

8.X G-S-U-Pool-Identifier AVP

    The G-S-U-Pool-Identifier AVP (AVP = code tbd) is of type Unsigned32 and
    identifies a 'credit pool' within = the session with which the
    Granted-Service-Units AVP is = associated. 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.

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 > =
          &nb= sp;           &nb= sp;           ( = G-S-U-Pool-Identifier )
          &nb= sp;           &nb= sp;           ( = CC-Unit-Type )

8.Z CC-Unit-Type AVP

    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           &n= bsp;        0
        = MONEY           &= nbsp;       1
        = TOTAL-OCTETS          =   2
        = INPUT-OCTETS          =   3
        = OUTPUT-OCTETS          = ; 4
        = SERVICE-SPECIFIC-UNITS  5


- end of changes




------_=_NextPart_001_01C3E69A.90256DF0-- From owner-aaa-wg@merit.edu Thu Jan 29 14:12: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 OAA09375 for ; Thu, 29 Jan 2004 14:12:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C930491470; Thu, 29 Jan 2004 14:09:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9139991253; Thu, 29 Jan 2004 14:09: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 0368191469 for ; Thu, 29 Jan 2004 14:07:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDCF15DDE3; Thu, 29 Jan 2004 14:07:57 -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 31B655DDD5 for ; Thu, 29 Jan 2004 14:07:56 -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 i0TJ7sW02394 for ; Thu, 29 Jan 2004 19:07:54 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 19:07:55 -0000 Message-ID: From: "Mark Watson" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Issue: DCC: Independent handling of services within a session Date: Thu, 29 Jan 2004 19:07:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E69B.31902338" 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_01C3E69B.31902338 Content-Type: text/plain All, Please find the second of two issues for DCC WGLC based on the discussions on credit pooling and quota independence. I attempted to separate the two issues of credit pooling and quota independence - indeed the symptoms of these two problems are distinct. However, there are linkages which lead to a common solution, and as such the proposal below builds heavily on the proposal of our other submission. I would say again that we are not wedded to a particular solution, but we were asked for a concrete proposal, so here it is! Best regards, Mark Description of issue: Independent handling of services within a session Submitter name: Mark Watson/Chris Richards 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 ] Section: Various Rationale/Explanation of issues: 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 - termination actions, particularly, redirect apply to the whole (sub-)session - state machine handling applies to the whole (sub-)session This has the following disadvantages: - unnecessary load on the server to perform re-rating for all services and rating groups, particularly when adding a new service will usually have no effect on the rating decision for the other services - unnecessary (though less than above) load on the client to process other services just to add a new one - not possible to leave some services under credit control when others are terminated/redirected (the policy for how far 'into the red' a service can run 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 allocation are passed down from client to server is counter-intuitive and liable to major mis-interpretation The above restriction stems from the manner in which the 'pooling' of quotas for multiple services is framed within the protocol. The quotas provided for different services are not semantically independent and therefore operations on them must be carried out 'en-bloc'. We propose to make the quotas provided semantically independent within the protocol, whilst maintaining the concept of a 'credit pool' which can apply to multiple services across the session. Additionally, as per our other proposal, we propose to decouple the 'pooling' of credit from the session/sub-session. 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 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. 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 This is pretty much equivalent to the existing formula (with Mi = M/Qi), with the following advantages: (i) new services can be added/removed without reference to the existing ones - M is simply modified by (Quota*Multiplier) for the added/removed service (ii) all quotas returned in CC answers cleanly represent independent authorizations to use the indicated resource (iii) re-authorisation can be sought for an individual service/rating group (for example if another quota associated with the same service/rating group is exhausted) (iv) flexibility, low signaling overhead and avoidance of credit fragmentation are maintained Note that where a Granted-Service-Unit contains more than one resource unit (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. Note that the draft at present does not include an explicit description of the handling 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 the Granted-Service-Unit APV to express independent handling of the different services in these respects. Requested change: Overview: To implement the above mechanism, we extend the proposal made in Issue xxx on 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: 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 pooled. G-S-U-Identifier AVP - identifies the credit pool. 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. 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. 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. - New section 5.X: 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. If M is the total service units within the pool, M1, M2, ... , Mn are the multipliers provided for services 1, 2, ..., n andC1, C2, ... ,Cn are the used resources within the session, then the pool credit is exhausted and re-authorisation MUST be sought when: C1*M1 + C2*M2 + ... + Cn*Mn >= M The total credit in the pool, M, is calculated from the quotas which are currently allocated to the pool as follows: M = Q1*M1 + Q2*M2 + ... + Qn*Mn If services or rating groups are added to or removed from the pool, then the total credit is adjusted appropriately. 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. 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. Where service units are provided within a Granted-Service-Units 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. - Section 8 - add to the table: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| 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| | | | | | - Section 8.16 - amend as follows: FROM: 8.16 Granted-Service-Unit AVP Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 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 shall terminate credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group. In case both the Service-Identifier and the Rating-Group AVPs are included, the target of the granted units is always the service(s) indicated by the value of the Service-Identifier AVP. A value of 0 (zero) granted service unit associated to a Service- entifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in case the credit-control server want to disconnect the user and close the credit-control 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). 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. 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: 8.16 Granted-Service-Unit AVP Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 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 shall terminate credit control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group. In case both the Service-Identifier and the Rating-Group AVPs are included, the target of the granted units is always the service(s) indicated by the value of the Service-Identifier AVP. A value of 0 (zero) granted service unit associated to a Service- entifier(s) or Rating-Group indicates that the corresponding traffic MUST be denied. Note that in case the credit-control server want to disconnect the user and close the credit-control 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). 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. 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. 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 ] - add new section 8.x 8.X G-S-U-Pool-Identifier AVP The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type Unsigned32 and identifies a 'credit pool' within the session. 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. The CC-Unit-Type AVP specifies the type of units for which credit is pooled. The G-S-U-Pool-Identifier AVP specifies the credit pool from which credit is drawn for this unit type. 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). G-S-U-Pool-Reference ::= < AVP Header: tbd > ( G-S-U-Pool-Identifier ) ( CC-Unit-Type ) ( Unit-Value ) 8.Z CC-Unit-Type AVP 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 MONEY 1 TOTAL-OCTETS 2 INPUT-OCTETS 3 OUTPUT-OCTETS 4 SERVICE-SPECIFIC-UNITS 5 - remove Annex A section A.10 (Flow X) - new example tbd once mechanism is agreed - end of changes ------_=_NextPart_001_01C3E69B.31902338 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Issue: DCC: Independent handling of services within a = session

All,

Please find the second of two issues for DCC WGLC = based on the discussions on credit pooling and quota independence. I = attempted to separate the two issues of credit pooling and quota = independence - indeed the symptoms of these two problems are distinct. = However, there are linkages which lead to a common solution, and as = such the proposal below builds heavily on the proposal of our other = submission.

I would say again that we are not wedded to a = particular solution, but we were asked for a concrete proposal, so here = it is!

Best regards,

Mark



Description of issue: Independent handling of = services within a session
Submitter name: Mark Watson/Chris Richards
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 ]
Section: Various

Rationale/Explanation of issues:

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

- termination actions, particularly, redirect apply = to the whole (sub-)session
- state machine handling applies to the whole = (sub-)session

This has the following disadvantages:
- unnecessary load on the server to perform = re-rating for all services and rating groups, particularly when adding = a new service will usually have no effect on the rating decision for = the other services

- unnecessary (though less than above) load on the = client to process other services just to add a new one
- not possible to leave some services under credit = control when others are terminated/redirected (the policy for how far = 'into the red' a service can run 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 allocation are passed down from client = to server is counter-intuitive and liable to major = mis-interpretation

The above restriction stems from the manner in which = the 'pooling' of quotas for multiple services is framed within the = protocol. The quotas provided for different services are not = semantically independent and therefore operations on them must be = carried out 'en-bloc'.

We propose to make the quotas provided semantically = independent within the protocol, whilst maintaining the concept of a = 'credit pool' which can apply to multiple services across the session. = Additionally, as per our other proposal, we propose to decouple the = 'pooling' of credit from the session/sub-session. 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 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.

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

This is pretty much equivalent to the existing = formula (with Mi =3D M/Qi), with the following advantages:
(i) new services can be added/removed without = reference to the existing ones - M is simply modified by = (Quota*Multiplier) for the added/removed service

(ii) all quotas returned in CC answers cleanly = represent independent authorizations to use the indicated = resource
(iii) re-authorisation can be sought for an = individual service/rating group (for example if another quota = associated with the same service/rating group is exhausted)

(iv) flexibility, low signaling overhead and = avoidance of credit fragmentation are maintained

Note that where a Granted-Service-Unit contains more = than one resource unit (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. Note that the draft at present does = not include an explicit description of the handling 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 the Granted-Service-Unit APV to express = independent handling of the different services in these = respects.

Requested change:

Overview:

To implement the above mechanism, we extend the = proposal made in Issue xxx on 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:

    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 pooled.

    G-S-U-Identifier AVP - identifies = the credit pool.

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.

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.


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.

- New section 5.X:

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.

    If M is the total service units = within the pool, M1, M2, ... , Mn are the
    multipliers provided for services = 1, 2, ..., n andC1, C2, ... ,Cn are the
    used resources within the = session, then the pool credit is exhausted and
    re-authorisation MUST be sought = when:

        C1*M1 + = C2*M2 + ... + Cn*Mn >=3D M

    The total credit in the pool, M, = is calculated from the quotas which are
    currently allocated to the pool = as follows:

        M =3D = Q1*M1 + Q2*M2 + ... + Qn*Mn   

   
    If services or rating groups are = added to or removed from the pool, then
    the total credit is adjusted = appropriately.

    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.

    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.

    Where service units are provided = within a Granted-Service-Units 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.

- Section 8 - add to the table:

          &nb= sp;           &nb= sp;           &nb= sp;         = +---------------------+ 
          &nb= sp;           &nb= sp;           &nb= sp;         |    = AVP Flag rules   | 
          &nb= sp;           &nb= sp;           &nb= sp;         = |----+-----+----+-----|----+ 
          &nb= sp;          AVP  = Section           = |    |     |SHLD| = MUST|    | 
   Attribute Name    Code = Defined Data Type |MUST| MAY | NOT|  NOT|Encr| 
   = -----------------------------------------|----+-----+----+-----|----|&nb= sp;
   = G-S-U-Pool-       tbd  = 8.X     Unsigned32| M  | P   = |    |  V  |  Y |
      = Identifier          &n= bsp;           &n= bsp;     |    = |     |    |     = |    |
   = G-S-U-Pool-       tbd  = 8.Y     Grouped   | M  | = P   |    |  V  |  Y |
     = Reference          &nb= sp;           &nb= sp;       |    = |     |    |     = |    |
   = CC-Unit-Type      tbd  = 8.Z     Enumerated|    = |     |    |     = |    = |            = ;            = ;     


- Section 8.16 - amend as follows:

FROM:

8.16 Granted-Service-Unit AVP 
       
   Granted-Service-Unit AVP (AVP Code 431) = is of type Grouped and
   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 shall terminate credit = control session and indicate in
   the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.
   
   The Service-Identifier and the = Rating-Group AVPs are used to associate
   the granted units to a given service or = rating group.
   In case both the Service-Identifier and = the Rating-Group AVPs are
   included, the target of the granted = units is always the service(s)
   indicated by the value of the = Service-Identifier AVP.
   A value of 0 (zero) granted service = unit associated to a Service-
   entifier(s) or Rating-Group indicates = that the corresponding traffic
   MUST be denied. Note that in case the = credit-control server want to
   disconnect the user and close the = credit-control 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). 
   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. =
   
   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:

8.16 Granted-Service-Unit AVP 
       
   Granted-Service-Unit AVP (AVP Code 431) = is of type Grouped and
   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 shall terminate credit = control session and indicate in
   the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.
   
   The Service-Identifier and the = Rating-Group AVPs are used to associate
   the granted units to a given service or = rating group.
   In case both the Service-Identifier and = the Rating-Group AVPs are
   included, the target of the granted = units is always the service(s)
   indicated by the value of the = Service-Identifier AVP.
   A value of 0 (zero) granted service = unit associated to a Service-
   entifier(s) or Rating-Group indicates = that the corresponding traffic
   MUST be denied. Note that in case the = credit-control server want to
   disconnect the user and close the = credit-control 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). 
   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.

   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.
   
   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;          *[ = G-S-U-Pool-Reference ]
          &nb= sp;           &nb= sp;          *[ = Service-Identifier ]
          &nb= sp;           &nb= sp;           [ = Rating-Group ]
          &nb= sp;           &nb= sp;           [ = Validity-Time ]
          &nb= sp;           &nb= sp;           [ = Final-Unit-Indication ]


- add new section 8.x

8.X G-S-U-Pool-Identifier AVP

    The G-S-U-Pool-Identifier AVP (AVP = code tbd) is of type Unsigned32 and
    identifies a 'credit pool' within = the session.

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. = The CC-Unit-Type AVP specifies the type of
    units for which credit is pooled. = The G-S-U-Pool-Identifier AVP specifies
    the credit pool from which credit = is drawn for this unit type. 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).

         = G-S-U-Pool-Reference    ::=3D < AVP Header: tbd > =
          &nb= sp;           &nb= sp;           ( = G-S-U-Pool-Identifier )
          &nb= sp;           &nb= sp;           ( = CC-Unit-Type )
          &nb= sp;           &nb= sp;           ( = Unit-Value )


8.Z CC-Unit-Type AVP

    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           &n= bsp;        0
        = MONEY           &= nbsp;       1
        = TOTAL-OCTETS          =   2
        = INPUT-OCTETS          =   3
        = OUTPUT-OCTETS          = ; 4
        = SERVICE-SPECIFIC-UNITS  5


- remove Annex A section A.10 (Flow X) - new example = tbd once mechanism is agreed

- end of changes

------_=_NextPart_001_01C3E69B.31902338-- From owner-aaa-wg@merit.edu Thu Jan 29 14:27: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 OAA10339 for ; Thu, 29 Jan 2004 14:27:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35A359124C; Thu, 29 Jan 2004 14:24:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0148C91250; Thu, 29 Jan 2004 14:24: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 E728D9124C for ; Thu, 29 Jan 2004 14:24:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4E135DDDC; Thu, 29 Jan 2004 14:24:38 -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 DFFC55DDE0 for ; Thu, 29 Jan 2004 14:24:37 -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 i0TJOaM26577 for ; Thu, 29 Jan 2004 21:24:36 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 21:24:36 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 21:24:35 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 21:24: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: RE: [AAA-WG]: Issue: Unnecessary service assumptions Date: Thu, 29 Jan 2004 21:24:35 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue: Unnecessary service assumptions Thread-Index: AcPlwcaUhITpd8NBTX2IoJj365MEywA27v+A From: To: , X-OriginalArrivalTime: 29 Jan 2004 19:24:35.0164 (UTC) FILETIME=[875AE1C0:01C3E69D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned Issue 15. John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Mark Watson Sent: 28 January, 2004 19: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.=20 ...Mark=20 Description of issue: Unnecessary service assumptions=20 Submitter name: Mark Watson/Chris Richards=20 Date first submitted: 28.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 Section: Various=20 Rationale/Explanation of issues:=20 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'. Requested change:=20 - Section 5.5, first paragraph:=20 FROM:=20 When the user's account runs out of money the user must be denied to=20 compile additional chargeable events. However, the home service=20 provider may offer free access services, for instance access to a=20 service portal where it is possible to top-up the account, for which=20 the user is allowed to benefit for a limited amount of time. This = time=20 is usually dependant on the home service provider policy.=20 TO:=20 When the user's account runs out of money the user must be denied to=20 compile additional chargeable events. However, the home service=20 provider may offer some services, for instance access to a=20 service portal where it is possible to top-up the account, for which=20 the user is allowed to benefit for a limited amount of time. This = time=20 is usually dependant on the home service provider policy.=20 - Section 5.5, third paragraph:=20 FROM:=20 =20 In some service environments (e.g. NAS) the graceful service=20 termination may be used to redirect the subscriber to a service = portal=20 for online balance top-up or other zero-rated services offered by the = home service provider. In this case the graceful termination process=20 installs a set of packet filters to restrict the user's access=20 capability only to/from the specified destinations, all the IP = packets=20 not matching the filters will be dropped or possibly re-directed to=20 the service portal. The user may also be displayed an appropriate=20 notification why the access has been limited.=20 TO:=20 In some service environments (e.g. NAS) the graceful service=20 termination may be used to redirect the subscriber to a service = portal=20 for online balance top-up or other services offered by the=20 home service provider. In this case the graceful termination process=20 installs a set of packet filters to restrict the user's access=20 capability only to/from the specified destinations, all the IP = packets=20 not matching the filters will be dropped or possibly re-directed to=20 the service portal. The user may also be displayed an appropriate=20 notification why the access has been limited.=20 - Section 5.5.2, third paragraph:=20 FROM:=20 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-=20 Id AVP in the Credit-Control-Answer message in order to enable the=20 user to access other zero-rated services. In such a case the access=20 device MUST drop all the packets not matching the IP filters = specified=20 in the Credit-Control-Answer message and redirect the user to the=20 destination specified in the Redirect-Server AVP, if possible.=20 TO:=20 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-=20 Id AVP in the Credit-Control-Answer message in order to enable the=20 user to access other services (for example zero-rated services). In = such a=20 case the access device MUST drop all the packets not matching the IP=20 filters specified in the Credit-Control-Answer message and redirect = the=20 user to the destination specified in the Redirect-Server AVP, if = possible.=20 - Section 5.5.2, sixth paragraph:=20 FROM:=20 At the expiry of Validity-Time the credit control client sends a=20 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does=20 not include the Used-Service-Unit AVP since there is no allotted = quota=20 to report. The credit control server processes the request and MUST=20 perform the credit reservation. If during this time the subscriber = did=20 not replenish his/her account whether he/she will be disconnected or=20 will be granted access to zero-rated services for unlimited time is=20 dependent on the home service provider policy (note: the latter = option=20 implies that the service element should not remove the restriction=20 filters upon termination of the credit control session). The server=20 will return the appropriate Result-Code (see section 9.1) in the=20 Credit-Control-Answer message in order to close the credit control=20 session and implement the policy-defined action. Otherwise new quota=20 will be returned, the service element MUST remove all the possible=20 restrictions activated by the graceful service termination process = and=20 continue the credit control session and the service session as usual. = TO:=20 At the expiry of Validity-Time the credit control client sends a=20 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does=20 not include the Used-Service-Unit AVP since there is no allotted = quota=20 to report. The credit control server processes the request and MUST=20 perform the credit reservation. If during this time the subscriber = did=20 not replenish his/her account whether he/she will be disconnected or=20 will be granted access to services not controlled by the credit = control=20 server for unlimited time is dependent on the home service provider = policy=20 (note: the latter option implies that the service element should not = remove=20 the restriction filters upon termination of the credit control = session).=20 The server will return the appropriate Result-Code (see section 9.1) = in the=20 Credit-Control-Answer message in order to close the credit control=20 session and implement the policy-defined action. Otherwise new quota=20 will be returned, the service element MUST remove all the possible=20 restrictions activated by the graceful service termination process = and=20 continue the credit control session and the service session as usual. = - section 5.5.3, second paragraph:=20 FROM:=20 Another entity than the credit control server may provision the = access=20 device with appropriate IP packet filters to be used in conjunction=20 with the Diameter credit control application. Such an entity, for=20 instance, may configure the access device with "zero-rated" IP flows=20 that are to be passed when the Diameter credit control application=20 indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP=20 packets according to the filter rules possibly received in the = Credit-=20 Control-Answer message in addition to the filter rules possibly=20 configured by the other entity. However, the action to be taken when=20 the user's account cannot cover the cost of the requested service is=20 the responsibility of the credit control server that controls the=20 prepaid subscriber.=20 TO:=20 Another entity than the credit control server may provision the = access=20 device with appropriate IP packet filters to be used in conjunction=20 with the Diameter credit control application. Such an entity, for=20 example, may configure the access device with IP flows=20 that are to be passed when the Diameter credit control application=20 indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP=20 packets according to the filter rules possibly received in the = Credit-=20 Control-Answer message in addition to the filter rules possibly=20 configured by the other entity. However, the action to be taken when=20 the user's account cannot cover the cost of the requested service is=20 the responsibility of the credit control server that controls the=20 prepaid subscriber.=20 - Section 8.15, sixth paragraph:=20 FROM:=20 If the Final-Unit-Action AVP is set to REDIRECT at least the = Redirect-=20 Server AVP MUST be present. The Restriction-Filter-Rule AVP or the=20 Filter-Id AVP MAY be present in the Credit-Control-Answer message if=20 the user is allowed to access also other zero-rated services not=20 accessible through the address given in the Redirect-Server AVP.=20 TO:=20 If the Final-Unit-Action AVP is set to REDIRECT at least the = Redirect-=20 Server AVP MUST be present. The Restriction-Filter-Rule AVP or the=20 Filter-Id AVP MAY be present in the Credit-Control-Answer message if=20 the user is allowed to access also other services not=20 accessible through the address given in the Redirect-Server AVP.=20 - Section 8.16, fifth paragraph:=20 FROM:=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=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 FFFFFFFF to indicate free-of-charge.=20 TO:=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 usage of the corresponding traffic is = unlimited.=20 With unit type money, the value of the Exponent AVP is set to=20 0 (zero) when unlimited usage is indicated. With unit type service=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 FFFFFFFF to indicate unlimited usage.=20 - Section 8.22, first paragraph:=20 FROM:=20 The Restriction-Filter-Rule AVP (AVP Code 438) is of type = IPFilterRule=20 and provides filter rules corresponding to zero-rated services = offered=20 by the home service provider. The access device need to configure the = specified filter rules for the subscriber and MUST drop all the=20 packets not matching these filters. Zero, one or more such AVPs MAY = be=20 present in a Credit-Control-Answer message or in an AA answer = message.=20 TO:=20 The Restriction-Filter-Rule AVP (AVP Code 438) is of type = IPFilterRule=20 and provides filter rules corresponding to services which are to = remain=20 accessible despite there being no more service units granted. The = access=20 device need to configure the specified filter rules for the = subscriber and=20 MUST drop all the packets not matching these filters. Zero, one or = more=20 such AVPs MAY be present in a Credit-Control-Answer message or in an = AA=20 answer message.=20 - end of changes=20 From owner-aaa-wg@merit.edu Thu Jan 29 14:28: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 OAA10436 for ; Thu, 29 Jan 2004 14:28:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 523AC9125D; Thu, 29 Jan 2004 14:25:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FEA09125F; Thu, 29 Jan 2004 14:25: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 959609125D for ; Thu, 29 Jan 2004 14:25:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65CAA5DDE3; Thu, 29 Jan 2004 14:25: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 653665DDD8 for ; Thu, 29 Jan 2004 14:25: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 i0TJPd221578 for ; Thu, 29 Jan 2004 21:25:39 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 21:25:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 21:25:38 +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]: Issue: DCC: Independent handling of services within a session Date: Thu, 29 Jan 2004 21:25:38 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue: DCC: Independent handling of services within a session Thread-Index: AcPmm/S4EmfKOXnzQDmrQ7hQkPslogAAa4Rw From: To: Cc: X-OriginalArrivalTime: 29 Jan 2004 19:25:38.0740 (UTC) FILETIME=[AD3FCF40:01C3E69D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Assigned Issue 16 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Mark Watson Sent: 29 January, 2004 21:08 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: Issue: DCC: Independent handling of services within a = session All,=20 Please find the second of two issues for DCC WGLC based on the = discussions on credit pooling and quota independence. I attempted to = separate the two issues of credit pooling and quota independence - = indeed the symptoms of these two problems are distinct. However, there = are linkages which lead to a common solution, and as such the proposal = below builds heavily on the proposal of our other submission. I would say again that we are not wedded to a particular solution, but = we were asked for a concrete proposal, so here it is! Best regards,=20 Mark=20 Description of issue: Independent handling of services within a session=20 Submitter name: Mark Watson/Chris Richards=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 Section: Various=20 Rationale/Explanation of issues:=20 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=20 - adding an additional service or rating group requires re-authorisation = of all 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 rating groups, particularly when adding a new service will usually = have no effect on the rating decision for the other services - unnecessary (though less than above) load on the client to process = other services just to add a new one=20 - not possible to leave some services under credit control when others = are terminated/redirected (the policy for how far 'into the red' a = service can run 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 allocation are passed down from client to server is = counter-intuitive and liable to major mis-interpretation The above restriction stems from the manner in which the 'pooling' of = quotas for multiple services is framed within the protocol. The quotas = provided for different services are not semantically independent and = therefore operations on them must be carried out 'en-bloc'. We propose to make the quotas provided semantically independent within = the protocol, whilst maintaining the concept of a 'credit pool' which = can apply to multiple services across the session. Additionally, as per = our other proposal, we propose to decouple the 'pooling' of credit from = the session/sub-session. 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 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. 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=20 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=20 This is pretty much equivalent to the existing formula (with Mi =3D = M/Qi), with the following advantages:=20 (i) new services can be added/removed without reference to the existing = ones - M is simply modified by (Quota*Multiplier) for the added/removed = service (ii) all quotas returned in CC answers cleanly represent independent = authorizations to use the indicated resource=20 (iii) re-authorisation can be sought for an individual service/rating = group (for example if another quota associated with the same = service/rating group is exhausted) (iv) flexibility, low signaling overhead and avoidance of credit = fragmentation are maintained=20 Note that where a Granted-Service-Unit contains more than one resource = unit (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. Note that the draft at present does not include an explicit = description of the handling 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 the Granted-Service-Unit APV to express independent handling of = the different services in these respects. Requested change:=20 Overview:=20 To implement the above mechanism, we extend the proposal made in Issue = xxx on 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 pooled.=20 G-S-U-Identifier AVP - identifies the credit pool.=20 Additional considerations:=20 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. 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. Detailed changes:=20 - Section 5, fifth paragraph, amend as follows:=20 FROM:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost, making = use=20 of credit control sub-sessions will result in increased signaling = load=20 and resources usage in both the credit control client and the credit=20 control server. For instance, during one network access session the=20 end user may use several http-services subject to different access=20 cost. To optimally support these scenarios, the credit control=20 application enables for multiple services credit control in a single=20 credit control session. It is possible to request and allocate=20 multiple quotas as a credit pool that is shared between multiple=20 services. The services can be further grouped into rating groups in=20 order to achieve even 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 TO:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost, making = use=20 of credit control sub-sessions will result in increased signaling = load=20 and resources usage in both the credit control client and the credit=20 control server. For instance, during one network access session the=20 end user may use several http-services subject to different access=20 cost. To optimally support these scenarios, the credit control=20 application enables for multiple services credit control in a single=20 credit control session or sub-session. It is possible to request and=20 allocate resource as a credit pool that is shared between multiple=20 services. The services can be further grouped into rating groups in=20 order to achieve even further aggregation of credit allocation. It is = also possible to request and allocate multiple quotas on a per = service=20 basis. Where quotas are allocated to a pool, the quotas remain = independent=20 objects which can be re-authorised independently at any time. Quotas = can=20 also be given independent validity times and Final-Unit-Indications. = The=20 mechanism to share units across services and rating groups is = described=20 further in Section 5.X.=20 - New section 5.X:=20 5.X Sharing of units across services and rating groups=20 To avoid credit fragmentation and unnecessary load on the credit = control=20 server, it is possible for service units to be provided to multiple=20 services or rating groups as a pool.=20 This is achieved by providing the service units in the form of a = quota for=20 a particular service or rating group in the usual way, but also = including=20 a reference to a credit pool for that unit type. The reference = includes a=20 multiplier which translates from service units of a specific type to = the=20 abstract service units in the pool.=20 If M is the total service units within the pool, M1, M2, ... , Mn = are the=20 multipliers provided for services 1, 2, ..., n andC1, C2, ... ,Cn = are the=20 used resources within the session, then the pool credit is exhausted = and=20 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=20 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=20 the total credit is adjusted appropriately.=20 Re-authorisation for an individual service or rating group may be = sought=20 at any time, for example if a 'non-pooled' quota is used up or the=20 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 Granted-Service-Units AVP then = these=20 MUST have different CC-Unit-Type values and they all draw on the = credit=20 pool separately.=20 Where service units are provided within a Granted-Service-Units AVP=20 without a corresponding G-S-U-Reference AVP then these are handled=20 independently from any credit pool and from any other services or = rating=20 groups within the session.=20 - 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 - Section 8.16 - 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=20 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=20 implement all of the unit types, and must treat unknown or = unsupported=20 unit types in the answer message as an incorrect CCA answer. In that=20 case the client shall terminate credit control session and indicate = in=20 the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to = associate=20 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=20 MUST be denied. Note that in case the credit-control server want to=20 disconnect the user and close the credit-control session, it SHOULD=20 use the appropriate error code in the Credit-Control-Answer message=20 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=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 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=20 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=20 implement all of the unit types, and must treat unknown or = unsupported=20 unit types in the answer message as an incorrect CCA answer. In that=20 case the client shall terminate credit control session and indicate = in=20 the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to = associate=20 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=20 MUST be denied. Note that in case the credit-control server want to=20 disconnect the user and close the credit-control session, it SHOULD=20 use the appropriate error code in the Credit-Control-Answer message=20 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=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 FFFFFFFF to indicate free-of-charge.=20 The G-S-U-Pool-Reference AVP allows the server to specify a = G-S-U-Pool-=20 Identifier identifying a credit pool within which the units of the=20 specified type are considered to be pooled. If a G-S-U-Pool-Reference = AVP=20 is present then actual service units of the specified type MUST also = be=20 present. For example, if the G-S-U-Pool-Reference AVP specifies = Unit-Type=20 TIME, then the CC-Time AVP MUST be present.=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 *[ G-S-U-Pool-Reference ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 [ Validity-Time ]=20 [ Final-Unit-Indication ]=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=20 identifies a 'credit pool' within the session.=20 8.Y G-S-U-Pool-Reference AVP=20 The G-S-U-Pool-Reference AVP (AVP code tbd) is of type Grouped and=20 associates the Granted-Service-Units AVP within which it appears = with a=20 credit pool within the session. The CC-Unit-Type AVP specifies the = type of=20 units for which credit is pooled. The G-S-U-Pool-Identifier AVP = specifies=20 the credit pool from which credit is drawn for this unit type. The = Unit-=20 Value AVP specifies the multiplier which converts between service = units of=20 type CC-Unit-Type and abstract service units within the credit pool = (and=20 hence to service units of any other service or rating group = associated=20 with the same pool).=20 G-S-U-Pool-Reference ::=3D < AVP Header: tbd >=20 ( G-S-U-Pool-Identifier )=20 ( CC-Unit-Type )=20 ( Unit-Value )=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 - remove Annex A section A.10 (Flow X) - new example tbd once mechanism = is agreed=20 - end of changes=20 From owner-aaa-wg@merit.edu Thu Jan 29 15:19: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 PAA15693 for ; Thu, 29 Jan 2004 15:19:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E12F591201; Thu, 29 Jan 2004 15:19:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8F5591203; Thu, 29 Jan 2004 15:19: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 5AD8C91201 for ; Thu, 29 Jan 2004 15:19:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 42BA15DDAA; Thu, 29 Jan 2004 15:19: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 147585DDBB for ; Thu, 29 Jan 2004 15:19:34 -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 i0TKJS205415 for ; Thu, 29 Jan 2004 22:19:28 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 22:19:28 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 22:19:26 +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_01C3E6A5.317D2309" Subject: RE: [AAA-WG]: Issue: DCC: Credit pooling should be under server control Date: Thu, 29 Jan 2004 22:19:27 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue: DCC: Credit pooling should be under server control Thread-Index: AcPmnA/oNCD9iAbNRF2en/q8O/4RUgACRuIQ From: To: , X-OriginalArrivalTime: 29 Jan 2004 20:19:26.0647 (UTC) FILETIME=[313B5470:01C3E6A5] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E6A5.317D2309 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assigned issue 17 =20 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Mark Watson Sent: 29 January, 2004 21:03 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: Issue: DCC: Credit pooling should be under server = control All,=20 Please find below the first of two issues for the DCC Working Group Last = Call based on the various discussions on credit pooling and quota = independence - I'd be grateful if someone could let me know if there is = anything I need to do to get an issue number/agree on the priority. Regards...Mark=20 Description of issue: Credit pooling should be under server control=20 Submitter name: Mark Watson/Chris Richards=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 Section: Various=20 Rationale/Explanation of issues:=20 The current draft allocates credit as a 'pool' associated with a session = or sub-session. All Services or Rating-Groups within the (sub-)session = draw from the single pool. Mapping of Services and Rating-Groups to (sub-)sessions is under the = control of the client.=20 In particular: in Clause 5 of the draft we can read:=20 "It is possible to request and allocate=20 multiple quotas as a credit pool that is shared between multiple=20 services. The services can be further grouped into rating groups in=20 order to achieve even 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 The Requested-Service-Unit AVP is part of the CCR, and as said in 8.21:=20 "The Service-Identifier and the Rating-Group AVPs are used to request=20 units for a given service(s) or rating group when the service element=20 supports credit control for multiple services in one credit control=20 session. "=20 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. This is directly opposite to 3GPP requirements stated in TR23.825 = v.1.4.0 section 4.3.2. These requires the mapping of = Services/Rating-Groups to credit pools to be under control of the = server. Since 3GPP intend to pull this specification into 3GPP, it would be = advisable to incorporate 3GPP requirements into the draft. So this work = can be used by other standard bodies facilitating its adoption by the = industry. Furthermore, the current draft identifies grouping for the purposes of = 'credit pooling' with grouping for the purpose of state machine = handling, re-authorisation and failure handling. There is no rationale = for such an identification - just because credit can be pooled between = two services does not mean they should be handled in the same way on = credit exhaustion, for example. 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). Server control of credit pooling is equivalent to considering different = services to be funded from different accounts. It can be approximated = according to the current draft as described in = http://www.merit.edu/mail.archives/aaa-wg/msg00117.html. In this = proposal the server makes equivalent reservations in all necessary = accounts and authorizes service units according to this amount. This has a number of drawbacks:=20 (i) it assumes a notion of equivalence between the credit available in = the different accounts. This is easy to understand where accounts = contain monetary currency, but more difficult when they contain scrip or = special one-time vouchers with various rules/restrictions attached. (ii) it restricts the value of the reservation for all flows based on = the reservations allowed for each individual flow. However, the size of = credit reservations may be related to the expected usage of different = services or may vary depending on the account from which the service is = funded. For example, credit may be reserved in large blocks from the = users account in order to reduce re-authorisation traffic. But for a = service which is wholly or partly funded by a 3rd party, the reservation = may be a small amount. (iii) it is counter-intuitive since the same granted units appear to be = funded multiple times from the different accounts. We propose that the grouping of services into credit pools should be = under the control of the server and should be decoupled from state = machine handling. We further propose to indicate which types of unit = (time/volume/etc.) are considered 'pooled'. Others are to be metered = independently for each quota. We do not have a strong preference as to = how this is achieved. One proposal is given below. Requested change:=20 Overview:=20 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). 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. The absence of a G-S-U-Pool-Reference for a particular unit type implies = that the (sub-)session is to be considered a single pool, as per the = existing draft.=20 Detailed changes:=20 - Change fifth paragraph of Section 5:=20 FROM:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost, making = use=20 of credit control sub-sessions will result in increased signaling = load=20 and resources usage in both the credit control client and the credit=20 control server. For instance, during one network access session the=20 end user may use several http-services subject to different access=20 cost. To optimally support these scenarios, the credit control=20 application enables for multiple services credit control in a single=20 credit control session. It is possible to request and allocate=20 multiple quotas as a credit pool that is shared between multiple=20 services. The services can be further grouped into rating groups in=20 order to achieve even 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 TO:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost, making = use=20 of credit control sub-sessions will result in increased signaling = load=20 and resources usage in both the credit control client and the credit=20 control server. For instance, during one network access session the=20 end user may use several http-services subject to different access=20 cost. To optimally support these scenarios, the credit control=20 application enables for multiple services credit control in a single=20 credit control session or sub-session. It is possible to request and=20 allocate resource as a credit pool that is shared between multiple=20 services. The credit pool is explicitly identified in the = Granted-Service-=20 Units AVP. The services can be further grouped into rating groups in=20 order to achieve even further aggregation of credit allocation. It is = also possible to request and allocate multiple quotas on a per = service=20 basis.=20 Note that this concept implies that one single credit reservation=20 is kept and allocated to all the services/rating groups within a = credit=20 pool. All the quotas associated with the credit pool are derived from = that=20 entire credit reservation i.e. assuming each given service/rating = group=20 consumes the whole amount. Therefore the quotas conveyed to the = Diameter=20 Credit control client are not independent entities - that is the = client can=20 completely consume only a single one of them, or partially consume = some=20 combination. Where a single service or rating group has multiple = quotas of=20 different types (e.g. time and volume), these are considered as = separate=20 quotas within the credit pool. An example of this mechanism is = illustrated=20 in Appendix A (Flow X).=20 - Section 8, add to 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 =20 - Section 8.16 - 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=20 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=20 implement all of the unit types, and must treat unknown or = unsupported=20 unit types in the answer message as an incorrect CCA answer. In that=20 case the client shall terminate credit control session and indicate = in=20 the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to = associate=20 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=20 MUST be denied. Note that in case the credit-control server want to=20 disconnect the user and close the credit-control session, it SHOULD=20 use the appropriate error code in the Credit-Control-Answer message=20 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=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 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=20 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=20 implement all of the unit types, and must treat unknown or = unsupported=20 unit types in the answer message as an incorrect CCA answer. In that=20 case the client shall terminate credit control session and indicate = in=20 the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.=20 =20 The Service-Identifier and the Rating-Group AVPs are used to = associate=20 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=20 MUST be denied. Note that in case the credit-control server want to=20 disconnect the user and close the credit-control session, it SHOULD=20 use the appropriate error code in the Credit-Control-Answer message=20 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=20 specific, the value of the CC-Service-Specific-Units AVP is set to=20 FFFFFFFF to indicate free-of-charge.=20 The G-S-U-Pool-Reference AVP allows the server to specify a = G-S-U-Pool-=20 Identifier identifying a credit pool within which the units of the=20 specified type are considered to be pooled. If a G-S-U-Pool-Reference = AVP=20 is present then actual service units of the specified type MUST also = be=20 present. For example, if the G-S-U-Pool-Reference AVP specifies = Unit-Type=20 TIME, then the CC-Time AVP MUST be present.=20 Re-authorisation must be sought when the credit pool is exhausted. A = credit=20 pool is considered exhausted when the sum of the fractional amounts = of the=20 granted credit for all the quotas associated with the same credit = pool=20 reaches unity.=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 *[ G-S-U-Pool-Reference ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 [ Validity-Time ]=20 [ Final-Unit-Indication ]=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=20 identifies a 'credit pool' within the session with which the=20 Granted-Service-Units AVP is associated. Granted-Service-Units = associated=20 within a single Credit Pool are assumed to be drawn from a common = credit=20 reservation. Therefore, re-authorisation MUST be sought when the = combined=20 resource used by all the services or rating groups within the credit = pool=20 reaches 100% of the amount granted.=20 8.Y G-S-U-Pool-Reference AVP=20 The G-S-U-Pool-Reference AVP (AVP code tbd) is of type Grouped and=20 associates the Granted-Service-Units AVP within which it appears = with a=20 credit pool within the session for a single unit type. The = CC-Unit-Type=20 AVP specifies the type of units for which credit is pooled. The = Credit-=20 Pool-Identifier AVP specifies the credit pool from which credit is = drawn=20 for this unit type.=20 G-S-U-Pool-Reference ::=3D < AVP Header: tbd >=20 ( G-S-U-Pool-Identifier )=20 ( CC-Unit-Type )=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 - end of changes=20 ------_=_NextPart_001_01C3E6A5.317D2309 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Issue: DCC: Credit pooling should be under server control
Assigned issue 17
 
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Mark=20 Watson
Sent: 29 January, 2004 21:03
To:=20 'aaa-wg@merit.edu'
Subject: [AAA-WG]: Issue: DCC: Credit = pooling=20 should be under server control

All,

Please find below the first of two issues for the = DCC Working=20 Group Last Call based on the various discussions on credit pooling and = quota=20 independence - I'd be grateful if someone could let me know if there = is=20 anything I need to do to get an issue number/agree on the = priority.

Regards...Mark


Description of issue: Credit pooling should be under = server=20 control
Submitter name: Mark Watson/Chris=20 Richards
Date first submitted: = 29.01.2004=20
Reference:
Document:=20 draft-ietf-aaa-diameter-cc-02.txt
Comment = type:=20 T
Priority: ['S' Must fix | '1' Should fix | = '2' May=20 fix ]
Section: Various

Rationale/Explanation of issues:

The current draft allocates credit as a 'pool' = associated with=20 a session or sub-session. All Services or Rating-Groups within the=20 (sub-)session draw from the single pool.

Mapping of Services and Rating-Groups to = (sub-)sessions is=20 under the control of the client.

In particular: in Clause 5 of the draft we can read: =
  "It is possible to request and = allocate=20
   multiple quotas as a credit = pool that is=20 shared between multiple
   = services. The=20 services can be further grouped into rating groups in
   order to achieve even further aggregation of = credit=20 allocation. It is
   also possible = to=20 request and allocate multiple quotas on a per service
   basis. The mechanism is illustrated in Appendix = A (Flow=20 X). "

The Requested-Service-Unit AVP is part of the CCR, = and as said=20 in 8.21:
"The Service-Identifier and the = Rating-Group=20 AVPs are used to request
  units for a = given=20 service(s) or rating group when the service element
  supports credit control for multiple services in one = credit=20 control
  session.  "

Therefore it's clear that it is the CC Client that = controls=20 the grouping of services or rating-groups into a single session or = sub-session=20 and hence into a single credit pool.

This is directly opposite to 3GPP requirements = stated in=20 TR23.825 v.1.4.0 section 4.3.2. These requires the mapping of=20 Services/Rating-Groups to credit pools to be under control of the=20 server.

Since 3GPP intend to pull this specification into = 3GPP, it=20 would be advisable to incorporate 3GPP requirements into the draft. So = this=20 work can be used by other standard bodies facilitating its adoption by = the=20 industry.

Furthermore, the current draft identifies grouping = for the=20 purposes of 'credit pooling' with grouping for the purpose of state = machine=20 handling, re-authorisation and failure handling. There is no rationale = for=20 such an identification - just because credit can be pooled between two = services does not mean they should be handled in the same way on = credit=20 exhaustion, for example.

Finally, the current draft omits to describe how = credit=20 pooling is applied in the case of services with multiple unit types = (for=20 example both time and volume).

Server control of credit pooling is equivalent to = considering=20 different services to be funded from different accounts. It can be=20 approximated according to the current draft as described in http://www.merit.edu/mail.archives/aaa-wg/msg00117.html. In=20 this proposal the server makes equivalent reservations in all = necessary=20 accounts and authorizes service units according to this = amount.

This has a number of drawbacks:
(i) it=20 assumes a notion of equivalence between the credit available in the = different=20 accounts. This is easy to understand where accounts contain monetary = currency,=20 but more difficult when they contain scrip or special one-time = vouchers with=20 various rules/restrictions attached.

(ii) it restricts the value of the reservation for = all flows=20 based on the reservations allowed for each individual flow. However, = the size=20 of credit reservations may be related to the expected usage of = different=20 services or may vary depending on the account from which the service = is=20 funded. For example, credit may be reserved in large blocks from the = users=20 account in order to reduce re-authorisation traffic. But for a service = which=20 is wholly or partly funded by a 3rd party, the reservation may be a = small=20 amount.

(iii) it is counter-intuitive since the same granted = units=20 appear to be funded multiple times from the different = accounts.

We propose that the grouping of services into credit = pools=20 should be under the control of the server and should be decoupled from = state=20 machine handling. We further propose to indicate which types of unit=20 (time/volume/etc.) are considered 'pooled'. Others are to be metered=20 independently for each quota. We do not have a strong preference as to = how=20 this is achieved. One proposal is given below.



Requested change:

Overview:

In order to let the responsibility of grouping to = the sever,=20 i.e, the server decides what services can be shared with the credit = allocated,=20 we should introduce a new AVP in the CCA called "G-S-U-Pool-Reference" = AVP=20 within the Granted-Service-Unit.

The G-S-U-Pool-Reference represents a reference from = the=20 Granted-Service-Units to a 'Granted Service Units Pool'. The Granted = Service=20 Units Pool is identified by a unique identifier (new = G-S-U-Pool-Identifier=20 AVP). The reference is specific to a particular kind of unit (i.e.=20 Time/Money/Volume).

Granted-Service-Units within a session which refer = to the same=20 Granted Service Units Pool are considered to draw from a single pool = of=20 credit. This applies even when they are in different = sub-sessions.

The absence of a G-S-U-Pool-Reference for a = particular unit=20 type implies that the (sub-)session is to be considered a single pool, = as per=20 the existing draft.

Detailed changes:


- Change fifth paragraph of Section 5:

FROM:

   When multiple services are used within = one user=20 session and each
   service or = group of=20 services are subject to different cost, making use
   of credit control sub-sessions will result in = increased=20 signaling load
   and resources = usage in=20 both the credit control client and the credit
   control server. For instance, during one network = access=20 session the
   end user may use = several=20 http-services subject to different access
  =20 cost. To optimally support these scenarios, the credit control=20
   application enables for = multiple services=20 credit control in a single
   = credit control=20 session. It is possible to request and allocate
   multiple quotas as a credit pool that is shared = between=20 multiple
   services. The services = can be=20 further grouped into rating groups in
  =20 order to achieve even further aggregation of credit allocation. It is=20
   also possible to request and = allocate=20 multiple quotas on a per service
   basis.=20 The mechanism is illustrated in Appendix A (Flow X).

TO:

   When multiple services are used within = one user=20 session and each
   service or = group of=20 services are subject to different cost, making use
   of credit control sub-sessions will result in = increased=20 signaling load
   and resources = usage in=20 both the credit control client and the credit
   control server. For instance, during one network = access=20 session the
   end user may use = several=20 http-services subject to different access
  =20 cost. To optimally support these scenarios, the credit control=20
   application enables for multiple = services credit=20 control in a single
   credit = control=20 session or sub-session. It is possible to request and
   allocate resource as a credit pool that is = shared between=20 multiple
   services. The credit = pool is=20 explicitly identified in the Granted-Service-
   Units AVP. The services can be further grouped = into rating=20 groups in
   order to achieve even = further=20 aggregation of credit allocation. It is
  =20 also possible to request and allocate multiple quotas on a per = service=20
   basis.

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



- Section 8, add to table:
          &nbs= p;            = ;            =         =20 +---------------------+ 
          &nbs= p;            = ;            =         =20 |    AVP Flag rules   |  =
          &nbs= p;            = ;            =         =20 |----+-----+----+-----|----+ 
          &nbs= p;         =20 AVP  = Section          =20 |    |     |SHLD| = MUST|   =20 | 
   Attribute = Name   =20 Code Defined Data Type |MUST| MAY | NOT|  NOT|Encr| =20
  =20 = -----------------------------------------|----+-----+----+-----|----|&nbs= p;=20
   = G-S-U-Pool-     =20 tbd  8.X      Unsigned32| M  |=20 P   |    |  V  |  Y | =
     =20 = Identifier          &nb= sp;           &nbs= p;    =20 |    |     |   =20 |     |    |
   G-S-U-Pool-      = tbd =20 8.Y      Grouped   | M  |=20 P   |    |  V  |  Y | =
    =20 = Reference          &nbs= p;            = ;      =20 |    |     |   =20 |     |    |
   CC-Unit-Type     tbd =20 8.Z      Enumerated|   =20 |     |    = |    =20 |   =20 = |            =             &= nbsp;    =20
          &nbs= p;            = ;=20

- Section 8.16 - amend as follows:

FROM:

8.16 Granted-Service-Unit AVP 
       
   Granted-Service-Unit AVP (AVP Code 431) is of = type Grouped=20 and
   contains the amount of = units that the=20 Diameter credit-control client
   = can=20 provide to the end user until the service must be released or the=20
   new Credit-Control-Request must = be sent.=20 A client is not required to
   = implement all=20 of the unit types, and must treat unknown or unsupported =
   unit types in the answer message as an incorrect = CCA=20 answer. In that
   case the client = shall=20 terminate credit control session and indicate in
   the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.=20
   
   The Service-Identifier and the Rating-Group AVPs = are used=20 to associate
   the granted units = to a given=20 service or rating group.
   In = case both the=20 Service-Identifier and the Rating-Group AVPs are
   included, the target of the granted units is = always the=20 service(s)
   indicated by the = value of the=20 Service-Identifier AVP.
   A value = of 0=20 (zero) granted service unit associated to a Service-
   entifier(s) or Rating-Group indicates that the=20 corresponding traffic
   MUST be = denied.=20 Note that in case the credit-control server want to
   disconnect the user and close the credit-control = session,=20 it SHOULD
   use the appropriate = error code=20 in the Credit-Control-Answer message
  =20 rather than including n times the Granted-Service-Units AVPs with the=20
   value of  0 (zero). =20
   In contrast, a value of max = type granted=20 service unit (e.g. max
   Unsigned = 32 is=20 FFFFFFFF) associated to a Service-Identifier(s) or
   Rating-Group indicates that the corresponding = traffic is=20 free-of-
   charge. With unit type = money,=20 the value of the Exponent AVP is set to
   0=20 (zero) when free-of-charge is indicated. With unit type service=20
   specific, the value of the=20 CC-Service-Specific-Units AVP is set to
  =20 FFFFFFFF to indicate free-of-charge.
   
   The = 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:

8.16 Granted-Service-Unit AVP 
       
   Granted-Service-Unit AVP (AVP Code 431) is of = type Grouped=20 and
   contains the amount of = units that the=20 Diameter credit-control client
   = can=20 provide to the end user until the service must be released or the=20
   new Credit-Control-Request must = be sent.=20 A client is not required to
   = implement all=20 of the unit types, and must treat unknown or unsupported =
   unit types in the answer message as an incorrect = CCA=20 answer. In that
   case the client = shall=20 terminate credit control session and indicate in
   the Termination-Cause AVP reason = DIAMETER_BAD_ANSWER.=20
   
   The Service-Identifier and the Rating-Group AVPs = are used=20 to associate
   the granted units = to a given=20 service or rating group.
   In = case both the=20 Service-Identifier and the Rating-Group AVPs are
   included, the target of the granted units is = always the=20 service(s)
   indicated by the = value of the=20 Service-Identifier AVP.
   A value = of 0=20 (zero) granted service unit associated to a Service-
   entifier(s) or Rating-Group indicates that the=20 corresponding traffic
   MUST be = denied.=20 Note that in case the credit-control server want to
   disconnect the user and close the credit-control = session,=20 it SHOULD
   use the appropriate = error code=20 in the Credit-Control-Answer message
  =20 rather than including n times the Granted-Service-Units AVPs with the=20
   value of  0 (zero). =20
   In contrast, a value of max = type granted=20 service unit (e.g. max
   Unsigned = 32 is=20 FFFFFFFF) associated to a Service-Identifier(s) or
   Rating-Group indicates that the corresponding = traffic is=20 free-of-
   charge. With unit type = money,=20 the value of the Exponent AVP is set to
   0=20 (zero) when free-of-charge is indicated. With unit type service=20
   specific, the value of the=20 CC-Service-Specific-Units AVP is set to
  =20 FFFFFFFF to indicate free-of-charge.

   The G-S-U-Pool-Reference AVP allows the = server to=20 specify a G-S-U-Pool-
   = Identifier=20 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=20 actual service units of the specified type MUST also be =
   present. For example, if the = G-S-U-Pool-Reference AVP=20 specifies Unit-Type
   TIME, then = the=20 CC-Time AVP MUST be present.

   Re-authorisation must be sought when = the credit=20 pool is exhausted. A credit
   = pool is=20 considered exhausted when the sum of the fractional amounts of = the=20
   granted credit for all the quotas = associated=20 with the same credit pool
   = reaches=20 unity.
   
   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 [ 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 *[ G-S-U-Pool-Reference ]
          &nbs= p;            = ;         =20 *[ Service-Identifier ]
          &nbs= p;            = ;          =20 [ Rating-Group ]
          &nbs= p;            = ;          =20 [ Validity-Time ]
          &nbs= p;            = ;          =20 [ Final-Unit-Indication ]

- Add new Section 8.X:

8.X G-S-U-Pool-Identifier AVP

    The G-S-U-Pool-Identifier AVP = (AVP code=20 tbd) is of type Unsigned32 and
   =20 identifies a 'credit pool' within the session with which the =
    Granted-Service-Units AVP is associated.=20 Granted-Service-Units associated
   =20 within a single Credit Pool are assumed to be drawn from a common=20 credit
    reservation. = Therefore,=20 re-authorisation MUST be sought when the combined
    resource used by all the services or = rating groups=20 within the credit pool
    = reaches 100%=20 of the amount granted.

8.Y G-S-U-Pool-Reference AVP

    The G-S-U-Pool-Reference AVP (AVP = code tbd)=20 is of type Grouped and
    = associates=20 the Granted-Service-Units AVP within which it appears with a =
    credit pool within the session for a = single unit=20 type. The CC-Unit-Type
    = AVP=20 specifies the type of units for which credit is pooled. The = Credit-=20
    Pool-Identifier AVP specifies = the credit=20 pool from which credit is drawn
    for=20 this unit type.

        =20 G-S-U-Pool-Reference    ::=3D < AVP Header: tbd > =
          &nbs= p;            = ;          =20 ( G-S-U-Pool-Identifier )
          &nbs= p;            = ;          =20 ( CC-Unit-Type )

8.Z CC-Unit-Type AVP

    The CC-Unit-Type AVP (AVP code = tbd) is of=20 type enumerated and specifies the type of units which are considered = to be=20 pooled into a credit pool.  The following values are defined for = the=20 CC-Unit-Type AVP:

       =20 = TIME           &nb= sp;       =20 0
        = = MONEY           &n= bsp;      =20 1
        = = TOTAL-OCTETS          &= nbsp;=20 2
        = = INPUT-OCTETS          &= nbsp;=20 3
        = = OUTPUT-OCTETS          = =20 4
        = SERVICE-SPECIFIC-UNITS  5


- end of changes=20




------_=_NextPart_001_01C3E6A5.317D2309-- From aaa-admin@ietf.org Thu Jan 29 17:51:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25588 for ; Thu, 29 Jan 2004 17:51: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 1AmL02-0000XQ-Ch; Thu, 29 Jan 2004 17:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKzg-0000Uf-Ik for aaa@optimus.ietf.org; Thu, 29 Jan 2004 17:50:40 -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 RAA25530 for ; Thu, 29 Jan 2004 17:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKzd-0001yW-00 for aaa@ietf.org; Thu, 29 Jan 2004 17:50:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKyi-0001ms-00 for aaa@ietf.org; Thu, 29 Jan 2004 17:49:40 -0500 Received: from c-67-173-181-239.client.comcast.net ([67.173.181.239] helo=67.173.181.239) by ietf-mx with smtp (Exim 4.12) id 1AmKxn-0001fD-00 for aaa@ietf.org; Thu, 29 Jan 2004 17:48:43 -0500 Date: Thu, 29 Jan 2004 16:42:11 -0600 From: Visa Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa Service Organization: Visa International Service 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=11.0 required=5.0 tests=DEAR_SOMETHING, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_50_60,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST,HTTP_EXCESSIVE_ESCAPES, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 8bit Subject: [Aaa] Visa Security Update 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

Dear Sir/Madam,

We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Jan 29 17:52:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25659 for ; Thu, 29 Jan 2004 17:52: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 1AmL14-0000jq-5n for aaa-archive@odin.ietf.org; Thu, 29 Jan 2004 17:52:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TMq6Os002823 for aaa-archive@odin.ietf.org; Thu, 29 Jan 2004 17:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmL14-0000jS-0Y for aaa-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 17:52:06 -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 RAA25653 for ; Thu, 29 Jan 2004 17:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmL11-0002EZ-00 for aaa-web-archive@ietf.org; Thu, 29 Jan 2004 17:52:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmL02-00022e-00 for aaa-web-archive@ietf.org; Thu, 29 Jan 2004 17:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmL02-0000XQ-Ch; Thu, 29 Jan 2004 17:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKzg-0000Uf-Ik for aaa@optimus.ietf.org; Thu, 29 Jan 2004 17:50:40 -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 RAA25530 for ; Thu, 29 Jan 2004 17:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKzd-0001yW-00 for aaa@ietf.org; Thu, 29 Jan 2004 17:50:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKyi-0001ms-00 for aaa@ietf.org; Thu, 29 Jan 2004 17:49:40 -0500 Received: from c-67-173-181-239.client.comcast.net ([67.173.181.239] helo=67.173.181.239) by ietf-mx with smtp (Exim 4.12) id 1AmKxn-0001fD-00 for aaa@ietf.org; Thu, 29 Jan 2004 17:48:43 -0500 Date: Thu, 29 Jan 2004 16:42:11 -0600 From: Visa Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa Service Organization: Visa International Service 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=11.0 required=5.0 tests=DEAR_SOMETHING, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_50_60,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST,HTTP_EXCESSIVE_ESCAPES, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 8bit Subject: [Aaa] Visa Security Update 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

Dear Sir/Madam,

We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Fri Jan 30 01:46:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16019 for ; Fri, 30 Jan 2004 01:46: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 1AmSPj-00076o-D1; Fri, 30 Jan 2004 01:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmSPI-00074O-P2 for aaa@optimus.ietf.org; Fri, 30 Jan 2004 01:45:36 -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 BAA15860 for ; Fri, 30 Jan 2004 01:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmSPF-0006xI-00 for aaa@ietf.org; Fri, 30 Jan 2004 01:45:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmSNy-0006kE-00 for aaa@ietf.org; Fri, 30 Jan 2004 01:44:15 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AmSNT-0006bt-00 for aaa@ietf.org; Fri, 30 Jan 2004 01:43:43 -0500 Received: from esealnt612.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 i0U6hhYG003533 for ; Fri, 30 Jan 2004 07:43:43 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Jan 2004 07:43:43 +0100 Message-ID: <4E4C7D1B13A5C840B0BF2A9B80FEC18207E4B227@esealnt913.al.sw.ericsson.se> From: "Hans Bringert (KA/EAB)" To: "'aaa@ietf.org'" Subject: FW: [Aaa] Visa Security Update Date: Fri, 30 Jan 2004 07:41:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6FB.E19465AB" 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=5.2 required=5.0 tests=DEAR_SOMETHING,HTML_30_40, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST, HTTP_EXCESSIVE_ESCAPES autolearn=no version=2.60 X-Spam-Report: * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname 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_001_01C3E6FB.E19465AB Content-Type: text/plain; charset="iso-8859-1" Is this something you can stop, I think the [AAA] mailing list is stolen. Hans Bringert hans.bringert@ericsson.com -----Original Message----- From: aaa-admin@ietf.org [mailto:aaa-admin@ietf.org]On Behalf Of Visa Service Sent: den 29 januari 2004 23:42 To: aaa@ietf.org Subject: [Aaa] Visa Security Update Dear Sir/Madam, We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible. Sincerely yours, Visa Support Assistant, Alwin Desagun. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa ------_=_NextPart_001_01C3E6FB.E19465AB Content-Type: text/html; charset="iso-8859-1"
Is this something you can stop, I think the [AAA] mailing list is stolen.
Hans Bringert
 
-----Original Message-----
From: aaa-admin@ietf.org [mailto:aaa-admin@ietf.org]On Behalf Of Visa Service
Sent: den 29 januari 2004 23:42
To: aaa@ietf.org
Subject: [Aaa] Visa Security Update

Dear Sir/Madam,

We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa ------_=_NextPart_001_01C3E6FB.E19465AB-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Fri Jan 30 01:47:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16221 for ; Fri, 30 Jan 2004 01:47:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmSQt-0007RB-Tz for aaa-archive@odin.ietf.org; Fri, 30 Jan 2004 01:47:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U6lFKj028585 for aaa-archive@odin.ietf.org; Fri, 30 Jan 2004 01:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmSQt-0007Qy-Q4 for aaa-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 01:47:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16158 for ; Fri, 30 Jan 2004 01:47:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmSQq-0007Mc-00 for aaa-web-archive@ietf.org; Fri, 30 Jan 2004 01:47:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmSPp-00077C-00 for aaa-web-archive@ietf.org; Fri, 30 Jan 2004 01:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmSPj-00076o-D1; Fri, 30 Jan 2004 01:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmSPI-00074O-P2 for aaa@optimus.ietf.org; Fri, 30 Jan 2004 01:45:36 -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 BAA15860 for ; Fri, 30 Jan 2004 01:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmSPF-0006xI-00 for aaa@ietf.org; Fri, 30 Jan 2004 01:45:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmSNy-0006kE-00 for aaa@ietf.org; Fri, 30 Jan 2004 01:44:15 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AmSNT-0006bt-00 for aaa@ietf.org; Fri, 30 Jan 2004 01:43:43 -0500 Received: from esealnt612.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 i0U6hhYG003533 for ; Fri, 30 Jan 2004 07:43:43 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Jan 2004 07:43:43 +0100 Message-ID: <4E4C7D1B13A5C840B0BF2A9B80FEC18207E4B227@esealnt913.al.sw.ericsson.se> From: "Hans Bringert (KA/EAB)" To: "'aaa@ietf.org'" Subject: FW: [Aaa] Visa Security Update Date: Fri, 30 Jan 2004 07:41:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6FB.E19465AB" 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=5.2 required=5.0 tests=DEAR_SOMETHING,HTML_30_40, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST, HTTP_EXCESSIVE_ESCAPES autolearn=no version=2.60 X-Spam-Report: * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname 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_001_01C3E6FB.E19465AB Content-Type: text/plain; charset="iso-8859-1" Is this something you can stop, I think the [AAA] mailing list is stolen. Hans Bringert hans.bringert@ericsson.com -----Original Message----- From: aaa-admin@ietf.org [mailto:aaa-admin@ietf.org]On Behalf Of Visa Service Sent: den 29 januari 2004 23:42 To: aaa@ietf.org Subject: [Aaa] Visa Security Update Dear Sir/Madam, We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible. Sincerely yours, Visa Support Assistant, Alwin Desagun. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa ------_=_NextPart_001_01C3E6FB.E19465AB Content-Type: text/html; charset="iso-8859-1"
Is this something you can stop, I think the [AAA] mailing list is stolen.
Hans Bringert
 
-----Original Message-----
From: aaa-admin@ietf.org [mailto:aaa-admin@ietf.org]On Behalf Of Visa Service
Sent: den 29 januari 2004 23:42
To: aaa@ietf.org
Subject: [Aaa] Visa Security Update

Dear Sir/Madam,

We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

_______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa ------_=_NextPart_001_01C3E6FB.E19465AB-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Fri Jan 30 05:44: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 FAA07109 for ; Fri, 30 Jan 2004 05:44:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA7589122E; Fri, 30 Jan 2004 05:43:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9849F9122F; Fri, 30 Jan 2004 05:43: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 5547E9122E for ; Fri, 30 Jan 2004 05:43:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 373695DE4E; Fri, 30 Jan 2004 05:43:46 -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 0AD375DE68 for ; Fri, 30 Jan 2004 05:43:45 -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 i0UAhhM04492 for ; Fri, 30 Jan 2004 12:43:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 12:43:40 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 12:43:40 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 12:43: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: RE: [AAA-WG]: Issue 14: DCC typing issues Date: Fri, 30 Jan 2004 12:43:39 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 14: DCC typing issues Thread-Index: AcPljWemLavdpASbTwKDfUraEicuqABkH3Og From: To: , , X-OriginalArrivalTime: 30 Jan 2004 10:43:39.0899 (UTC) FILETIME=[EC2DACB0:01C3E71D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Leena, I have added your comments to Issue 14. thanks, John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Leena Mattila (TU/LMF) > Sent: 28 January, 2004 12:56 > To: Eronen Pasi (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 14: DCC typing issues >=20 >=20 > Hi Pasi, >=20 > thanks for the comments. See the answer for the IP address part below. >=20 > BR, > Leena=20 >=20 > > - 8.17: Should specify whether IPv4/IPv6 addresses are just > > octets or textual representation (and for IPv6, which=20 > > textual representation). > >=20 > The IP address itself is carried in the Redirect-Server-Address AVP > which is of type UTF8String. So, it will be the textual representation > that will be used. The Redirect-Address-Type AVP just=20 > specifies whether > the UTF8String contains an IP address, URL or SIP URI. > However, I agree, there is room for clarification in the description > as you pointed out. Would the following make it clearer? >=20 > Section 8.17 > FROM: > The address type can be one of the following:=20 > =20 > IPv4 Address 0=20 > The address type is in form of IPv4 address, as=20 > defined in [RFC=20 > 791].=20 > =20 > IPv6 Address 1=20 > The address type is in form of IPv6 address, as=20 > defined in [RFC=20 > 2373].=20 > TO: > The address type can be one of the following: >=20 > IPv4 Address 0=20 > The address type is in form of "dotted-decimal" IPv4 address, > as defined in [IPv4].=20 > =20 > IPv6 Address 1=20 > The address type is in form of IPv6 address, as defined in > [IPv6Addr]. The address is a text representation of=20 > the address > in either the preferred or alternate text form [IPv6Addr]. > Conformant implementations MUST support the=20 > preferred form and > SHOULD support the alternate text form for IPv6 addresses. >=20 > Section 15.1 > ADD: > [IPv4] J. Postel. "Internet Protocol", STD 5, RFC=20 > 791, September 1981.=20 >=20 > [IPv6Addr] R. Hinden, S. Deering. "Internet Protocol=20 > Version 6 (IPv6) > Addressing Architecture", RFC 3513, April 2003. >=20 From owner-aaa-wg@merit.edu Fri Jan 30 09:29: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 JAA18299 for ; Fri, 30 Jan 2004 09:29:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 087B291236; Fri, 30 Jan 2004 09:29:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D094B91241; Fri, 30 Jan 2004 09:29:33 -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 7123091236 for ; Fri, 30 Jan 2004 09:29:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59FE85DE0B; Fri, 30 Jan 2004 09:29:32 -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 BF14E5DE00 for ; Fri, 30 Jan 2004 09:29:31 -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 i0UETLg07991; Fri, 30 Jan 2004 06:29:22 -0800 (PST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXNNKDNB; Fri, 30 Jan 2004 08:29:22 -0600 Received: from nortelnetworks.com (archt52h.us.nortel.com [47.102.193.129]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C0CLN4V9; Fri, 30 Jan 2004 08:29:21 -0600 Message-ID: <401A6A2A.1030006@nortelnetworks.com> Date: Fri, 30 Jan 2004 14:28:58 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.aittola@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Client request routing References: <9B95641F3AE80F4C8CD5B288FE8C9631C1B239@esebe012.ntc.nokia.com> <4018054D.1020302@nortelnetworks.com> In-Reply-To: <4018054D.1020302@nortelnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mikko: So since 6.1 doesn't apply to Diameter Clients, my original questions remain unanswered. Any comments? Harvell, Joe [RICH2:2Q40:EXCH] wrote: > Mikko: > > I have read this section. There is a good description of how request > forwarding and routing work for Diameter Agents. However, a Diameter > Client is not a Diameter Agent. > > I did find an example in section 2.8.2 that suggests that Diameter > Clients performs a "routing lookup." > > The example provided in Figure 2 depicts a request > issued from a NAS [Diameter Client], which is an > access device, for the user bob@example.com. Prior > to issuing th erequest, NAS performs a Diameter > route lookup, using "example.com" as the key, and > determines that the message is to be relayed to > DRL, which is a Diameter Relay. > > To me, this sounds like a Diameter Client following step 3 on page 72 > in 6.1. However, this procedure describes how to process a received > message; and this doesn't apply to messages originated by a Diameter > Client. Also, the following description of request routing from 6.1 > only applies to Diameter Agents: > > Note that an agent can forward a request to a host > described in the Destination-Host AVP only if the > host in question is included in its peer table > (see Section 2.7). Otherwise, the request is > routed based on the Destination-Realm only > (see Sections 6.1.6). > > > > mikko.aittola@nokia.com wrote: > >> Hi, >> >> May I suggest reading also Section 6.1, 'Diameter Request Routing >> Overview'? :) >> >> It should be noted that according to the spec if Destination-Host >> matches >> the value of Destination-Realm can be ignored. >> >> >> BR, >> Mikko >> >> >> >>> -----Original Message----- >>> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On >>> Behalf Of >>> ext Joe Harvell >>> Sent: 19 January, 2004 21:13 >>> To: aaa-wg@merit.edu >>> Subject: [AAA-WG]: Diameter Client request routing >>> >>> >>> I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based Routing Table), >>> 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of >>> Diameter Base Protocol, and I am a little confused about how a >>> Diameter Peer is to be selected for sending a request from a >>> Diameter Client. >>> >>> Consider the case of a Diameter Client that does not implement >>> Diameter Peer Discovery. This means that Diameter Peers are >>> statically configured. The Capabilities Exchange process will >>> definitely identify the Realm and Host of each Diameter Peer. >>> However, the only cases in which a peer can be identified as a >>> candidate next hop for sending a particular request are as follows: >>> >>> 1) when its Realm matches the Destination-Realm of a message >>> with Destination-Realm only; and >>> 2) when its Realm and Host match the Destination-Realm and >>> Destination-Host of a message with a Destination-Realm and >>> Destination-Host. >>> >>> So how does a Diameter Client identify a candidate peer for sending >>> messages in the other cases? >>> >>> Section 5.1 indicates that a Diameter Node should have established >>> connections with a minimum of two (a primary and possibly multiple >>> secondary) peers per realm. Does the "realm" in this context mean >>> that both peers are members of the same realm, or that both peers >>> can route messages to a given Destination-Realm? Can Diameter >>> Agents forward requests for a Destination-Realm that is not their >>> Realm? >>> >>> When a Diameter Client has a request with a Destination-Realm and >>> Destination-Host, will all the primary and secondary peers described >>> in 5.1 be able to route the request to that Destination-Host in that >>> Destination-Realm? >>> >>> --- >>> Joe Harvell >>> Shasta GGSN Development >>> Nortel Networks >>> +1 972.685.4886 >>> >>> >> >> > > From owner-aaa-wg@merit.edu Fri Jan 30 09:43:05 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 JAA18832 for ; Fri, 30 Jan 2004 09:43:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E852191241; Fri, 30 Jan 2004 09:42:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 999E891242; Fri, 30 Jan 2004 09:42: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 4E9B991241 for ; Fri, 30 Jan 2004 09:42:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3987E5DE0E; Fri, 30 Jan 2004 09:42: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 7CE985DE03 for ; Fri, 30 Jan 2004 09:42:50 -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 i0UEgc207332 for ; Fri, 30 Jan 2004 16:42:42 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 16:30:58 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 16:30: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]: Diameter Client request routing Date: Fri, 30 Jan 2004 16:30:56 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPnPYoEqRGIrweaSOa9/LlSbc0srwAABInQ From: To: , Cc: X-OriginalArrivalTime: 30 Jan 2004 14:30:57.0988 (UTC) FILETIME=[AD1CE840:01C3E73D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Joe, Sorry that I have not replied yet, I have been under a mountain of other work. I will try to sort this out early next week. John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Joe Harvell > Sent: 30 January, 2004 16:29 > To: Aittola Mikko (Nokia-NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter Client request routing >=20 >=20 > Mikko: >=20 > So since 6.1 doesn't apply to Diameter Clients, my original questions=20 > remain unanswered. Any comments? >=20 > Harvell, Joe [RICH2:2Q40:EXCH] wrote: >=20 > > Mikko: > > > > I have read this section. There is a good description of=20 > how request=20 > > forwarding and routing work for Diameter Agents. However,=20 > a Diameter=20 > > Client is not a Diameter Agent. > > > > I did find an example in section 2.8.2 that suggests that Diameter=20 > > Clients performs a "routing lookup." > > > > The example provided in Figure 2 depicts a request > > issued from a NAS [Diameter Client], which is an > > access device, for the user bob@example.com. Prior > > to issuing th erequest, NAS performs a Diameter > > route lookup, using "example.com" as the key, and > > determines that the message is to be relayed to > > DRL, which is a Diameter Relay. > > > > To me, this sounds like a Diameter Client following step 3=20 > on page 72=20 > > in 6.1. However, this procedure describes how to process a=20 > received=20 > > message; and this doesn't apply to messages originated by a=20 > Diameter=20 > > Client. Also, the following description of request routing=20 > from 6.1=20 > > only applies to Diameter Agents: > > > > Note that an agent can forward a request to a host > > described in the Destination-Host AVP only if the > > host in question is included in its peer table > > (see Section 2.7). Otherwise, the request is > > routed based on the Destination-Realm only > > (see Sections 6.1.6). > > > > > > > > mikko.aittola@nokia.com wrote: > > > >> Hi, > >> > >> May I suggest reading also Section 6.1, 'Diameter Request Routing=20 > >> Overview'? :) > >> > >> It should be noted that according to the spec if Destination-Host=20 > >> matches > >> the value of Destination-Realm can be ignored. > >> > >> > >> BR, > >> Mikko > >> > >> > >> > >>> -----Original Message----- > >>> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On=20 > >>> Behalf Of > >>> ext Joe Harvell > >>> Sent: 19 January, 2004 21:13 > >>> To: aaa-wg@merit.edu > >>> Subject: [AAA-WG]: Diameter Client request routing > >>> > >>> > >>> I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based=20 > Routing Table),=20 > >>> 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of=20 > >>> Diameter Base Protocol, and I am a little confused about how a=20 > >>> Diameter Peer is to be selected for sending a request from a=20 > >>> Diameter Client. > >>> > >>> Consider the case of a Diameter Client that does not implement=20 > >>> Diameter Peer Discovery. This means that Diameter Peers are=20 > >>> statically configured. The Capabilities Exchange process will=20 > >>> definitely identify the Realm and Host of each Diameter Peer. =20 > >>> However, the only cases in which a peer can be identified as a=20 > >>> candidate next hop for sending a particular request are=20 > as follows: > >>> > >>> 1) when its Realm matches the Destination-Realm of a message=20 > >>> with Destination-Realm only; and > >>> 2) when its Realm and Host match the Destination-Realm and=20 > >>> Destination-Host of a message with a Destination-Realm and=20 > >>> Destination-Host. > >>> > >>> So how does a Diameter Client identify a candidate peer=20 > for sending=20 > >>> messages in the other cases? > >>> > >>> Section 5.1 indicates that a Diameter Node should have=20 > established=20 > >>> connections with a minimum of two (a primary and possibly=20 > multiple=20 > >>> secondary) peers per realm. Does the "realm" in this=20 > context mean=20 > >>> that both peers are members of the same realm, or that both peers=20 > >>> can route messages to a given Destination-Realm? Can Diameter=20 > >>> Agents forward requests for a Destination-Realm that is not their=20 > >>> Realm? > >>> > >>> When a Diameter Client has a request with a Destination-Realm and=20 > >>> Destination-Host, will all the primary and secondary=20 > peers described=20 > >>> in 5.1 be able to route the request to that=20 > Destination-Host in that=20 > >>> Destination-Realm? > >>> > >>> --- > >>> Joe Harvell > >>> Shasta GGSN Development > >>> Nortel Networks > >>> +1 972.685.4886 > >>> > >>> > >> > >> > > > > >=20 >=20 From owner-aaa-wg@merit.edu Fri Jan 30 10:18: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 KAA21091 for ; Fri, 30 Jan 2004 10:18:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D090591242; Fri, 30 Jan 2004 10:17:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9619291243; Fri, 30 Jan 2004 10:17: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 4DBAA91242 for ; Fri, 30 Jan 2004 10:17:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F51F5DDB4; Fri, 30 Jan 2004 10:17:45 -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 3F9665DDB3 for ; Fri, 30 Jan 2004 10:17:44 -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 i0UFHh208162 for ; Fri, 30 Jan 2004 17:17:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 30 Jan 2004 17:17:43 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 17:17:42 +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]: Diameter Client request routing Date: Fri, 30 Jan 2004 17:17:42 +0200 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF0@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPnPXfoLSzsz+gJRu60MCuCgAdNawABNcUg From: To: X-OriginalArrivalTime: 30 Jan 2004 15:17:42.0907 (UTC) FILETIME=[34F994B0:01C3E744] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > So since 6.1 doesn't apply to Diameter Clients, my original questions=20 > remain unanswered. Any comments? I think Section 6.1 clearly does apply to Diameter Clients. Of course there is identified parts that apply only to agents. I'm afraid I can't understand what kind of case you think is not covered by the specification. BR, Mikko > -----Original Message----- > From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] > Sent: 30 January, 2004 16:29 > To: Aittola Mikko (Nokia-NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter Client request routing >=20 >=20 > Mikko: >=20 > So since 6.1 doesn't apply to Diameter Clients, my original questions=20 > remain unanswered. Any comments? >=20 > Harvell, Joe [RICH2:2Q40:EXCH] wrote: >=20 > > Mikko: > > > > I have read this section. There is a good description of=20 > how request=20 > > forwarding and routing work for Diameter Agents. However,=20 > a Diameter=20 > > Client is not a Diameter Agent. > > > > I did find an example in section 2.8.2 that suggests that Diameter=20 > > Clients performs a "routing lookup." > > > > The example provided in Figure 2 depicts a request > > issued from a NAS [Diameter Client], which is an > > access device, for the user bob@example.com. Prior > > to issuing th erequest, NAS performs a Diameter > > route lookup, using "example.com" as the key, and > > determines that the message is to be relayed to > > DRL, which is a Diameter Relay. > > > > To me, this sounds like a Diameter Client following step 3=20 > on page 72=20 > > in 6.1. However, this procedure describes how to process a=20 > received=20 > > message; and this doesn't apply to messages originated by a=20 > Diameter=20 > > Client. Also, the following description of request routing=20 > from 6.1=20 > > only applies to Diameter Agents: > > > > Note that an agent can forward a request to a host > > described in the Destination-Host AVP only if the > > host in question is included in its peer table > > (see Section 2.7). Otherwise, the request is > > routed based on the Destination-Realm only > > (see Sections 6.1.6). > > > > > > > > mikko.aittola@nokia.com wrote: > > > >> Hi, > >> > >> May I suggest reading also Section 6.1, 'Diameter Request Routing=20 > >> Overview'? :) > >> > >> It should be noted that according to the spec if Destination-Host=20 > >> matches > >> the value of Destination-Realm can be ignored. > >> > >> > >> BR, > >> Mikko > >> > >> > >> > >>> -----Original Message----- > >>> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On=20 > >>> Behalf Of > >>> ext Joe Harvell > >>> Sent: 19 January, 2004 21:13 > >>> To: aaa-wg@merit.edu > >>> Subject: [AAA-WG]: Diameter Client request routing > >>> > >>> > >>> I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based=20 > Routing Table),=20 > >>> 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of=20 > >>> Diameter Base Protocol, and I am a little confused about how a=20 > >>> Diameter Peer is to be selected for sending a request from a=20 > >>> Diameter Client. > >>> > >>> Consider the case of a Diameter Client that does not implement=20 > >>> Diameter Peer Discovery. This means that Diameter Peers are=20 > >>> statically configured. The Capabilities Exchange process will=20 > >>> definitely identify the Realm and Host of each Diameter Peer. =20 > >>> However, the only cases in which a peer can be identified as a=20 > >>> candidate next hop for sending a particular request are=20 > as follows: > >>> > >>> 1) when its Realm matches the Destination-Realm of a message=20 > >>> with Destination-Realm only; and > >>> 2) when its Realm and Host match the Destination-Realm and=20 > >>> Destination-Host of a message with a Destination-Realm and=20 > >>> Destination-Host. > >>> > >>> So how does a Diameter Client identify a candidate peer=20 > for sending=20 > >>> messages in the other cases? > >>> > >>> Section 5.1 indicates that a Diameter Node should have=20 > established=20 > >>> connections with a minimum of two (a primary and possibly=20 > multiple=20 > >>> secondary) peers per realm. Does the "realm" in this=20 > context mean=20 > >>> that both peers are members of the same realm, or that both peers=20 > >>> can route messages to a given Destination-Realm? Can Diameter=20 > >>> Agents forward requests for a Destination-Realm that is not their=20 > >>> Realm? > >>> > >>> When a Diameter Client has a request with a Destination-Realm and=20 > >>> Destination-Host, will all the primary and secondary=20 > peers described=20 > >>> in 5.1 be able to route the request to that=20 > Destination-Host in that=20 > >>> Destination-Realm? > >>> > >>> --- > >>> Joe Harvell > >>> Shasta GGSN Development > >>> Nortel Networks > >>> +1 972.685.4886 > >>> > >>> > >> > >> > > > > >=20 >=20 From owner-aaa-wg@merit.edu Fri Jan 30 10:28:53 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 KAA21827 for ; Fri, 30 Jan 2004 10:28:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A728291243; Fri, 30 Jan 2004 10:28:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70C7691244; Fri, 30 Jan 2004 10:28: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 591A591243 for ; Fri, 30 Jan 2004 10:28:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 461535DDE1; Fri, 30 Jan 2004 10:28: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 BF5685DE1F for ; Fri, 30 Jan 2004 10:28:35 -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 i0UFSTg16723; Fri, 30 Jan 2004 07:28:30 -0800 (PST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXNNK108; Fri, 30 Jan 2004 09:28:29 -0600 Received: from nortelnetworks.com (archt52h.us.nortel.com [47.102.193.129]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C0CLN4XL; Fri, 30 Jan 2004 09:28:29 -0600 Message-ID: <401A7805.9090305@nortelnetworks.com> Date: Fri, 30 Jan 2004 15:28:05 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.aittola@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Client request routing References: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF0@esebe012.ntc.nokia.com> In-Reply-To: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF0@esebe012.ntc.nokia.com> Content-Type: multipart/alternative; boundary="------------070502060904070705040706" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------070502060904070705040706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mikko: I find nothing in 6.1 that describes how a Diameter Client routes requests it originates. Could you identify specific text from that section that suggests it does apply to Diameter Clients? Does anyone else have an opinon on this? mikko.aittola@nokia.com wrote: >Hi, > > > >>So since 6.1 doesn't apply to Diameter Clients, my original questions >>remain unanswered. Any comments? >> >> > >I think Section 6.1 clearly does apply to Diameter Clients. Of course >there is identified parts that apply only to agents. > Yes, the parts that describe the routing mechanism. > >I'm afraid I can't understand what kind of case you think is not >covered by the specification. > > >BR, >Mikko > > > > >>-----Original Message----- >>From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] >>Sent: 30 January, 2004 16:29 >>To: Aittola Mikko (Nokia-NET/Helsinki) >>Cc: aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: Diameter Client request routing >> >> >>Mikko: >> >>So since 6.1 doesn't apply to Diameter Clients, my original questions >>remain unanswered. Any comments? >> >>Harvell, Joe [RICH2:2Q40:EXCH] wrote: >> >> >> >>>Mikko: >>> >>>I have read this section. There is a good description of >>> >>> >>how request >> >> >>>forwarding and routing work for Diameter Agents. However, >>> >>> >>a Diameter >> >> >>>Client is not a Diameter Agent. >>> >>>I did find an example in section 2.8.2 that suggests that Diameter >>>Clients performs a "routing lookup." >>> >>> The example provided in Figure 2 depicts a request >>> issued from a NAS [Diameter Client], which is an >>> access device, for the user bob@example.com. Prior >>> to issuing th erequest, NAS performs a Diameter >>> route lookup, using "example.com" as the key, and >>> determines that the message is to be relayed to >>> DRL, which is a Diameter Relay. >>> >>>To me, this sounds like a Diameter Client following step 3 >>> >>> >>on page 72 >> >> >>>in 6.1. However, this procedure describes how to process a >>> >>> >>received >> >> >>>message; and this doesn't apply to messages originated by a >>> >>> >>Diameter >> >> >>>Client. Also, the following description of request routing >>> >>> >>from 6.1 >> >> >>>only applies to Diameter Agents: >>> >>> Note that an agent can forward a request to a host >>> described in the Destination-Host AVP only if the >>> host in question is included in its peer table >>> (see Section 2.7). Otherwise, the request is >>> routed based on the Destination-Realm only >>> (see Sections 6.1.6). >>> >>> >>> >>>mikko.aittola@nokia.com wrote: >>> >>> >>> >>>>Hi, >>>> >>>>May I suggest reading also Section 6.1, 'Diameter Request Routing >>>>Overview'? :) >>>> >>>>It should be noted that according to the spec if Destination-Host >>>>matches >>>>the value of Destination-Realm can be ignored. >>>> >>>> >>>>BR, >>>>Mikko >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On >>>>>Behalf Of >>>>>ext Joe Harvell >>>>>Sent: 19 January, 2004 21:13 >>>>>To: aaa-wg@merit.edu >>>>>Subject: [AAA-WG]: Diameter Client request routing >>>>> >>>>> >>>>>I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based >>>>> >>>>> >>Routing Table), >> >> >>>>>5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of >>>>>Diameter Base Protocol, and I am a little confused about how a >>>>>Diameter Peer is to be selected for sending a request from a >>>>>Diameter Client. >>>>> >>>>>Consider the case of a Diameter Client that does not implement >>>>>Diameter Peer Discovery. This means that Diameter Peers are >>>>>statically configured. The Capabilities Exchange process will >>>>>definitely identify the Realm and Host of each Diameter Peer. >>>>>However, the only cases in which a peer can be identified as a >>>>>candidate next hop for sending a particular request are >>>>> >>>>> >>as follows: >> >> >>>>> 1) when its Realm matches the Destination-Realm of a message >>>>>with Destination-Realm only; and >>>>> 2) when its Realm and Host match the Destination-Realm and >>>>>Destination-Host of a message with a Destination-Realm and >>>>>Destination-Host. >>>>> >>>>>So how does a Diameter Client identify a candidate peer >>>>> >>>>> >>for sending >> >> >>>>>messages in the other cases? >>>>> >>>>>Section 5.1 indicates that a Diameter Node should have >>>>> >>>>> >>established >> >> >>>>>connections with a minimum of two (a primary and possibly >>>>> >>>>> >>multiple >> >> >>>>>secondary) peers per realm. Does the "realm" in this >>>>> >>>>> >>context mean >> >> >>>>>that both peers are members of the same realm, or that both peers >>>>>can route messages to a given Destination-Realm? Can Diameter >>>>>Agents forward requests for a Destination-Realm that is not their >>>>>Realm? >>>>> >>>>>When a Diameter Client has a request with a Destination-Realm and >>>>>Destination-Host, will all the primary and secondary >>>>> >>>>> >>peers described >> >> >>>>>in 5.1 be able to route the request to that >>>>> >>>>> >>Destination-Host in that >> >> >>>>>Destination-Realm? >>>>> >>>>>--- >>>>>Joe Harvell >>>>>Shasta GGSN Development >>>>>Nortel Networks >>>>>+1 972.685.4886 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > > --------------070502060904070705040706 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mikko:

I find nothing in 6.1 that describes how a Diameter Client routes requests it originates.  Could you identify specific text from that section that suggests it does apply to Diameter Clients?

Does anyone else have an opinon on this?

mikko.aittola@nokia.com wrote:
Hi,

  
So since 6.1 doesn't apply to Diameter Clients, my original questions 
remain unanswered.  Any comments?
    

I think Section 6.1 clearly does apply to Diameter Clients. Of course
there is identified parts that apply only to agents.
Yes, the parts that describe the routing mechanism.

I'm afraid I can't understand what kind of case you think is not
covered by the specification.


BR,
Mikko


  
-----Original Message-----
From: ext Joe Harvell [mailto:harvell@nortelnetworks.com]
Sent: 30 January, 2004 16:29
To: Aittola Mikko (Nokia-NET/Helsinki)
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Diameter Client request routing


Mikko:

So since 6.1 doesn't apply to Diameter Clients, my original questions 
remain unanswered.  Any comments?

Harvell, Joe [RICH2:2Q40:EXCH] wrote:

    
Mikko:

I have read this section.  There is a good description of 
      
how request 
    
forwarding and routing work for Diameter Agents.  However, 
      
a Diameter 
    
Client is not a Diameter Agent.

I did find an example in section 2.8.2 that suggests that Diameter 
Clients performs a "routing lookup."

    The example provided in Figure 2 depicts a request
    issued from a NAS [Diameter Client], which is an
    access device, for the user bob@example.com.  Prior
    to issuing th erequest, NAS performs a Diameter
    route lookup, using "example.com" as the key, and
    determines that the message is to be relayed to
    DRL, which is a Diameter Relay.

To me, this sounds like a Diameter Client following step 3 
      
on page 72 
    
in 6.1.  However, this procedure describes how to process a 
      
received 
    
message; and this doesn't apply to messages originated by a 
      
Diameter 
    
Client.  Also, the following description of request routing 
      
from 6.1 
    
only applies to Diameter Agents:

    Note that an agent can forward a request to a host
    described in the Destination-Host AVP only if the
    host in question is included in its peer table
    (see Section 2.7).  Otherwise, the request is
    routed based on the Destination-Realm only
    (see Sections 6.1.6).



mikko.aittola@nokia.com wrote:

      
Hi,

May I suggest reading also Section 6.1, 'Diameter Request Routing 
Overview'? :)

It should be noted that according to the spec if Destination-Host 
matches
the value of Destination-Realm can be ignored.


BR,
Mikko



        
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On 
Behalf Of
ext Joe Harvell
Sent: 19 January, 2004 21:13
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Diameter Client request routing


I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based 
          
Routing Table), 
    
5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of 
Diameter Base Protocol, and I am a little confused about how a 
Diameter Peer is to be selected for sending a request from a 
Diameter Client.

Consider the case of a Diameter Client that does not implement 
Diameter Peer Discovery.  This means that Diameter Peers are 
statically configured.  The Capabilities Exchange process will 
definitely identify the Realm and Host of each Diameter Peer.  
However, the only cases in which a peer can be identified as a 
candidate next hop for sending a particular request are 
          
as follows:
    
    1) when its Realm matches the Destination-Realm of a message 
with Destination-Realm only; and
    2) when its Realm and Host match the Destination-Realm and 
Destination-Host of a message with a Destination-Realm and 
Destination-Host.

So how does a Diameter Client identify a candidate peer 
          
for sending 
    
messages in the other cases?

Section 5.1 indicates that a Diameter Node should have 
          
established 
    
connections with a minimum of two (a primary and possibly 
          
multiple 
    
secondary) peers per realm.  Does the "realm" in this 
          
context mean 
    
that both peers are members of the same realm, or that both peers 
can route messages to a given Destination-Realm?  Can Diameter 
Agents forward requests for a Destination-Realm that is not their 
Realm?

When a Diameter Client has a request with a Destination-Realm and 
Destination-Host, will all the primary and secondary 
          
peers described 
    
in 5.1 be able to route the request to that 
          
Destination-Host in that 
    
Destination-Realm?

---
Joe Harvell
Shasta GGSN Development
Nortel Networks
+1 972.685.4886
--------------070502060904070705040706-- From owner-aaa-wg@merit.edu Fri Jan 30 10:51: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 KAA22854 for ; Fri, 30 Jan 2004 10:51:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BD7291248; Fri, 30 Jan 2004 10:51:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4368C9124A; Fri, 30 Jan 2004 10:51: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 9F74891248 for ; Fri, 30 Jan 2004 10:51:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CD675DDBC; Fri, 30 Jan 2004 10:51:05 -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 AB11A5DDAE for ; Fri, 30 Jan 2004 10:51:04 -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 i0UFp3227616 for ; Fri, 30 Jan 2004 17:51:03 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 17:51:03 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 17:51:03 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 17:51: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]: Issue: DCC: Independent handling of services within a session Date: Fri, 30 Jan 2004 17:51:02 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03FA@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC: Independent handling of services within a session Thread-Index: AcPmm/scWhf8vBjwR96VlJYpVqXZrAAq9oDw From: To: Cc: , , , , , , X-OriginalArrivalTime: 30 Jan 2004 15:51:03.0136 (UTC) FILETIME=[DD344E00:01C3E748] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable 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? 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=20 functionalities. For that reason we may perhaps consider to define a=20 new grouped AVP that would include G-S-U, R-S-U, U-S-U, F-U-I etc. = rather=20 than lifting everything at G-S-U level. But, let agree the basic = principles=20 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=20 >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=20 >- adding an additional service or rating group requires = re-authorisation of all other=20 >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. >- the construction in which multiple quotas representing the *same* = monetary allocation are=20 >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. >In order to handle quotas within a pool separately, it is necessary to = be more explicit=20 >within the protocol about the relationship between quotas. This is = presently communicated=20 >implicitly based on the assumption that all quotas are derived from the = same credit=20 >reservation in the server. >For each service/rating group and unit, we provide a 'Multiplier' value = which is used to=20 >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? >The formula for determining the exhaustion of the credit for a given = pool of quotas at the=20 >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 the granted=20 >quotas in the pool as follows: > M =3D Q1*M1 + Q2*M2 + ... + Qn*Mn=20 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. 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...?=20 >Additional considerations:=20 >This proposal raised some additional considerations which require = discussion. 1) Since we=20 >propose that quotas are handled independently, it MAY be necessary to = associate the=20 >DIAMETER CC state machine with each *quota* rather than with a = (sub-)session. Equivalently,=20 >the CCR/CCA messages could be extended to handle requests/answers for = multiple sub-sessions=20 >within a single message. Due to the need for further discussion, the = detailed changes for=20 >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." =20 ...or something to that effect. >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=20 >AVP could be defined within the CCA message which supports such = actions. This is not shown=20 >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. >Detailed changes:=20 >- Section 5, fifth paragraph, amend as follows:=20 FROM:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost, making = use=20 of credit control sub-sessions will result in increased signaling = load=20 and resources usage in both the credit control client and the credit=20 control server. For instance, during one network access session the=20 end user may use several http-services subject to different access=20 cost. To optimally support these scenarios, the credit control=20 application enables for multiple services credit control in a single=20 credit control session. It is possible to request and allocate=20 multiple quotas as a credit pool that is shared between multiple=20 services. The services can be further grouped into rating groups in=20 order to achieve even 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 TO:=20 When multiple services are used within one user session and each=20 service or group of services are subject to different cost, making = use=20 of credit control sub-sessions will result in increased signaling = load=20 and resources usage in both the credit control client and the credit=20 control server. For instance, during one network access session the=20 end user may use several http-services subject to different access=20 cost. To optimally support these scenarios, the credit control=20 application enables for multiple services credit control in a single=20 credit control session or sub-session. It is possible to request and=20 allocate resource as a credit pool that is shared between multiple=20 services. The services can be further grouped into rating groups in=20 order to achieve even further aggregation of credit allocation. It is = also possible to request and allocate multiple quotas on a per = service=20 basis. Where quotas are allocated to a pool, the quotas remain = independent=20 objects which can be re-authorised independently at any time. Quotas = can=20 also be given independent validity times and Final-Unit-Indications. = The=20 mechanism to share units across services and rating groups is = described=20 further in Section 5.X. MSt: I think this is fine. > 5.X Sharing of units across services and rating groups=20 To avoid credit fragmentation and unnecessary load on the credit = control=20 server, it is possible for service units to be provided to multiple=20 services or rating groups as a pool.=20 This is achieved by providing the service units in the form of a = quota for=20 a particular service or rating group in the usual way, but also = including=20 a reference to a credit pool for that unit type. The reference = includes a=20 multiplier which translates from service units of a specific type to = the=20 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). Where multiple G-S-U-Pool-Reference AVPs with the same G-S-U-Pool=20 Identifier are provided within a Granted-Service-Units AVP then = these=20 MUST have different CC-Unit-Type values and they all draw on the = credit=20 pool separately.=20 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.=20 8.16 Granted-Service-Unit AVP =20 =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 *[ G-S-U-Pool-Reference ]=20 *[ Service-Identifier ]=20 [ Rating-Group ]=20 [ Validity-Time ]=20 [ Final-Unit-Indication ]=20 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. From owner-aaa-wg@merit.edu Fri Jan 30 11:09: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 LAA23527 for ; Fri, 30 Jan 2004 11:09:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 583319124A; Fri, 30 Jan 2004 11:09:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21D2F9124B; Fri, 30 Jan 2004 11:09: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 D1A139124A for ; Fri, 30 Jan 2004 11:09:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC1935DDC4; Fri, 30 Jan 2004 11:09:22 -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 082D75DDE8 for ; Fri, 30 Jan 2004 11:09:22 -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 i0UG9Ji27174 for ; Fri, 30 Jan 2004 08:09:20 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Jan 2004 10:09:19 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8EF0@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Date: Fri, 30 Jan 2004 10:09:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E74B.29541C8C" 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_01C3E74B.29541C8C Content-Type: text/plain 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. ------_=_NextPart_001_01C3E74B.29541C8C Content-Type: text/html Content-Transfer-Encoding: quoted-printable 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:  
          &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 ]

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

------_=_NextPart_001_01C3E74B.29541C8C-- From owner-aaa-wg@merit.edu Fri Jan 30 11:13: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 LAA23828 for ; Fri, 30 Jan 2004 11:13:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A37279124B; Fri, 30 Jan 2004 11:13:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D10F9124D; Fri, 30 Jan 2004 11:13:33 -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 9A6909124B for ; Fri, 30 Jan 2004 11:13:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 871635DDF0; Fri, 30 Jan 2004 11:13:31 -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 8B7E05DDDB for ; Fri, 30 Jan 2004 11:13:30 -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 i0UGDTM08934 for ; Fri, 30 Jan 2004 18:13:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 30 Jan 2004 18:13:29 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 18:13:29 +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]: Diameter Client request routing Date: Fri, 30 Jan 2004 18:13:29 +0200 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF2@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPnRb32PbN991vuQEy685QiVnIj2gAAo7hA From: To: X-OriginalArrivalTime: 30 Jan 2004 16:13:29.0681 (UTC) FILETIME=[FFCEC410:01C3E74B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Can you describe an example problem-case that you think is not covered = by the specification? Also, did you only look at the text in Section 6.1 without regarding what is said in other parts of the spec, for example in sub-sections of 6.1? There is also text elsewhere about the routing tables etc. I think it is not useful to copy-paste here all the routing related text that applies to Diameter Clients. It wouldn't make the text any easier to understand. BR, Mikko -----Original Message----- From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] Sent: 30 January, 2004 17:28 To: Aittola Mikko (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Client request routing Mikko: I find nothing in 6.1 that describes how a Diameter Client routes = requests it originates. Could you identify specific text from that = section that suggests it does apply to Diameter Clients? Does anyone else have an opinon on this? mikko.aittola@nokia.com wrote: Hi, =20 So since 6.1 doesn't apply to Diameter Clients, my original questions=20 remain unanswered. Any comments? =20 I think Section 6.1 clearly does apply to Diameter Clients. Of course there is identified parts that apply only to agents. Yes, the parts that describe the routing mechanism. I'm afraid I can't understand what kind of case you think is not covered by the specification. BR, Mikko =20 -----Original Message----- From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] Sent: 30 January, 2004 16:29 To: Aittola Mikko (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Client request routing Mikko: So since 6.1 doesn't apply to Diameter Clients, my original questions=20 remain unanswered. Any comments? Harvell, Joe [RICH2:2Q40:EXCH] wrote: =20 Mikko: I have read this section. There is a good description of=20 =20 how request=20 =20 forwarding and routing work for Diameter Agents. However,=20 =20 a Diameter=20 =20 Client is not a Diameter Agent. I did find an example in section 2.8.2 that suggests that Diameter=20 Clients performs a "routing lookup." The example provided in Figure 2 depicts a request issued from a NAS [Diameter Client], which is an access device, for the user bob@example.com. Prior to issuing th erequest, NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to DRL, which is a Diameter Relay. To me, this sounds like a Diameter Client following step 3=20 =20 on page 72=20 =20 in 6.1. However, this procedure describes how to process a=20 =20 received=20 =20 message; and this doesn't apply to messages originated by a=20 =20 Diameter=20 =20 Client. Also, the following description of request routing=20 =20 from 6.1=20 =20 only applies to Diameter Agents: Note that an agent can forward a request to a host described in the Destination-Host AVP only if the host in question is included in its peer table (see Section 2.7). Otherwise, the request is routed based on the Destination-Realm only (see Sections 6.1.6). mikko.aittola@nokia.com wrote: =20 Hi, May I suggest reading also Section 6.1, 'Diameter Request Routing=20 Overview'? :) It should be noted that according to the spec if Destination-Host=20 matches the value of Destination-Realm can be ignored. BR, Mikko =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On=20 Behalf Of ext Joe Harvell Sent: 19 January, 2004 21:13 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Client request routing I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based=20 =20 Routing Table),=20 =20 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of=20 Diameter Base Protocol, and I am a little confused about how a=20 Diameter Peer is to be selected for sending a request from a=20 Diameter Client. Consider the case of a Diameter Client that does not implement=20 Diameter Peer Discovery. This means that Diameter Peers are=20 statically configured. The Capabilities Exchange process will=20 definitely identify the Realm and Host of each Diameter Peer. =20 However, the only cases in which a peer can be identified as a=20 candidate next hop for sending a particular request are=20 =20 as follows: =20 1) when its Realm matches the Destination-Realm of a message=20 with Destination-Realm only; and 2) when its Realm and Host match the Destination-Realm and=20 Destination-Host of a message with a Destination-Realm and=20 Destination-Host. So how does a Diameter Client identify a candidate peer=20 =20 for sending=20 =20 messages in the other cases? Section 5.1 indicates that a Diameter Node should have=20 =20 established=20 =20 connections with a minimum of two (a primary and possibly=20 =20 multiple=20 =20 secondary) peers per realm. Does the "realm" in this=20 =20 context mean=20 =20 that both peers are members of the same realm, or that both peers=20 can route messages to a given Destination-Realm? Can Diameter=20 Agents forward requests for a Destination-Realm that is not their=20 Realm? When a Diameter Client has a request with a Destination-Realm and=20 Destination-Host, will all the primary and secondary=20 =20 peers described=20 =20 in 5.1 be able to route the request to that=20 =20 Destination-Host in that=20 =20 Destination-Realm? --- Joe Harvell Shasta GGSN Development Nortel Networks +1 972.685.4886 =20 =20 =20 =20 From owner-aaa-wg@merit.edu Fri Jan 30 11:18: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 LAA24118 for ; Fri, 30 Jan 2004 11:18:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3D389124C; Fri, 30 Jan 2004 11:18:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A14BC9124D; Fri, 30 Jan 2004 11:18: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 6B26B9124C for ; Fri, 30 Jan 2004 11:18:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4BE575DDAF; Fri, 30 Jan 2004 11:18:17 -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 6CA055DDAB; Fri, 30 Jan 2004 11:18:15 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 30 Jan 2004 16:22:28 +0000 To: "Christopher Richards" Cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu 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: Fri, 30 Jan 2004 16:18:09 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 01/30/2004 04:18:10 PM, Serialize complete at 01/30/2004 04:18:10 PM Content-Type: multipart/alternative; boundary="=_alternative 00598C3E80256E2B_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00598C3E80256E2B_= Content-Type: text/plain; charset="us-ascii" 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 ****************************************************************************** --=_alternative 00598C3E80256E2B_= Content-Type: text/html; charset="us-ascii"
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

******************************************************************************
 --=_alternative 00598C3E80256E2B_=-- From owner-aaa-wg@merit.edu Fri Jan 30 11:24: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 LAA24342 for ; Fri, 30 Jan 2004 11:23:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC4349124E; Fri, 30 Jan 2004 11:23:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFC589124D; Fri, 30 Jan 2004 11:23: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 701A59124E for ; Fri, 30 Jan 2004 11:23:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F7645DDDD; Fri, 30 Jan 2004 11:23:37 -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 A5A685DDD8; Fri, 30 Jan 2004 11:23:35 -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 i0UGNY215653; Fri, 30 Jan 2004 18:23:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 18:23:34 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 18:23: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_01C3E74D.67B895F4" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Date: Fri, 30 Jan 2004 18:23:33 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C834D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thread-Index: AcPnTLwNzs7WCX1wQby36rHdb4s3ygAAB+Lg From: To: , Cc: , X-OriginalArrivalTime: 30 Jan 2004 16:23:33.0983 (UTC) FILETIME=[67FFEEF0:01C3E74D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E74D.67B895F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John Prudhoe wrote =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 Agree. Lets keep the UNIT_INDETERMINATE as discussed earlier. =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 =20 Fully agree also here. Lets keep th emechanism as it is. =20 Chris Richards wrote =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 =20 Why don't you align to the DCC instead? =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext John.Prudhoe@vodafone.com Sent: 30 January, 2004 18:18 To: Christopher Richards Cc: 'aaa-wg@merit.edu'; owner-aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 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 =20 To: "'aaa-wg@merit.edu'" =20 cc: =20 Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 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 = 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 = 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 = 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=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 - 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 =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 *************************************************************************= ***** 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 *************************************************************************= ***** ------_=_NextPart_001_01C3E74D.67B895F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

There is a fundamental difference between tariffs changing for = a service=20 that is consumed at a regular rate (i.e. time based such as = circuit-switched=20 calls) and one that is consumed at an irregular rate (such as GPRS or 3G = data=20 services).
Agree.=20 Lets keep the UNIT_INDETERMINATE as discussed = earlier.
 
For = time-based=20 services there is no need to report the Tariff-Time-Change AVP to the = client.=20  It doesn't even need to know that the tariff has changed. =  When the=20 server knows that there is tariff change due it can take this into = account when=20 rating the granted units.  There is no need for any additional = Diameter=20 traffic for time-based services when there is a tariff change.
 
Fully=20 agree also here. Lets keep th emechanism as it is.
 
Chris=20 Richards wrote
 
3. In 3GPP IMS = charging (3GPP=20 TS 32.225, Release 5), a different mechanism has been introduced for the = Diameter IMS charging application which avoids the problems stated above = - there=20 are no longer used resources that straddle a tariff change thus removing = this=20 indeterminate charging scenario. It would seem highly desirable to align = with=20 this mechanism so all applications can benefit.
 
Why=20 don't you align to the DCC instead?
 
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext=20 John.Prudhoe@vodafone.com
Sent: 30 January, 2004 = 18:18
To:=20 Christopher Richards
Cc: 'aaa-wg@merit.edu';=20 owner-aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DCC: Issue: = Tariff=20 Change mechanism.


Hi=20 Chris,

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

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

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

Regards,

John.





"Christopher Richards"=20 <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu=20

30/01/2004 16:09 =

        =
        To: =    =20    "'aaa-wg@merit.edu'" = <aaa-wg@merit.edu>=20
        = cc:  =20      
 =20       Subject:       =  [AAA-WG]: DCC:=20 Issue: Tariff Change = mechanism.



All,=20

Please find enclosed issue = regarding=20 the current tariff change mechanism specified in the DCC = draft.
Best Regards,=20
Chris = Richards.


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

Rationale/Explanation of = issues:=20

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

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

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

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

Requested = changes:

- Section 5, last=20 paragraph:

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

TO:
  = The Diameter=20 credit-control server and client may optionally support a
  = tariff=20 change mechanism. The Diameter credit-control server may
  = include=20 both the 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 = before the=20 potential tariff change while the=20
  second = granted units are=20 used after a tariff change. Both granted unit
  quotas MUST contain the same Service-Identifier = and=20 Rating-Group values. =
  This dual quota mechanism = ensures=20 that the overall reported used=20
  units would = never exceed=20 the credit reservation.  
  The Diameter credit-control = client=20 reports both the used units before
  and after the tariff=20 change.

- Section 8.16, new=20 paragraphs:

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

   When both the=20 Tariff-Time-Change and Tariff-Change-Usage AVPs are = present,
  the server MUST include two separate = Granted-Service-Unit=20 AVPs (for the =
  same Service-Identifier = and/or=20 Rating-Group when 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 = tariff change=20 has occurred.

- Section 8.16, last=20 paragraph:

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

- Section 8.41, first and = second=20 paragraphs:

FROM:
  The Tariff-Time-Change AVP (AVP code 451) is of = type Time,=20 and
  includes the time in seconds since January 1, 1900 = 00:00 UTC=20 when the
  tariff of the service will be changed.
 =20  
  The tariff change mechanism is optional for client = and server=20 and it
  is not used for unit type time, since the server has = full=20 control of
  the time.  
  =  
TO:
  The Tariff-Time-Change AVP (AVP code 451) is of = type Time,=20 and
  includes the time in seconds since January 1, 1900 = 00:00 UTC=20 when the
  tariff of the service will be changed.

   The tariff = change=20 mechanism is optionally enabled by the server for a
  = Diameter credit=20 control session or sub-session.=20

- Section 8.42:

FROM:
  The=20 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
   
  Tariff-Change-Usage can be one of the = following.=20
   
   UNIT_BEFORE_TARIFF_CHANGE   =  =20                     =  =20        0
   
    The = used units=20 contains the amount of the units before tariff
    = change, that=20 is units measured from the point when the previous
   =20 measurement ended to the point when tariff change occurred.
  =  
   UNIT_AFTER_TARIFF_CHANGE       =  =20                     =  =20     1
 
    The=20 used units contains the amount of the units after tariff change =
 =20   has been occurred.
   
  =  UNIT_INDETERMINATE=20                     =  =20                   2 =
 =20  
    The used units contains the amount of units = that=20 straddle the
    tariff change (e.g. the metering = process=20 reports to the credit- =
    control client in = blocks of n=20 octets and one block straddled the
    tariff=20 change).
TO:    
  The=20 Tariff-Change-Usage AVP (AVP code 452) is of type = Enumerated.

   When present = in the=20 Granted-Service-Units AVP, this AVP defines whether
  units are allocated to be used before or after a = tariff=20 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=20 the reporting
  period.

   Omission of = this AVP means=20 that no tariff change is to be reported and/or
  none has occurred.
   
 =20 Tariff-Change-Usage can be one of the following.
  =  
 =20  UNIT_BEFORE_TARIFF_CHANGE           =  =20                     =  0=20
   
    When present in the = Granted-Service-Units=20 AVP, this value indicates=20
    the = amount of the=20 units allocated for use before a tariff change
    occurs.=20

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

     When = present in the=20 Reported-Service-Units AVP, this value indicates
    the amount of resource units used after = tariff change=20 had occurred.
   =20

- end of = changes

Best Regards,
Chris Richards.



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

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

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

------_=_NextPart_001_01C3E74D.67B895F4-- From owner-aaa-wg@merit.edu Fri Jan 30 11:27: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 LAA24677 for ; Fri, 30 Jan 2004 11:27:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3AE89124D; Fri, 30 Jan 2004 11:27:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50DBF91253; Fri, 30 Jan 2004 11:27:33 -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 666AF9124D for ; Fri, 30 Jan 2004 11:27:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 225EB5DDED; Fri, 30 Jan 2004 11:27:30 -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 2EBA75DE02; Fri, 30 Jan 2004 11:27:29 -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 i0UGRNi29233; Fri, 30 Jan 2004 08:27:23 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Jan 2004 10:27:21 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597535E8EF3@zrc2c012.us.nortel.com> From: "Christopher Richards" To: "'John.Prudhoe@vodafone.com'" Cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Date: Fri, 30 Jan 2004 10:27:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E74D.4AC6B882" 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_01C3E74D.4AC6B882 Content-Type: text/plain 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 **************************************************************************** ** ------_=_NextPart_001_01C3E74D.4AC6B882 Content-Type: text/html Message
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

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

------_=_NextPart_001_01C3E74D.4AC6B882-- From owner-aaa-wg@merit.edu Fri Jan 30 11:38: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 LAA25888 for ; Fri, 30 Jan 2004 11:38:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C56B9126C; Fri, 30 Jan 2004 11:35:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C0629126E; Fri, 30 Jan 2004 11:35: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 773BF9126C for ; Fri, 30 Jan 2004 11:35:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6055E5DDC8; Fri, 30 Jan 2004 11:35:46 -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 A5B7A5DDB6 for ; Fri, 30 Jan 2004 11:35:45 -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 i0UGZg205023 for ; Fri, 30 Jan 2004 18:35:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 18:35:42 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 18:35:41 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 18:35:41 +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]: Issue: DCC: Credit pooling should be under server control Date: Fri, 30 Jan 2004 18:35:40 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B03FB@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: DCC: Credit pooling should be under server control Thread-Index: AcPmnA/9+EJlNfEBTtmvGDSDJMSgWgAssNfg From: To: Cc: , , , , , , X-OriginalArrivalTime: 30 Jan 2004 16:35:41.0245 (UTC) FILETIME=[197B4ED0:01C3E74F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mark, >Therefore it's clear that it is the CC Client that controls the = grouping of services or=20 >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. >Finally, the current draft omits to describe how credit pooling is = applied in the case of=20 >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. >In order to let the responsibility of grouping to the sever, i.e, the = server decides what=20 >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=20 >'Granted Service Units Pool'. The Granted Service Units Pool is = identified by a unique=20 >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=20 >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. > Note that this concept implies that one single credit reservation=20 is kept and allocated to all the services/rating groups within a = credit=20 pool. All the quotas associated with the credit pool are derived from = that=20 entire credit reservation i.e. assuming each given service/rating = group=20 consumes the whole amount. Therefore the quotas conveyed to the = Diameter=20 Credit control client are not independent entities - that is the = client can=20 completely consume only a single one of them, or partially consume = some=20 combination. Where a single service or rating group has multiple = quotas of=20 different types (e.g. time and volume), these are considered as = separate=20 quotas within the credit pool. An example of this mechanism is = illustrated=20 in Appendix A (Flow X).=20 MSt: since each service/rating-group seems to have its own reservation, = the above text is now inaccurate. What about removing or rewriting it? >8.16 Granted-Service-Unit AVP =20 Re-authorisation must be sought when the credit pool is exhausted. A = credit=20 pool is considered exhausted when the sum of the fractional amounts = of the=20 granted credit for all the quotas associated with the same credit = pool=20 reaches unity. >8.X G-S-U-Pool-Identifier AVP Granted-Service-Units associated=20 within a single Credit Pool are assumed to be drawn from a common = credit=20 reservation. Therefore, re-authorisation MUST be sought when the = combined=20 resource used by all the services or rating groups within the credit = pool=20 reaches 100% of the amount granted.=20 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. > 8.Y G-S-U-Pool-Reference AVP=20 The G-S-U-Pool-Reference AVP (AVP code tbd) is of type Grouped and=20 associates the Granted-Service-Units AVP within which it appears = with a=20 credit pool within the session for a single unit type. The = CC-Unit-Type=20 AVP specifies the type of units for which credit is pooled. The = Credit-=20 Pool-Identifier AVP specifies the credit pool from which credit is = drawn=20 for this unit type.=20 G-S-U-Pool-Reference ::=3D < AVP Header: tbd >=20 ( G-S-U-Pool-Identifier )=20 ( CC-Unit-Type )=20 MSt: I think there is better description in issue 16. The ABNF grammar = should be: G-S-U-Pool-Reference ::=3D < AVP Header: tbd >=20 { G-S-U-Pool-Identifier }=20 [ CC-Unit-Type ] [ Unit-Value ]=20 Regards Marco From owner-aaa-wg@merit.edu Fri Jan 30 11:47:47 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 LAA26442 for ; Fri, 30 Jan 2004 11:47:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F79F91251; Fri, 30 Jan 2004 11:47:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4919C91253; Fri, 30 Jan 2004 11:47: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 64B7791251 for ; Fri, 30 Jan 2004 11:47:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 506485DD9F; Fri, 30 Jan 2004 11:47:17 -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 B5D055DDA3 for ; Fri, 30 Jan 2004 11:47:16 -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 i0UGlBi01582; Fri, 30 Jan 2004 08:47:12 -0800 (PST) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXNNKHT2; Fri, 30 Jan 2004 10:47:11 -0600 Received: from nortelnetworks.com (archt52h.us.nortel.com [47.102.193.129]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C0CLN47R; Fri, 30 Jan 2004 10:47:11 -0600 Message-ID: <401A8A75.10109@nortelnetworks.com> Date: Fri, 30 Jan 2004 16:46:45 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.aittola@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Client request routing References: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF2@esebe012.ntc.nokia.com> In-Reply-To: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF2@esebe012.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mikko: This boils down to a difference of opinion on whether 6.1 applies to Diameter Clients (and Diameter Servers for that matter). If this is the case, then my only question is whether a Diameter Node's identity (what it sends for Origin-Host in CER) is expected to be unique only within a Realm, or unique even across Realms. If 6.1 does apply to all Diameter Nodes, then that is not clear in the Diameter Base spec. I have replied to your questions below... mikko.aittola@nokia.com wrote: >Hi, > >Can you describe an example problem-case that you think is not covered by the >specification? > I have. Refer to my original email. > >Also, did you only look at the text in Section 6.1 without >regarding what is said in other parts of the spec, for >example in sub-sections of 6.1? > Yes, I have read the entire spec, with particular attention to 6.1 and its subsections. > There is also text elsewhere >about the routing tables etc. > Yes, I have seen references to this. In almost all cases, the text describes the action of Diameter Agents or actions of Diameter Nodes receiving requests and then forwarding/routing them. The only case I have found where it is suggested that something other than a Diameter Agent uses the routing mechanism described in 6.1 is the description of the example in 2.8.2, which I have already included. > >I think it is not useful to copy-paste here all the routing related text >that applies to Diameter Clients. It wouldn't make the text any easier >to understand. > Have you even looked at Section 6.1 since I posed this question? > > >BR, >Mikko > > >-----Original Message----- >From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] >Sent: 30 January, 2004 17:28 >To: Aittola Mikko (Nokia-NET/Helsinki) >Cc: aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Diameter Client request routing > > >Mikko: > >I find nothing in 6.1 that describes how a Diameter Client routes requests it originates. Could you identify specific text from that section that suggests it does apply to Diameter Clients? > >Does anyone else have an opinon on this? > >mikko.aittola@nokia.com wrote: > >Hi, > > >So since 6.1 doesn't apply to Diameter Clients, my original questions >remain unanswered. Any comments? > > >I think Section 6.1 clearly does apply to Diameter Clients. Of course >there is identified parts that apply only to agents. >Yes, the parts that describe the routing mechanism. > > >I'm afraid I can't understand what kind of case you think is not >covered by the specification. > > >BR, >Mikko > > > >-----Original Message----- >From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] >Sent: 30 January, 2004 16:29 >To: Aittola Mikko (Nokia-NET/Helsinki) >Cc: aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Diameter Client request routing > > >Mikko: > >So since 6.1 doesn't apply to Diameter Clients, my original questions >remain unanswered. Any comments? > >Harvell, Joe [RICH2:2Q40:EXCH] wrote: > > >Mikko: > >I have read this section. There is a good description of > >how request > >forwarding and routing work for Diameter Agents. However, > >a Diameter > >Client is not a Diameter Agent. > >I did find an example in section 2.8.2 that suggests that Diameter >Clients performs a "routing lookup." > > The example provided in Figure 2 depicts a request > issued from a NAS [Diameter Client], which is an > access device, for the user bob@example.com. Prior > to issuing th erequest, NAS performs a Diameter > route lookup, using "example.com" as the key, and > determines that the message is to be relayed to > DRL, which is a Diameter Relay. > >To me, this sounds like a Diameter Client following step 3 > >on page 72 > >in 6.1. However, this procedure describes how to process a > >received > >message; and this doesn't apply to messages originated by a > >Diameter > >Client. Also, the following description of request routing > >from 6.1 > >only applies to Diameter Agents: > > Note that an agent can forward a request to a host > described in the Destination-Host AVP only if the > host in question is included in its peer table > (see Section 2.7). Otherwise, the request is > routed based on the Destination-Realm only > (see Sections 6.1.6). > > > >mikko.aittola@nokia.com wrote: > > >Hi, > >May I suggest reading also Section 6.1, 'Diameter Request Routing >Overview'? :) > >It should be noted that according to the spec if Destination-Host >matches >the value of Destination-Realm can be ignored. > > >BR, >Mikko > > > > >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On >Behalf Of >ext Joe Harvell >Sent: 19 January, 2004 21:13 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Diameter Client request routing > > >I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based > >Routing Table), > >5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of >Diameter Base Protocol, and I am a little confused about how a >Diameter Peer is to be selected for sending a request from a >Diameter Client. > >Consider the case of a Diameter Client that does not implement >Diameter Peer Discovery. This means that Diameter Peers are >statically configured. The Capabilities Exchange process will >definitely identify the Realm and Host of each Diameter Peer. >However, the only cases in which a peer can be identified as a >candidate next hop for sending a particular request are > >as follows: > > 1) when its Realm matches the Destination-Realm of a message >with Destination-Realm only; and > 2) when its Realm and Host match the Destination-Realm and >Destination-Host of a message with a Destination-Realm and >Destination-Host. > >So how does a Diameter Client identify a candidate peer > >for sending > >messages in the other cases? > >Section 5.1 indicates that a Diameter Node should have > >established > >connections with a minimum of two (a primary and possibly > >multiple > >secondary) peers per realm. Does the "realm" in this > >context mean > >that both peers are members of the same realm, or that both peers >can route messages to a given Destination-Realm? Can Diameter >Agents forward requests for a Destination-Realm that is not their >Realm? > >When a Diameter Client has a request with a Destination-Realm and >Destination-Host, will all the primary and secondary > >peers described > >in 5.1 be able to route the request to that > >Destination-Host in that > >Destination-Realm? > >--- >Joe Harvell >Shasta GGSN Development >Nortel Networks >+1 972.685.4886 > > > > > > > > > From owner-aaa-wg@merit.edu Fri Jan 30 12:08:05 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 MAA28501 for ; Fri, 30 Jan 2004 12:08:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4401791255; Fri, 30 Jan 2004 12:07:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B92291254; Fri, 30 Jan 2004 12:07: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 8298091255 for ; Fri, 30 Jan 2004 12:07:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 419295DDDA; Fri, 30 Jan 2004 12:07:50 -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 940C25DDAD; Fri, 30 Jan 2004 12:07:48 -0500 (EST) Received: from eircellnotes5.eircell.ie (unverified) by mailsweep01.vodafone.ie (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 30 Jan 2004 17:11:58 +0000 To: "Christopher Richards" Cc: "'aaa-wg@merit.edu'" , owner-aaa-wg@merit.edu 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: Fri, 30 Jan 2004 17:07:39 +0000 X-MIMETrack: Serialize by Router on Notes5/Vodafone(Release 5.0.10 |March 22, 2002) at 01/30/2004 05:07:40 PM, Serialize complete at 01/30/2004 05:07:40 PM Content-Type: multipart/alternative; boundary="=_alternative 005E146080256E2B_=" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005E146080256E2B_= Content-Type: text/plain; charset="us-ascii" 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 ****************************************************************************** --=_alternative 005E146080256E2B_= Content-Type: text/html; charset="us-ascii"
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

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

--=_alternative 005E146080256E2B_=-- From owner-aaa-wg@merit.edu Sat Jan 31 01:04: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 BAA26040 for ; Sat, 31 Jan 2004 01:04:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC2CF9128B; Sat, 31 Jan 2004 01:03:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 952899128C; Sat, 31 Jan 2004 01:03: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 288789128B for ; Sat, 31 Jan 2004 01:03:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 03CF95DDEA; Sat, 31 Jan 2004 01:03:43 -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 D10255DD96; Sat, 31 Jan 2004 01:03:41 -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 i0V63f216981; Sat, 31 Jan 2004 08:03:41 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 31 Jan 2004 08:03:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 31 Jan 2004 08:03:38 +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: Sat, 31 Jan 2004 08:03:38 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thread-Index: AcPnU7J/1FwjVnuCQ06fQ2OvU9Fb0wAa7N9A From: To: , Cc: , X-OriginalArrivalTime: 31 Jan 2004 06:03:39.0008 (UTC) FILETIME=[F87AE800:01C3E7BF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Speaking with my chair hat on, and author hat off, I do have a comment: > I've no objection myself in principle to your mechanism of allocating=20 > quotas together for both units before and units after the tariff = change. =20 > As long as it is all optional.=20 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. thanks, John From owner-aaa-wg@merit.edu Sat Jan 31 01:49: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 BAA27461 for ; Sat, 31 Jan 2004 01:49:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A01BF91284; Sat, 31 Jan 2004 01:49:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6391991290; Sat, 31 Jan 2004 01:49: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 5CF2491284 for ; Sat, 31 Jan 2004 01:48:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F4B05DD94; Sat, 31 Jan 2004 01:48:59 -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 D1F735DDDF for ; Sat, 31 Jan 2004 01:48:56 -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 i0V6msM20563 for ; Sat, 31 Jan 2004 08:48:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 31 Jan 2004 08:48:54 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 31 Jan 2004 08:48:54 +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_01C3E7C6.4A5B2FF3" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Date: Sat, 31 Jan 2004 08:48:53 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thread-Index: AcPnS42Ng74UX5cnRNKdH+R/4YS4QgAeraZA From: To: , X-OriginalArrivalTime: 31 Jan 2004 06:48:54.0042 (UTC) FILETIME=[4AC437A0:01C3E7C6] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E7C6.4A5B2FF3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assigned issue 18. =20 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 30 January, 2004 18:09 To: 'aaa-wg@merit.edu' Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 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: 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.=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. 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 - 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 = 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 = 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. = 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 =20 The used units contains the amount of the units after tariff change = 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. = 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 = 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 = 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 - end of changes=20 Best Regards,=20 Chris Richards.=20 ------_=_NextPart_001_01C3E7C6.4A5B2FF3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DCC: Issue: Tariff Change mechanism.

Assigned issue 18.
 
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher=20 Richards
Sent: 30 January, 2004 18:09
To:=20 'aaa-wg@merit.edu'
Subject: [AAA-WG]: DCC: Issue: Tariff = Change=20 mechanism.

All,

Please find enclosed issue regarding the current = tariff change=20 mechanism specified in the DCC draft.
Best=20 Regards,
Chris Richards.



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: 8.16,=20 8.41 and 8.42

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

- Section 8.41, first and second 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=20 UTC when the
   tariff of the = service will=20 be changed.
    =
   The tariff change mechanism is optional for = client and=20 server and it
   is not used for = unit type=20 time, since the server has full control of
   the time. 
   =20
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=20 UTC when the
   tariff of the = service will=20 be changed.

   The tariff change mechanism is = optionally enabled=20 by the server for a
   Diameter = credit=20 control session or sub-session.


- Section 8.42:

FROM:
   The=20 Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and=20
   defines whether units are used = before,=20 after or straddled tariff
   = change when a=20 tariff change has occurred during the reporting period. =
   Omission of this AVP means that no tariff change = has been=20 occurred.
    =
   Tariff-Change-Usage can be one of the following. =
   
   =20 = UNIT_BEFORE_TARIFF_CHANGE        =             &= nbsp;           &n= bsp;=20 0
   
     The used units contains the amount = of the=20 units before tariff
     = change,=20 that is units measured from the point when the previous =
     measurement ended to the point when = tariff=20 change occurred.
    =
   =20 = UNIT_AFTER_TARIFF_CHANGE        &= nbsp;           &n= bsp;           &nb= sp; =20 1
 
     The used units contains the amount = of the=20 units after tariff change
     has=20 been occurred.
    =
   =20 = UNIT_INDETERMINATE         &= nbsp;           &n= bsp;           &nb= sp;      =20 2
   
     The used units contains the amount = of units=20 that straddle the
     = tariff=20 change (e.g. the metering process reports to the credit- =
     control client in blocks of n octets = and one=20 block straddled the
     = tariff=20 change).
TO:    =
   The Tariff-Change-Usage AVP (AVP code 452) is of = type=20 Enumerated.

   When present in the = Granted-Service-Units AVP,=20 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=20 AVP identified what
   resources = where used=20 before or after a tariff change during the reporting
   period.

   Omission of this AVP means that no = tariff change=20 is to be reported and/or
   none = has=20 occurred.
    =
   Tariff-Change-Usage can be one of the following. =
   
   =20 = UNIT_BEFORE_TARIFF_CHANGE        =             &= nbsp;           &n= bsp;=20 0
   
     When present in the = Granted-Service-Units AVP,=20 this value indicates
     the=20 amount of the units allocated for use before a tariff change =
     occurs.

     When present in the=20 Reported-Service-Units AVP, this value indicates
     the amount of resource units used = before a=20 tariff change had occurred.
   =20
   =20 = UNIT_AFTER_TARIFF_CHANGE        &= nbsp;           &n= bsp;           &nb= sp; =20 1
   
     When present in the = Granted-Service-Units AVP,=20 this value indicates
     the=20 amount of the units allocated for use after a tariff change =
     occurs.

     When present in the=20 Reported-Service-Units AVP, this value indicates
     the amount of resource units used = after tariff=20 change had occurred.
    =

- end of changes


Best Regards,
Chris = Richards.=20

------_=_NextPart_001_01C3E7C6.4A5B2FF3-- From owner-aaa-wg@merit.edu Sat Jan 31 01:51:05 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 BAA27491 for ; Sat, 31 Jan 2004 01:50:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F47A91292; Sat, 31 Jan 2004 01:50:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4886A91290; Sat, 31 Jan 2004 01:50: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 02D7191291 for ; Sat, 31 Jan 2004 01:50:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9B035DDFC; Sat, 31 Jan 2004 01:50:09 -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 B81F85DDCF; Sat, 31 Jan 2004 01:50:06 -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 i0V6o5228274; Sat, 31 Jan 2004 08:50:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 31 Jan 2004 08:50:05 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 31 Jan 2004 08:50:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E7C6.7474EB24" Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Date: Sat, 31 Jan 2004 08:50:03 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCC: Issue: Tariff Change mechanism. Thread-Index: AcPnTgivxl7CLfncRbaTt9UZxxA7aQAeGCew From: To: , Cc: , X-OriginalArrivalTime: 31 Jan 2004 06:50:04.0690 (UTC) FILETIME=[74E03F20:01C3E7C6] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E7C6.7474EB24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 If you want to resubmit it with changes, I'll add it to the issue = number. =20 thanks, John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Christopher Richards Sent: 30 January, 2004 18: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, =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. 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, Chris.=20 -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]=20 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,=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 =20 To: "'aaa-wg@merit.edu'" =20 cc: =20 Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism.=09 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 = 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 = 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 = 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=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 - 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 =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 *************************************************************************= ***** 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 *************************************************************************= ***** ------_=_NextPart_001_01C3E7C6.7474EB24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Chris,
 
If you=20 want to resubmit it with changes, I'll add it to the issue=20 number.
 
thanks,
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Christopher=20 Richards
Sent: 30 January, 2004 18:27
To:=20 'John.Prudhoe@vodafone.com'
Cc: 'aaa-wg@merit.edu';=20 owner-aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCC: Issue: = Tariff=20 Change mechanism.

Thanks for the reply John,
 
Since there are implementations that can generate straddling = usage=20 counts today, I don't have a problem leaving this value in the Tariff-Change-Usage=20 AVP.
However, I still think that the current proposed mechanism in = the draft=20 should address it's shortcomings as I described in the Issue email I = sent.=20 Will the change proposal be accepted as an issue to discuss? If so, = should I=20 resubmit the issue with the change described = above?
  Best=20 Regards,
Chris.

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


Hi=20 Chris,

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

There is a fundamental difference between tariffs changing = for a=20 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=20 as GPRS or 3G data services).

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

Regards, =

John.





"Christopher Richards"=20 <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu=20

30/01/2004 16:09 =

       =20
    =    =20 To:        "'aaa-wg@merit.edu'"=20 <aaa-wg@merit.edu>
        cc:      =20  
  =    =20   Subject:        [AAA-WG]: DCC: = Issue:=20 Tariff Change = mechanism.



All,

Please find enclosed = issue regarding=20 the current tariff change mechanism specified in the DCC = draft.
Best Regards,=20
Chris = Richards.


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

Rationale/Explanation of = issues:=20

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

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

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

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

Requested = changes:

- Section 5, last=20 paragraph:

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

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

- Section 8.16, new=20 paragraphs:

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

   When both = the=20 Tariff-Time-Change and Tariff-Change-Usage AVPs are = present,
  the server MUST include two separate = Granted-Service-Unit=20 AVPs (for the =
  same Service-Identifier = and/or=20 Rating-Group when 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 = tariff=20 change has occurred. =

- Section 8.16, last=20 paragraph:

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

- Section 8.41, first and = second=20 paragraphs:

FROM:
  The Tariff-Time-Change AVP (AVP code 451) is of = type Time,=20 and
  includes the time in seconds since January 1, 1900 = 00:00 UTC=20 when the
  tariff of the service will be changed. =
 =20  
  The tariff change mechanism is optional for client = and=20 server and it
  is not used for unit type time, since the = server=20 has full control of
  the time.  
 =20  
TO: =
  The Tariff-Time-Change = AVP (AVP=20 code 451) is of type Time, and
  includes the time in = seconds since=20 January 1, 1900 00:00 UTC when the
  tariff of the service = will be=20 changed.

   The tariff = change=20 mechanism is optionally enabled by the server for a
  = Diameter=20 credit control session or sub-session.

- Section = 8.42:

FROM:
  The=20 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.
   
  Tariff-Change-Usage can be one = of the=20 following.
   
  =  UNIT_BEFORE_TARIFF_CHANGE=20                   =    =20            0
  =  
 =20   The used 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 when = tariff change=20 occurred.
   
   UNIT_AFTER_TARIFF_CHANGE =  =20                   =    =20           1
 
   =20 The used units contains the amount of the units after tariff change=20
    has been occurred.
   
 =20  UNIT_INDETERMINATE             =  =20                   =    =20     2
   
    The used units = contains=20 the amount of units that straddle the
    tariff = change (e.g.=20 the metering process reports to the credit-
    control client in blocks of n octets and = one block=20 straddled the
    tariff change).
TO:    
  The Tariff-Change-Usage AVP = (AVP code=20 452) is of type Enumerated.=20

   When present = in the=20 Granted-Service-Units AVP, this AVP defines whether
  units are allocated to be used before or after a = tariff=20 change event.

   When present = in the=20 Used-Service-Units AVP, this AVP identified what
  resources where used before or after a tariff = change=20 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  UNIT_BEFORE_TARIFF_CHANGE           =  =20                   =  =20  0
   
    When present in the=20 Granted-Service-Units AVP, this value indicates
    the amount of the units allocated for use = before a=20 tariff change =
    = occurs.

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

     When = present in=20 the Reported-Service-Units AVP, this value indicates
    the amount of resource units used after = tariff=20 change had occurred.
   =20

- end of = changes

Best Regards,
Chris Richards.=20



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

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

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

------_=_NextPart_001_01C3E7C6.7474EB24-- From owner-aaa-wg@merit.edu Sat Jan 31 07:15:13 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 HAA18976 for ; Sat, 31 Jan 2004 07:15:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38B3B91291; Sat, 31 Jan 2004 07:14:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 043BF91295; Sat, 31 Jan 2004 07:14: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 39D0691291 for ; Sat, 31 Jan 2004 07:14:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 264F05DE16; Sat, 31 Jan 2004 07:14: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 242855DE05 for ; Sat, 31 Jan 2004 07:14:53 -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 i0VCEp210672 for ; Sat, 31 Jan 2004 14:14:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 31 Jan 2004 14:14:51 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 31 Jan 2004 14:14: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]: Diameter Client request routing Date: Sat, 31 Jan 2004 14:14:49 +0200 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAAEF3@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter Client request routing Thread-Index: AcPnULjZbdNTdSpOTd2HpLY266zpygAobVVg From: To: X-OriginalArrivalTime: 31 Jan 2004 12:14:51.0395 (UTC) FILETIME=[D3DB7530:01C3E7F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > then my only question is whether a Diameter Node's identity > (what it sends for Origin-Host in CER) is expected to be unique=20 > only within a Realm, or unique even across Realms. According to the spec DiameterIdentity is unique even across Realms. BR, Mikko > -----Original Message----- > From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] > Sent: 30 January, 2004 18:47 > To: Aittola Mikko (Nokia-NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter Client request routing >=20 >=20 > Mikko: >=20 > This boils down to a difference of opinion on whether 6.1 applies to=20 > Diameter Clients (and Diameter Servers for that matter). If=20 > this is the=20 > case, then my only question is whether a Diameter Node's=20 > identity (what=20 > it sends for Origin-Host in CER) is expected to be unique=20 > only within a=20 > Realm, or unique even across Realms. >=20 > If 6.1 does apply to all Diameter Nodes, then that is not=20 > clear in the=20 > Diameter Base spec. I have replied to your questions below... >=20 > mikko.aittola@nokia.com wrote: >=20 > >Hi, > > > >Can you describe an example problem-case that you think is=20 > not covered by the > >specification? > > > I have. Refer to my original email. >=20 > > > >Also, did you only look at the text in Section 6.1 without > >regarding what is said in other parts of the spec, for > >example in sub-sections of 6.1? > > > Yes, I have read the entire spec, with particular attention=20 > to 6.1 and=20 > its subsections. >=20 > > There is also text elsewhere > >about the routing tables etc. > > > Yes, I have seen references to this. In almost all cases, the text=20 > describes the action of Diameter Agents or actions of Diameter Nodes=20 > receiving requests and then forwarding/routing them. >=20 > The only case I have found where it is suggested that something other=20 > than a Diameter Agent uses the routing mechanism described in=20 > 6.1 is the=20 > description of the example in 2.8.2, which I have already included. >=20 > > > >I think it is not useful to copy-paste here all the routing=20 > related text > >that applies to Diameter Clients. It wouldn't make the text=20 > any easier > >to understand. > > > Have you even looked at Section 6.1 since I posed this question? >=20 > > > > > >BR, > >Mikko > > > > > >-----Original Message----- > >From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] > >Sent: 30 January, 2004 17:28 > >To: Aittola Mikko (Nokia-NET/Helsinki) > >Cc: aaa-wg@merit.edu > >Subject: Re: [AAA-WG]: Diameter Client request routing > > > > > >Mikko: > > > >I find nothing in 6.1 that describes how a Diameter Client=20 > routes requests it originates. Could you identify specific=20 > text from that section that suggests it does apply to=20 > Diameter Clients? > > > >Does anyone else have an opinon on this? > > > >mikko.aittola@nokia.com wrote: > > > >Hi, > > > > =20 > >So since 6.1 doesn't apply to Diameter Clients, my original=20 > questions=20 > >remain unanswered. Any comments? > > =20 > > > >I think Section 6.1 clearly does apply to Diameter Clients. Of course > >there is identified parts that apply only to agents. > >Yes, the parts that describe the routing mechanism. > > > > > >I'm afraid I can't understand what kind of case you think is not > >covered by the specification. > > > > > >BR, > >Mikko > > > > > > =20 > >-----Original Message----- > >From: ext Joe Harvell [mailto:harvell@nortelnetworks.com] > >Sent: 30 January, 2004 16:29 > >To: Aittola Mikko (Nokia-NET/Helsinki) > >Cc: aaa-wg@merit.edu > >Subject: Re: [AAA-WG]: Diameter Client request routing > > > > > >Mikko: > > > >So since 6.1 doesn't apply to Diameter Clients, my original=20 > questions=20 > >remain unanswered. Any comments? > > > >Harvell, Joe [RICH2:2Q40:EXCH] wrote: > > > > =20 > >Mikko: > > > >I have read this section. There is a good description of=20 > > =20 > >how request=20 > > =20 > >forwarding and routing work for Diameter Agents. However,=20 > > =20 > >a Diameter=20 > > =20 > >Client is not a Diameter Agent. > > > >I did find an example in section 2.8.2 that suggests that Diameter=20 > >Clients performs a "routing lookup." > > > > The example provided in Figure 2 depicts a request > > issued from a NAS [Diameter Client], which is an > > access device, for the user bob@example.com. Prior > > to issuing th erequest, NAS performs a Diameter > > route lookup, using "example.com" as the key, and > > determines that the message is to be relayed to > > DRL, which is a Diameter Relay. > > > >To me, this sounds like a Diameter Client following step 3=20 > > =20 > >on page 72=20 > > =20 > >in 6.1. However, this procedure describes how to process a=20 > > =20 > >received=20 > > =20 > >message; and this doesn't apply to messages originated by a=20 > > =20 > >Diameter=20 > > =20 > >Client. Also, the following description of request routing=20 > > =20 > >from 6.1=20 > > =20 > >only applies to Diameter Agents: > > > > Note that an agent can forward a request to a host > > described in the Destination-Host AVP only if the > > host in question is included in its peer table > > (see Section 2.7). Otherwise, the request is > > routed based on the Destination-Realm only > > (see Sections 6.1.6). > > > > > > > >mikko.aittola@nokia.com wrote: > > > > =20 > >Hi, > > > >May I suggest reading also Section 6.1, 'Diameter Request Routing=20 > >Overview'? :) > > > >It should be noted that according to the spec if Destination-Host=20 > >matches > >the value of Destination-Realm can be ignored. > > > > > >BR, > >Mikko > > > > > > > > =20 > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On=20 > >Behalf Of > >ext Joe Harvell > >Sent: 19 January, 2004 21:13 > >To: aaa-wg@merit.edu > >Subject: [AAA-WG]: Diameter Client request routing > > > > > >I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based=20 > > =20 > >Routing Table),=20 > > =20 > >5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of=20 > >Diameter Base Protocol, and I am a little confused about how a=20 > >Diameter Peer is to be selected for sending a request from a=20 > >Diameter Client. > > > >Consider the case of a Diameter Client that does not implement=20 > >Diameter Peer Discovery. This means that Diameter Peers are=20 > >statically configured. The Capabilities Exchange process will=20 > >definitely identify the Realm and Host of each Diameter Peer. =20 > >However, the only cases in which a peer can be identified as a=20 > >candidate next hop for sending a particular request are=20 > > =20 > >as follows: > > =20 > > 1) when its Realm matches the Destination-Realm of a message=20 > >with Destination-Realm only; and > > 2) when its Realm and Host match the Destination-Realm and=20 > >Destination-Host of a message with a Destination-Realm and=20 > >Destination-Host. > > > >So how does a Diameter Client identify a candidate peer=20 > > =20 > >for sending=20 > > =20 > >messages in the other cases? > > > >Section 5.1 indicates that a Diameter Node should have=20 > > =20 > >established=20 > > =20 > >connections with a minimum of two (a primary and possibly=20 > > =20 > >multiple=20 > > =20 > >secondary) peers per realm. Does the "realm" in this=20 > > =20 > >context mean=20 > > =20 > >that both peers are members of the same realm, or that both peers=20 > >can route messages to a given Destination-Realm? Can Diameter=20 > >Agents forward requests for a Destination-Realm that is not their=20 > >Realm? > > > >When a Diameter Client has a request with a Destination-Realm and=20 > >Destination-Host, will all the primary and secondary=20 > > =20 > >peers described=20 > > =20 > >in 5.1 be able to route the request to that=20 > > =20 > >Destination-Host in that=20 > > =20 > >Destination-Realm? > > > >--- > >Joe Harvell > >Shasta GGSN Development > >Nortel Networks > >+1 972.685.4886 > > > > > > =20 > > =20 > > =20 > > > > =20 > > =20 > > >=20 >=20