From diffserv-admin@ietf.org Sun Apr 1 17:51:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16565 for ; Sun, 1 Apr 2001 17:51:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28139; Sun, 1 Apr 2001 17:30:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28068 for ; Sun, 1 Apr 2001 17:30:09 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12504 for ; Sun, 1 Apr 2001 17:30:08 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA31122; Sun, 1 Apr 2001 14:29:38 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA24626; Sun, 1 Apr 2001 14:29:29 -0700 Message-ID: <3AC64D2C.EABBF107@hursley.ibm.com> Date: Sat, 31 Mar 2001 15:33:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Larry Jones CC: diffserv@ietf.org Subject: Re: [Diffserv] The relation between PDB's and the SLSs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Larry, Some history and context: we took a firm decision when the diffserv WG was chartered that it would not discuss end to end service definitions, and would even more certainly not discuss service level agreements. This was to allow (and force) the WG to concentrate on low level mechanisms, a bite-sized problem we felt able to tackle. Indeed it has only taken us 3 years to get these mechanisms approximately defined :-) The PDB work was added in response to a clear feeling in the community that we needed to try to specify edge to edge behavior, at least in a statistical fashion. Now a PDB defines some parameters, but it does not define their values. Just to invent a trivial example, a PDB might have exactly three parameters, a loss rate L that is not exceeded for percentage P of intervals of length T. In my personal opinion (this is not a WG opinion), an SLS based on that PDB would simply specify values for {L,P,T}, e.g. {L=0.1%, P=99.9%, T= 10 seconds}. So to me an SLS is simply a PDB with its parameters set to numerical values. I personally disagree with the extract you quote. If there isn't a clear mapping between PDB parameters and SLS parameters, the SLS isn't implementable. The customer might see parameters one step more abstract in an SLA, but SLAs aren't in IETF scope at all. However, this is not and will not be a topic for the diffserv WG itself. That's why there is a move to create a separate IETF activity for SLSs. Now, if the SLS work ended up with parameters that didn't map readily to PDB parameters, we'd have a problem. But since no PDBs have been approved for publication yet, except the Default PDB which has no parameters, we aren't at that point yet. The diffserv co-chairs still believe that we don't have enough practical deployment experience yet to freeze the choice of PDB or SLS parameters. Brian Larry Jones wrote: > > Could someone inform me of how the PDB activities occuring the the DiffServ > working group or related to (or not related to) the SLS Internet Drafts such > as "Service Level Specification Semantics and Parameters". I have only just > recently been tracking the workgroup but intuitively it appears that the > objectives may be somehat overlapping. If not I an intereseted in if there > has been some formalism established regarding how the two activities relate > to each other. > > In "Service Level Specfication and Usage Framework", by Yves T' Jones et. > al. it states that "The specification of SLSs is out of the scope of the > DiffServ WG. The definition of PDB's could however have an impact on the SLS > definition.... It is important to keep in mind that in general the PDB > definitions and their attributes are not expected to be directly visible to > customers at the SLS level". > > This distinction is somewhat perplexing to me since it is not clear why the > PDB can not be itself be used instead of the SLS formalism specified in > those references. Can somewhat help me out with the formalism in how the two > transport domain level specifications are intended to coexist. > > thanks in advance, > > Larry Jones > Verizon Laboratories _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 06:46:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28014 for ; Mon, 2 Apr 2001 06:46:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13579; Mon, 2 Apr 2001 06:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13548 for ; Mon, 2 Apr 2001 06:16:45 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25338 for ; Mon, 2 Apr 2001 06:16:44 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f32AGTe00826; Mon, 2 Apr 2001 12:16:29 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 2863AC099; Mon, 2 Apr 2001 13:23:32 +0200 (CEST) Date: Mon, 02 Apr 2001 12:18:57 +0200 From: Marcus Brunner To: Brian E Carpenter , Larry Jones Cc: diffserv@ietf.org Subject: Re: [Diffserv] The relation between PDB's and the SLSs Message-ID: <2666426651.986213937@[192.168.102.79]> In-Reply-To: <3AC64D2C.EABBF107@hursley.ibm.com> X-Mailer: Mulberry/2.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, I aggree, that there is not enough deployment experience. On the other hand, without at least PDB/SLS proposals, it is very difficult to convience potential customers to use DiffServ -> deployment at all. Today I see many ISPs/Operators not jumping on DiffServ, because they do not see what "Service" can be provided using the DiffServ mechanisms. Furthermore, they are interested in end-to-end services. Without working at least into the direction of end-to-end services, there is low chance to deploy DiffServ. Marcus --On Saturday, March 31, 2001 3:33 PM -0600 Brian E Carpenter wrote: [...] > Now, if the SLS work ended up with parameters that didn't map readily > to PDB parameters, we'd have a problem. But since no PDBs have been > approved for publication yet, except the Default PDB which has no > parameters, we aren't at that point yet. The diffserv co-chairs still > believe that we don't have enough practical deployment experience yet > to freeze the choice of PDB or SLS parameters. > [...] -------------------------------------- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 09:28:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08008 for ; Mon, 2 Apr 2001 09:28:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16247; Mon, 2 Apr 2001 09:06:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16216 for ; Mon, 2 Apr 2001 09:06:28 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06678 for ; Mon, 2 Apr 2001 09:06:29 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA71542; Mon, 2 Apr 2001 06:05:55 -0700 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA25848; Mon, 2 Apr 2001 06:05:58 -0700 Message-ID: <3AC87926.5F9038BF@hursley.ibm.com> Date: Mon, 02 Apr 2001 08:05:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Larry Jones CC: diffserv@ietf.org Subject: Re: [Diffserv] Can no longer find/access the Virtual Wire PDB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Larry, Internet Drafts expire after 6 months unless the authors refresh them, which the VW authors have not done. Brian Larry Jones wrote: > > Hi > > It appears that the Virtual Wire PDB draft can no longer be found in the > Internet Drafts. Has it been removed? > > On another note, I retract my last message regarding PDBs/SLSs. The relation > between SLSs and PDBs is clear in the AF PDB draft. However, there could > stand to be more discussion on the that relationship in the SLS Internet > Drafts (e.g. "Service Specification and Usage Framework"). But thats a > different mailing list. > > Larry Jones > Verizon Laboratories _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 09:33:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08278 for ; Mon, 2 Apr 2001 09:33:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16372; Mon, 2 Apr 2001 09:14:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16345 for ; Mon, 2 Apr 2001 09:14:22 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07058 for ; Mon, 2 Apr 2001 09:14:24 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA29214; Mon, 2 Apr 2001 06:13:51 -0700 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA18716; Mon, 2 Apr 2001 06:13:53 -0700 Message-ID: <3AC87B01.12C4D40@hursley.ibm.com> Date: Mon, 02 Apr 2001 08:13:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Marcus Brunner CC: diffserv@ietf.org Subject: Re: [Diffserv] The relation between PDB's and the SLSs References: <2666426651.986213937@[192.168.102.79]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Actually I think ISPs are interested in edge to edge services, because they know they can never guarantee end to end; it's customers who care about end to end services. But it's precisely because of the chicken and egg problem that we started the PDB work, and now we need the R&D community to give us some feedback. Regards Brian Marcus Brunner wrote: > > Brian, > > I aggree, that there is not enough deployment experience. On the other > hand, without at least PDB/SLS proposals, it is very difficult to convience > potential customers to use DiffServ -> deployment at all. > > Today I see many ISPs/Operators not jumping on DiffServ, because they do > not see what "Service" can be provided using the DiffServ mechanisms. > Furthermore, they are interested in end-to-end services. Without working at > least into the direction of end-to-end services, there is low chance to > deploy DiffServ. > > Marcus > > --On Saturday, March 31, 2001 3:33 PM -0600 Brian E Carpenter > wrote: > > [...] > > > Now, if the SLS work ended up with parameters that didn't map readily > > to PDB parameters, we'd have a problem. But since no PDBs have been > > approved for publication yet, except the Default PDB which has no > > parameters, we aren't at that point yet. The diffserv co-chairs still > > believe that we don't have enough practical deployment experience yet > > to freeze the choice of PDB or SLS parameters. > > > [...] > -------------------------------------- > Dr. Marcus Brunner > C&C Research Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.tik.ee.ethz.ch/~brunner > > Adenauerplatz 6 > D-69115 Heidelberg > Germany > > Phone: +49 (0)6221/ 9051129 > Fax: +49 (0)6221/ 9051155 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 09:40:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08818 for ; Mon, 2 Apr 2001 09:40:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16613; Mon, 2 Apr 2001 09:22:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16582 for ; Mon, 2 Apr 2001 09:22:44 -0400 (EDT) Received: from hotmail.com (f176.law6.hotmail.com [216.32.241.176]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07560 for ; Mon, 2 Apr 2001 09:22:46 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Apr 2001 06:22:16 -0700 Received: from 193.137.239.226 by lw6fd.law6.hotmail.msn.com with HTTP; Mon, 02 Apr 2001 13:22:15 GMT X-Originating-IP: [193.137.239.226] From: "Maria do C閡 Jord鉶" To: diffserv@ietf.org Date: Mon, 02 Apr 2001 13:22:15 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2001 13:22:16.0195 (UTC) FILETIME=[EF9D7530:01C0BB77] Subject: [Diffserv] DiffServ implementation in a linux machine Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id JAA16613 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA08818 Hi, I'm an Informatic student, and now I'm working in project that involves DiffServ configuration in a Linux machine and I have to make some analyses in traffic, and to make this i need some DiffServ tools like ALTQ, but i need more than this. Could you send me some links about another DiffServ tools (or software) to analyse traffic ? Thanks, Ceu Jord鉶 _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 12:28:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18648 for ; Mon, 2 Apr 2001 12:28:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20190; Mon, 2 Apr 2001 12:07:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20158 for ; Mon, 2 Apr 2001 12:07:29 -0400 (EDT) Received: from www.k.ro (root@www.k.ro [194.102.255.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17554 for ; Mon, 2 Apr 2001 12:07:28 -0400 (EDT) Received: (from www@localhost) by www.k.ro (8.11.2/8.11.2) id f32G7Pa16894; Mon, 2 Apr 2001 19:07:25 +0300 Date: Mon, 02 Apr 2001 19:07:25 +0300 Message-Id: <200104021607.f32G7Pa16894@www.k.ro> From: Rares SERBAN X-Mailer: Super-Mail@k.ro http://mail.k.ro/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-IP: 138.96.152.99 To: "LarryJones" Cc: diffserv@ietf.org Subject: RE: [Diffserv] The relation between PDB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Larry, >In "Service Level Specfication and Usage Framework", by Yves T' Jones et. >al. it states that "The specification of SLSs is out of the scope of the >DiffServ WG. The definition of PDB's could however have an impact on the SLS >definition.... It is important to keep in mind that in general the PDB >definitions and their attributes are not expected to be directly visible to >customers at the SLS level". Service Level Specifications are defined by a Service Level Agreement between User/ISP or ISP/ISP. PDB defines multiple objects. With these objects we can built parameters for SLS.(instantiate) The problem is how to establish a comon language between User/ISP, ISP/ISP ("laws")for setting parameters? How many parameters needs one ISP and hom many another? etc. PDB "language" describes/defines(may be managed) the objects (inside). > >This distinction is somewhat perplexing to me since it is not clear why the >PDB can not be itself be used instead of the SLS formalism specified in >those references. Can somewhat help me out with the formalism in how the two >transport domain level specifications are intended to coexist. Here, I can give some references because some people are working at this subject. http://www-sop.inria.fr/rodeo/Rares.Serban/Research.html May be is not so clear. May be you will find some articles, presentations. Thank you, R. ------------------------------ K Free E-mail http://www.k.ro/ by KappaNet http://www.kappa.ro/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 12:30:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18750 for ; Mon, 2 Apr 2001 12:30:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18555; Mon, 2 Apr 2001 10:51:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18524 for ; Mon, 2 Apr 2001 10:51:47 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13053 for ; Mon, 2 Apr 2001 10:51:48 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA31030; Mon, 2 Apr 2001 07:51:13 -0700 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA24784; Mon, 2 Apr 2001 07:51:17 -0700 Message-ID: <3AC891C3.B417537B@hursley.ibm.com> Date: Mon, 02 Apr 2001 09:50:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Maria do =?iso-8859-1?Q?C=E9u=20Jord=E3o?= CC: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ implementation in a linux machine References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA18525 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id KAA18555 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA18750 Hi, This sort of question is more appropriate for the diffserv implementation list. Please see http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv co-chair "Maria do C閡 Jord鉶" wrote: > > Hi, > I'm an Informatic student, and now I'm working in project that involves > DiffServ configuration in a Linux machine and I have to make some analyses > in traffic, and to make this i need some DiffServ tools like ALTQ, but i > need more than this. Could you send me some links about another DiffServ > tools (or software) to analyse traffic ? > > Thanks, > Ceu Jord鉶 > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 2 17:04:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01165 for ; Mon, 2 Apr 2001 17:04:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24599; Mon, 2 Apr 2001 16:43:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24568 for ; Mon, 2 Apr 2001 16:43:09 -0400 (EDT) Received: from mailman.packetdesign.com ([65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00082 for ; Mon, 2 Apr 2001 16:43:10 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f32Kgf288258 for ; Mon, 2 Apr 2001 13:42:41 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3AC8E57A.3A65AEE2@packetdesign.com> Date: Mon, 02 Apr 2001 13:47:54 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] TCP urgent DATA vs DIFFSERV EF DATA References: <200103301743.MAA28748@ietf.org> <3AC4DCC2.17D06A31@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit And, perhaps tangentially to the discussion below, but as far as "expanding MF classification in a DS node to also include...", there isn't any called out limit on how many (or how few) fields can get called out in a multifield classifier. A particular implementation may limit you. Now as to the wisdom of including any particular field, that isn't addressed by diffserv. Kathie Brian E Carpenter wrote: > > That was what I expected, and that being so it does seem more > like a topic for e2e-interest than this list. > > Brian > > John Wroclawski wrote: > > > > At 12:42 PM -0500 3/30/01, Jeff Norman wrote: > > >It may be outside the scope of this WG, since we might be dealing > > >with implementation here, but does anyone see any problem or issues > > >with expanding MF classification in a DS node to also include the TCP > > >URG and ACK flags? > > > > > >Comments and opinions welcome. > > > > > >--Jeff > > > > Including URG would need careful thought. URG is not out of band > > data, it's an indication that there's something urgent later on in > > the in-band stream. So the goal would be to get the whole stream to > > the receiver faster. Pulling URG-flagged packets into a different > > PHB, and thus likely delivering them out of order, might make the > > situation worse by triggering congestion control and retransmissions. > > > > --john > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 3 08:14:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28061 for ; Tue, 3 Apr 2001 08:14:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12232; Tue, 3 Apr 2001 07:42:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12201 for ; Tue, 3 Apr 2001 07:42:09 -0400 (EDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26379 for ; Tue, 3 Apr 2001 07:42:08 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id NAA13906 for ; Tue, 3 Apr 2001 13:33:28 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA26425 for ; Tue, 3 Apr 2001 13:36:07 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id NAA00371 for ; Tue, 3 Apr 2001 13:41:45 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id NAA08689 for ; Tue, 3 Apr 2001 13:41:50 +0200 (MET DST) Message-ID: <01a401c0bc32$cf7b39c0$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: References: <200103301743.MAA28748@ietf.org> <3AC4DCC2.17D06A31@hursley.ibm.com> <3AC8E57A.3A65AEE2@packetdesign.com> Date: Tue, 3 Apr 2001 13:39:57 +0200 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] (DiffServ) Role / Interface Type / Interface Index Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, In the PIB, the DataPath is linked to a role and a role is linked to an interface type (corresponding to a capability set). In the MIB, the DataPath is linked to an IfIndex. The question is : When receiving a new Datapath Entry from the PDP, a PEP has to map it towards several interfaces (each has an IfIndex), how the device (PEP) know which interface belongs to a specific capability set ? Where is this information ? I had red about a Policy Auxiliary Mib for this mapping... what is it exactly ? Thanks -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Software and Services Strategic Program - VIPeR Marcoussis, France Tel +33 1 69 63 41 87 Fax +33 1 69 63 11 69 yacine.el_mghazli@ms.alcatel.fr ---------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 3 08:47:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28802 for ; Tue, 3 Apr 2001 08:47:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13004; Tue, 3 Apr 2001 08:24:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12975 for ; Tue, 3 Apr 2001 08:24:48 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28218 for ; Tue, 3 Apr 2001 08:24:47 -0400 (EDT) Message-Id: <200104031224.IAA28218@ietf.org> Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Tue, 3 Apr 2001 08:23:36 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H9V0AAR4; Tue, 3 Apr 2001 08:23:34 -0400 Received: from tweedy (dhcp223-130.engeast.baynetworks.com [192.32.223.130]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWRXPR; Tue, 3 Apr 2001 08:23:35 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 03 Apr 2001 08:22:58 -0400 To: Yacine El Mghazli X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] (DiffServ) Role / Interface Type / Interface Index Cc: diffserv In-Reply-To: <01a401c0bc32$cf7b39c0$c2f809bc@ms.alcatel.fr> References: <200103301743.MAA28748@ietf.org> <3AC4DCC2.17D06A31@hursley.ibm.com> <3AC8E57A.3A65AEE2@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Yacine: Yes. The PEP have the Interface to RoleCombo mapping based on the Policy Auxiliary Mib. -- Kwok -- At 01:39 PM 4/3/01 +0200, Yacine El Mghazli wrote: >Hi, > >In the PIB, the DataPath is linked to a role and a role is linked to an >interface type (corresponding to a capability set). >In the MIB, the DataPath is linked to an IfIndex. > >The question is : > >When receiving a new Datapath Entry from the PDP, a PEP has to map it >towards several interfaces (each has an IfIndex), how the device (PEP) know >which interface belongs to a specific capability set ? >Where is this information ? >I had red about a Policy Auxiliary Mib for this mapping... what is it >exactly ? > >Thanks > >-- Yacine El Mghazli >---------------------------------------------------------------------- > Alcatel R&I > Software and Services Strategic Program - VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr >---------------------------------------------------------------------- > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 3 14:05:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10989 for ; Tue, 3 Apr 2001 14:05:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18105; Tue, 3 Apr 2001 13:46:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18084 for ; Tue, 3 Apr 2001 13:46:07 -0400 (EDT) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10040 for ; Tue, 3 Apr 2001 13:46:06 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GB8009BQ9BZMT@firewall.mcit.com> for diffserv@ietf.org; Tue, 3 Apr 2001 17:45:35 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GB8008019BTZT@pmismtp01.wcomnet.com> for diffserv@ietf.org; Tue, 03 Apr 2001 17:45:35 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GB80080N9BLRH@pmismtp01.wcomnet.com> for diffserv@ietf.org; Tue, 03 Apr 2001 17:45:22 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Tue, 03 Apr 2001 17:45:21 +0000 Content-return: allowed Date: Tue, 03 Apr 2001 17:45:19 +0000 From: "Iliff, Tina" To: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F569D@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_Jcc6B/9SdEyNveAUqFb9xA)" Subject: [Diffserv] qosAssuredRate PRIORITY Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_Jcc6B/9SdEyNveAUqFb9xA) Content-type: text/plain; charset=iso-8859-1 All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff --Boundary_(ID_Jcc6B/9SdEyNveAUqFb9xA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable qosAssuredRate PRIORITY

All,

It is not clear to me from reading = both the diffserv-pib-03 and the diffserv-model-06 drafts in which = order the values of the PRIORITY field in the qosAssuredRate PRC are = processed.  In other words, would 1 indicate a higher priority = than 2 or vice versa?

Regards,
Tina Iliff

--Boundary_(ID_Jcc6B/9SdEyNveAUqFb9xA)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 3 16:49:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16551 for ; Tue, 3 Apr 2001 16:49:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20987; Tue, 3 Apr 2001 16:35:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20954 for ; Tue, 3 Apr 2001 16:35:18 -0400 (EDT) Received: from uni03mr.unity.ncsu.edu ([152.1.1.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16021 for ; Tue, 3 Apr 2001 16:35:15 -0400 (EDT) Received: from anr.mcnc.org (vinay@hickory.csc.ncsu.edu [152.1.205.74]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id QAA24393; Tue, 3 Apr 2001 16:26:13 -0400 (EDT) Message-ID: <3ACA31F3.4C9C00AF@anr.mcnc.org> Date: Tue, 03 Apr 2001 16:26:27 -0400 From: vinay mahadik Reply-To: vamahadi@unity.ncsu.edu Organization: MCNC - Advanced Networking Research/NCSU/Mahadik.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: FOCUS-IDS@SECURITYFOCUS.COM, diffserv@ietf.org, ids@uow.edu.au CC: vamahadi@unity.ncsu.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Monitoring DiffServ. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi - We are researching on the possibility of having a distributed statistical IDS for our DiffServ domain. We have in the past deployed the SRI-NIDES algorithm to monitor and protect OSPF routers (JiNao project at MCNC). Briefly, what we have done is to profile aggregate/macro- DiffServ flows to detect, statistically, packet dropping/delaying/remarking attacks in the domain when one ore more core or edge routers have been compromised. We are still more interested in protecting certain 'critical' communications for which we plan to use micro-flow level rule-based and statistical anomaly detection on the traffic. It is for this rule-based detection, that I was looking for more ideas/input. What parameters/'rules' would an IDS designer consider important for monitoring microflow-level network traffic - specifically for DiffServ-domain traffic. For example, one rule we intend to use is to detect a non-zero or a significantly high packet-dropping rate of AF traffic with a low drop-priority. Another would be to detect remarking of EF/AF to BE and the other way around within (an appropriately paid/brokered) session. Yes, we have been prudent enough to note that anomaly != attack, but it *is* a good indication of the 'ill-health' of the diffserv domain. Ideas and criticism welcome. Thanks, Vinay. -- Mr. Mahadik, Vinay A. http://hickory.csc.ncsu.edu _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 08:39:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16180 for ; Wed, 4 Apr 2001 08:39:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09942; Wed, 4 Apr 2001 08:17:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09911 for ; Wed, 4 Apr 2001 08:17:18 -0400 (EDT) Received: from smtp.elogica.com.br (IDENT:root@[200.249.220.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15318 for ; Wed, 4 Apr 2001 08:17:17 -0400 (EDT) Received: from cin.ufpe.br ([200.249.43.22]) by smtp.elogica.com.br (8.9.3/8.9.3) with ESMTP id JAA25848; Wed, 4 Apr 2001 09:16:57 -0300 Message-ID: <3ACB111D.4811235E@cin.ufpe.br> Date: Wed, 04 Apr 2001 09:18:37 -0300 From: Carlos Alberto Kamienski X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Marcus Brunner , diffserv@ietf.org Subject: Re: [Diffserv] The relation between PDB's and the SLSs References: <2666426651.986213937@[192.168.102.79]> <3AC87B01.12C4D40@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian What do you mean by "it's customers who care about end to end services" ? Are you thinking in the end to end arguments to support this statement ? I think the idea of having ISPs cooperating through negotiation to deploy end to end services is that one ISP can't deploy worldwide e2e services by itself (even though it could want it) and advanced applications can't rely on best effort service to work properly. Carlos Kamienski Brian E Carpenter wrote: > Actually I think ISPs are interested in edge to edge services, because > they know they can never guarantee end to end; it's customers who care about > end to end services. But it's precisely because of the chicken and egg > problem that we started the PDB work, and now we need the R&D community > to give us some feedback. > > Regards > Brian > > Marcus Brunner wrote: > > > > Brian, > > > > I aggree, that there is not enough deployment experience. On the other > > hand, without at least PDB/SLS proposals, it is very difficult to convience > > potential customers to use DiffServ -> deployment at all. > > > > Today I see many ISPs/Operators not jumping on DiffServ, because they do > > not see what "Service" can be provided using the DiffServ mechanisms. > > Furthermore, they are interested in end-to-end services. Without working at > > least into the direction of end-to-end services, there is low chance to > > deploy DiffServ. > > > > Marcus > > > > --On Saturday, March 31, 2001 3:33 PM -0600 Brian E Carpenter > > wrote: > > > > [...] > > > > > Now, if the SLS work ended up with parameters that didn't map readily > > > to PDB parameters, we'd have a problem. But since no PDBs have been > > > approved for publication yet, except the Default PDB which has no > > > parameters, we aren't at that point yet. The diffserv co-chairs still > > > believe that we don't have enough practical deployment experience yet > > > to freeze the choice of PDB or SLS parameters. > > > > > [...] > > -------------------------------------- > > Dr. Marcus Brunner > > C&C Research Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.tik.ee.ethz.ch/~brunner > > > > Adenauerplatz 6 > > D-69115 Heidelberg > > Germany > > > > Phone: +49 (0)6221/ 9051129 > > Fax: +49 (0)6221/ 9051155 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 08:56:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16931 for ; Wed, 4 Apr 2001 08:56:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10424; Wed, 4 Apr 2001 08:42:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10393 for ; Wed, 4 Apr 2001 08:41:56 -0400 (EDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16285 for ; Wed, 4 Apr 2001 08:41:56 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA01120 for ; Wed, 4 Apr 2001 14:33:07 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA27154 for ; Wed, 4 Apr 2001 14:35:39 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA17056 for ; Wed, 4 Apr 2001 14:41:18 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id OAA06334 for ; Wed, 4 Apr 2001 14:41:23 +0200 (MET DST) Message-ID: <016c01c0bd04$460845c0$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: Subject: [Diffserv] CountActTable Date: Wed, 4 Apr 2001 14:38:47 +0200 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit In the lattest DS PIB : Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > Action Tables > A general extensible framework and examples of parameterization > tables for Absolute Drop, Mark and Count actions. and page 11 : > 4.5.1. DSCP Mark Action PRC > (...) > 4.5.2. Absolute Drop Action So why is there no Count Action Table in the PIB ? However there is an CountActTable in the MIB...I feel confused. Thanx -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Software and Services Strategic Program - VIPeR Marcoussis, France Tel +33 1 69 63 41 87 Fax +33 1 69 63 11 69 yacine.el_mghazli@ms.alcatel.fr ---------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 11:11:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22420 for ; Wed, 4 Apr 2001 11:11:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12833; Wed, 4 Apr 2001 10:55:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12808 for ; Wed, 4 Apr 2001 10:55:03 -0400 (EDT) Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21679 for ; Wed, 4 Apr 2001 10:55:01 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GB900HDPW0Y18@firewall.mcit.com> for diffserv@ietf.org; Wed, 4 Apr 2001 14:53:22 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GB900G01W0NX8@pmismtp01.wcomnet.com>; Wed, 04 Apr 2001 14:53:22 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GB900F6YW09IG@pmismtp01.wcomnet.com>; Wed, 04 Apr 2001 14:52:57 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 04 Apr 2001 14:52:56 +0000 Content-return: allowed Date: Wed, 04 Apr 2001 14:52:55 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Yacine El Mghazli'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56AC@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_7bt2nboj88ofBrIwy9XYEw)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_7bt2nboj88ofBrIwy9XYEw) Content-type: text/plain; charset=iso-8859-1 Yacine, I am just guessing here but it makes more sense to me to only have a count action in the MIB and not in the PIB. I do not consider counting of packets traversing certain datapath functional elements a piece of policy; however, I do consider it as part of a network nodes management. Tina Iliff -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Wednesday, April 04, 2001 7:39 AM To: diffserv@ietf.org Subject: [Diffserv] CountActTable In the lattest DS PIB : Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > Action Tables > A general extensible framework and examples of parameterization > tables for Absolute Drop, Mark and Count actions. and page 11 : > 4.5.1. DSCP Mark Action PRC > (...) > 4.5.2. Absolute Drop Action So why is there no Count Action Table in the PIB ? However there is an CountActTable in the MIB...I feel confused. Thanx -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Software and Services Strategic Program - VIPeR Marcoussis, France Tel +33 1 69 63 41 87 Fax +33 1 69 63 11 69 yacine.el_mghazli@ms.alcatel.fr ---------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_7bt2nboj88ofBrIwy9XYEw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

Yacine,

I am just guessing here but it makes = more sense to me to only have a count action in the MIB and not in the = PIB.  I do not consider counting of packets traversing certain = datapath functional elements a piece of policy; however, I do consider = it as part of a network nodes management.

Tina Iliff


      -----Original = Message-----
      From:   Yacine El = Mghazli [mailto:yacine.el_mghazli@al= catel.fr]
      Sent:   Wednesday, April 04, 2001 7:39 AM
      To:     diffserv@ietf.org
      Subject:       = [Diffserv] CountActTable

      In the lattest DS PIB :

      Quoted from the = draft-ietf-diffserv-pib-03.txt (page 5) :
      > Action Tables
      >      A = general extensible framework and examples of parameterization
      >      = tables for Absolute Drop, Mark and Count actions. 

      and page 11 :
      > 4.5.1.  DSCP Mark Action = PRC
      > (...)
      > 4.5.2.  Absolute Drop = Action

      So why is there no Count Action Table = in the PIB ?
      However there is an CountActTable in = the MIB...I feel confused.

      Thanx

      -- Yacine El Mghazli
      ---------------------------------------------------------= -------------
        Alcatel R&I
        Software and Services = Strategic Program - VIPeR
        Marcoussis, France
        Tel  +33 1 69 63 41 = 87
        Fax  +33 1 69 63 11 = 69
        = yacine.el_mghazli@ms.alcatel.fr
      ---------------------------------------------------------= -------------


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_7bt2nboj88ofBrIwy9XYEw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 11:23:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22968 for ; Wed, 4 Apr 2001 11:23:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12913; Wed, 4 Apr 2001 10:57:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12870 for ; Wed, 4 Apr 2001 10:57:04 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21768 for ; Wed, 4 Apr 2001 10:57:02 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA72648; Wed, 4 Apr 2001 07:56:28 -0700 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA26266; Wed, 4 Apr 2001 07:56:31 -0700 Message-ID: <3ACB35FF.657CEDCB@hursley.ibm.com> Date: Wed, 04 Apr 2001 09:55:59 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Carlos Alberto Kamienski CC: Marcus Brunner , diffserv@ietf.org Subject: Re: [Diffserv] The relation between PDB's and the SLSs References: <2666426651.986213937@[192.168.102.79]> <3AC87B01.12C4D40@hursley.ibm.com> <3ACB111D.4811235E@cin.ufpe.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Carlos Alberto Kamienski wrote: > > Brian > > What do you mean by "it's customers who care about end to end services" ? > Are you thinking in the end to end arguments to support this statement ? No, simply that the only people who depend on end to end service are actual customers. ISPs can only control edge to edge service. > > I think the idea of having ISPs cooperating through negotiation to deploy end to end > services is that one ISP can't deploy worldwide e2e services by itself (even though it > could want it) and advanced applications can't rely on best effort service to work properly. The network runs on bilateral connections between ISPs. It's at the bilateral peering points that PDB parameters will be measured. If we try to extend standardisation to a wider scope than that, we will surely fail. In any case, diffserv is entirely based on the edge to edge model, and anything outside that scope belongs on another mailing list. Brian > > Carlos Kamienski > > Brian E Carpenter wrote: > > > Actually I think ISPs are interested in edge to edge services, because > > they know they can never guarantee end to end; it's customers who care about > > end to end services. But it's precisely because of the chicken and egg > > problem that we started the PDB work, and now we need the R&D community > > to give us some feedback. > > > > Regards > > Brian > > > > Marcus Brunner wrote: > > > > > > Brian, > > > > > > I aggree, that there is not enough deployment experience. On the other > > > hand, without at least PDB/SLS proposals, it is very difficult to convience > > > potential customers to use DiffServ -> deployment at all. > > > > > > Today I see many ISPs/Operators not jumping on DiffServ, because they do > > > not see what "Service" can be provided using the DiffServ mechanisms. > > > Furthermore, they are interested in end-to-end services. Without working at > > > least into the direction of end-to-end services, there is low chance to > > > deploy DiffServ. > > > > > > Marcus > > > > > > --On Saturday, March 31, 2001 3:33 PM -0600 Brian E Carpenter > > > wrote: > > > > > > [...] > > > > > > > Now, if the SLS work ended up with parameters that didn't map readily > > > > to PDB parameters, we'd have a problem. But since no PDBs have been > > > > approved for publication yet, except the Default PDB which has no > > > > parameters, we aren't at that point yet. The diffserv co-chairs still > > > > believe that we don't have enough practical deployment experience yet > > > > to freeze the choice of PDB or SLS parameters. > > > > > > > [...] > > > -------------------------------------- > > > Dr. Marcus Brunner > > > C&C Research Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.tik.ee.ethz.ch/~brunner > > > > > > Adenauerplatz 6 > > > D-69115 Heidelberg > > > Germany > > > > > > Phone: +49 (0)6221/ 9051129 > > > Fax: +49 (0)6221/ 9051155 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 11:25:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23045 for ; Wed, 4 Apr 2001 11:25:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13450; Wed, 4 Apr 2001 11:10:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13420 for ; Wed, 4 Apr 2001 11:10:50 -0400 (EDT) Received: from mel.alcatel.fr (na5.alcatel.fr [194.133.58.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22367 for ; Wed, 4 Apr 2001 11:10:48 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA08058; Wed, 4 Apr 2001 17:01:14 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA00091; Wed, 4 Apr 2001 17:02:54 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id RAA24499; Wed, 4 Apr 2001 17:08:33 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id RAA21894; Wed, 4 Apr 2001 17:08:39 +0200 (MET DST) Message-ID: <028d01c0bd18$d8982bd0$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: "Iliff, Tina" , References: <492EB4A3F68CD411ABE800508B69362E3F56AC@RIPEXCH002.wcomnet.com> Subject: Re: [Diffserv] CountActTable Date: Wed, 4 Apr 2001 17:06:37 +0200 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > I am just guessing here but it makes more sense to me to only have a count > action in the MIB and not in the PIB. I do not consider counting of packets > traversing certain datapath functional elements a piece of policy; however, > I do consider it as part of a network nodes management. Do you mean that counting packets is only managed using SNMP ? > Tina Iliff > > > -----Original Message----- > From: Yacine El Mghazli > [mailto:yacine.el_mghazli@alcatel.fr] > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action Tables > > A general extensible framework and examples of > parameterization > > tables for Absolute Drop, Mark and Count actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count Action Table in the PIB ? > However there is an CountActTable in the MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > ---------------------------------------------------------------------- > Alcatel R&I > Software and Services Strategic Program - VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > ---------------------------------------------------------------------- > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 11:50:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23777 for ; Wed, 4 Apr 2001 11:49:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13599; Wed, 4 Apr 2001 11:14:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13569 for ; Wed, 4 Apr 2001 11:14:38 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22598 for ; Wed, 4 Apr 2001 11:14:36 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GB900A55WZ8DZ@firewall.mcit.com> for diffserv@ietf.org; Wed, 4 Apr 2001 15:13:56 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GB900401WZ6RU@dgismtp02.wcomnet.com>; Wed, 04 Apr 2001 15:13:56 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GB9002BMWYVSD@dgismtp02.wcomnet.com>; Wed, 04 Apr 2001 15:13:43 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 04 Apr 2001 15:13:42 +0000 Content-return: allowed Date: Wed, 04 Apr 2001 15:13:41 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Yacine El Mghazli'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56B3@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_1TCPe25P3V7o4ZnfYPC6rg)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_1TCPe25P3V7o4ZnfYPC6rg) Content-type: text/plain; charset=ISO-8859-1 Yacine, Like I said, it is just an assumption or a guess. Someone else will have to answer. The Accounting PIB may be a good place for a counter. However, I have not taken a look at that draft in a while. Tina Iliff -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > I am just guessing here but it makes more sense to me to only have a count > action in the MIB and not in the PIB. I do not consider counting of packets > traversing certain datapath functional elements a piece of policy; however, > I do consider it as part of a network nodes management. Do you mean that counting packets is only managed using SNMP ? > Tina Iliff > > > -----Original Message----- > From: Yacine El Mghazli > [mailto:yacine.el_mghazli@alcatel.fr] > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action Tables > > A general extensible framework and examples of > parameterization > > tables for Absolute Drop, Mark and Count actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count Action Table in the PIB ? > However there is an CountActTable in the MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > ---------------------------------------------------------------------- > Alcatel R&I > Software and Services Strategic Program - VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > ---------------------------------------------------------------------- > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > --Boundary_(ID_1TCPe25P3V7o4ZnfYPC6rg) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

Yacine,

Like I said, it is just an assumption = or a guess.  Someone else will have to answer.  The = Accounting PIB may be a good place for a counter.  However, I have = not taken a look at that draft in a while.

Tina Iliff


      -----Original = Message-----
      From:   Yacine El = Mghazli [mailto:yacine.el_mghazli= @ms.alcatel.fr]
      Sent:   Wednesday, April 04, 2001 10:07 AM
      To:     Iliff, Tina; diffserv@ietf.org
      Subject:       = Re: [Diffserv] CountActTable

      > I am just guessing here but it = makes more sense to me to only have a count
      > action in the MIB and not in the = PIB.  I do not consider counting of
      packets
      > traversing certain datapath = functional elements a piece of policy;
      however,
      > I do consider it as part of a = network nodes management.

      Do you mean that counting packets is = only managed using SNMP ?

      > Tina Iliff
      >
      >
      > -----Original = Message-----
      > From: Yacine El Mghazli
      > [mailto:yacine.el_mghazli@al= catel.fr]
      > Sent: Wednesday, April 04, 2001 = 7:39 AM
      > To: diffserv@ietf.org
      > Subject: [Diffserv] = CountActTable
      >
      > In the lattest DS PIB :
      >
      > Quoted from the = draft-ietf-diffserv-pib-03.txt (page 5) :
      > > Action Tables
      > = >      A general extensible framework and = examples of
      > parameterization
      > = >      tables for Absolute Drop, Mark and = Count actions.
      >
      > and page 11 :
      > > 4.5.1.  DSCP Mark = Action PRC
      > > (...)
      > > 4.5.2.  Absolute Drop = Action
      >
      > So why is there no Count Action = Table in the PIB ?
      > However there is an = CountActTable in the MIB...I feel
      > confused.
      >
      > Thanx
      >
      > -- Yacine El Mghazli
      >
      > = ----------------------------------------------------------------------
      >   Alcatel = R&I
      >   Software and = Services Strategic Program - VIPeR
      >   Marcoussis, = France
      >   Tel  +33 1 69 = 63 41 87
      >   Fax  +33 1 69 = 63 11 69
      >   = yacine.el_mghazli@ms.alcatel.fr
      >
      > = ----------------------------------------------------------------------
      >
      >
      > = _______________________________________________
      > diffserv mailing list
      > diffserv@ietf.org
      > http://www1.ietf.org/mailman/listinfo/diffserv
      > Archive:
      >
      http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.h
      > tml
      >

--Boundary_(ID_1TCPe25P3V7o4ZnfYPC6rg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 12:02:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24229 for ; Wed, 4 Apr 2001 12:02:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14574; Wed, 4 Apr 2001 11:47:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14465 for ; Wed, 4 Apr 2001 11:47:46 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23730 for ; Wed, 4 Apr 2001 11:47:43 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA39822; Wed, 4 Apr 2001 08:47:09 -0700 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA21656; Wed, 4 Apr 2001 08:47:09 -0700 Message-ID: <3ACB41CF.DADF93FF@hursley.ibm.com> Date: Wed, 04 Apr 2001 10:46:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iliff, Tina" CC: "'Yacine El Mghazli'" , diffserv@ietf.org Subject: Re: [Diffserv] CountActTable References: <492EB4A3F68CD411ABE800508B69362E3F56B3@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Traditionally, MIBs are for monitoring, so including counters is normal. PIBs are supposed to be for configuration management, so counters indeed don't seem relevant. Brian > "Iliff, Tina" wrote: > > Yacine, > > Like I said, it is just an assumption or a guess. Someone else will have to answer. The Accounting PIB may be a good place > for a counter. However, I have not taken a look at that draft in a while. > > Tina Iliff > > -----Original Message----- > From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr] > Sent: Wednesday, April 04, 2001 10:07 AM > To: Iliff, Tina; diffserv@ietf.org > Subject: Re: [Diffserv] CountActTable > > > I am just guessing here but it makes more sense to me to only have a count > > action in the MIB and not in the PIB. I do not consider counting of > packets > > traversing certain datapath functional elements a piece of policy; > however, > > I do consider it as part of a network nodes management. > > Do you mean that counting packets is only managed using SNMP ? > > > Tina Iliff > > > > > > -----Original Message----- > > From: Yacine El Mghazli > > [mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, 2001 7:39 AM > > To: diffserv@ietf.org > > Subject: [Diffserv] CountActTable > > > > In the lattest DS PIB : > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > > Action Tables > > > A general extensible framework and examples of > > parameterization > > > tables for Absolute Drop, Mark and Count actions. > > > > and page 11 : > > > 4.5.1. DSCP Mark Action PRC > > > (...) > > > 4.5.2. Absolute Drop Action > > > > So why is there no Count Action Table in the PIB ? > > However there is an CountActTable in the MIB...I feel > > confused. > > > > Thanx > > > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > Alcatel R&I > > Software and Services Strategic Program - VIPeR > > Marcoussis, France > > Tel +33 1 69 63 41 87 > > Fax +33 1 69 63 11 69 > > yacine.el_mghazli@ms.alcatel.fr > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 13:38:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26977 for ; Wed, 4 Apr 2001 13:38:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16560; Wed, 4 Apr 2001 13:14:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16531 for ; Wed, 4 Apr 2001 13:14:12 -0400 (EDT) Received: from longsys.com ([63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26250 for ; Wed, 4 Apr 2001 13:14:11 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f34HDm509776 for ; Wed, 4 Apr 2001 17:13:48 GMT Message-Id: <4.2.2.20010404125349.00bc9dd0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 04 Apr 2001 13:13:38 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] CountActTable In-Reply-To: <492EB4A3F68CD411ABE800508B69362E3F56B3@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The Count Action is a diffserv packet handling action. Including it in a configuration causes counting to be done. It sure seems that this action ought to be configurable with the PIB, just like every other Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would have to use SNMP to CONFIGURE this element in order to later use SNMP to retreive the counts. This Action is not itself a counter that would go in an Accounting PIB, or only in an SNMP MIB. Yours, Joel M. Halpern At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: >Yacine, > >Like I said, it is just an assumption or a guess. Someone else will have >to answer. The Accounting PIB may be a good place for a >counter. However, I have not taken a look at that draft in a while. > >Tina Iliff >-----Original Message----- From: Yacine El Mghazli >[mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > I am just guessing here but it makes more sense to me to only have a > count > action in the MIB and not in the PIB. I do not consider > counting of packets > traversing certain datapath functional elements a > piece of policy; however, > I do consider it as part of a network nodes > management. > >Do you mean that counting packets is only managed using SNMP ? > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > Mghazli > > [mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > Tables > > A general extensible framework and examples of > > parameterization > > tables for Absolute Drop, Mark and Count > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > Action Table in the PIB ? > However there is an CountActTable in the > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > ---------------------------------------------------------------------- > > Alcatel R&I > Software and Services Strategic Program - > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > ---------------------------------------------------------------------- > > > > _______________________________________________ > diffserv > mailing list > diffserv@ietf.org > > http://www1.ietf.org/mailm > an/listinfo/diffserv > > Archive: > > t.h>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > list.h > tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 14:17:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27994 for ; Wed, 4 Apr 2001 14:17:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17221; Wed, 4 Apr 2001 13:56:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17194 for ; Wed, 4 Apr 2001 13:56:27 -0400 (EDT) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27473 for ; Wed, 4 Apr 2001 13:56:26 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GBA00EMJ4FT9X@firewall.mcit.com> for diffserv@ietf.org; Wed, 4 Apr 2001 17:55:05 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBA005014FRK8@dgismtp02.wcomnet.com>; Wed, 04 Apr 2001 17:55:05 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBA0047J4FEJQ@dgismtp02.wcomnet.com>; Wed, 04 Apr 2001 17:54:50 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 04 Apr 2001 17:54:50 +0000 Content-return: allowed Date: Wed, 04 Apr 2001 17:54:48 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Joel M. Halpern'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56B9@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_vzhUzbgymonVtA0MQUjsMA)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_vzhUzbgymonVtA0MQUjsMA) Content-type: text/plain; charset=ISO-8859-1 Here are some excerpts from diffserv-model-06: At the lowest level considered here, are individual functional datapath elements, each with their own configuration parameters and management counters and flags. using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management functions such as billing applications. I find these excerpts unclear as to determining if a PIB or MIB or both should implement a data structure to support the definition of a Counter Action. Tina Iliff -----Original Message----- From: Joel M. Halpern [mailto:joel@longsys.com] Sent: Wednesday, April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: [Diffserv] CountActTable The Count Action is a diffserv packet handling action. Including it in a configuration causes counting to be done. It sure seems that this action ought to be configurable with the PIB, just like every other Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would have to use SNMP to CONFIGURE this element in order to later use SNMP to retreive the counts. This Action is not itself a counter that would go in an Accounting PIB, or only in an SNMP MIB. Yours, Joel M. Halpern At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: >Yacine, > >Like I said, it is just an assumption or a guess. Someone else will have >to answer. The Accounting PIB may be a good place for a >counter. However, I have not taken a look at that draft in a while. > >Tina Iliff >-----Original Message----- From: Yacine El Mghazli >[mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > I am just guessing here but it makes more sense to me to only have a > count > action in the MIB and not in the PIB. I do not consider > counting of packets > traversing certain datapath functional elements a > piece of policy; however, > I do consider it as part of a network nodes > management. > >Do you mean that counting packets is only managed using SNMP ? > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > Mghazli > > [mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > Tables > > A general extensible framework and examples of > > parameterization > > tables for Absolute Drop, Mark and Count > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > Action Table in the PIB ? > However there is an CountActTable in the > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > ---------------------------------------------------------------------- > > Alcatel R&I > Software and Services Strategic Program - > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > ---------------------------------------------------------------------- > > > > _______________________________________________ > diffserv > mailing list > diffserv@ietf.org > > http://www1.ietf.org/mailm > an/listinfo/diffserv > > Archive: > > t.h>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > list.h > tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_vzhUzbgymonVtA0MQUjsMA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

Here are some excerpts from = diffserv-model-06:

At the lowest level = considered here, are = individual functional datapath elements, each with their own configuration parameters and management counters and flags.

using a Counter element downstream of the Meter, it might also be used to help in collecting = data for out-of-band management = functions such as billing applications.

I find these excerpts unclear as to = determining if a PIB or MIB or both should implement a data structure = to support the definition of a Counter Action.

Tina Iliff


      -----Original = Message-----
      From:   Joel M. Halpern = [mailto:joel@longsys.com]=
      Sent:   Wednesday, April 04, 2001 12:14 PM
      To:     diffserv@ietf.org
      Subject:       = RE: [Diffserv] CountActTable

      The Count Action is a diffserv packet = handling action.  Including it in a
      configuration causes counting to be = done.  It sure seems that this action
      ought to be configurable with the = PIB, just like every other Diffserv
      packet handling action (Meter, Mark, = Drop).  Otherwise, one would have to
      use SNMP to CONFIGURE this element in = order to later use SNMP to retreive
      the counts.

      This Action is not itself a counter = that would go in an Accounting PIB, or
      only in an SNMP MIB.

      Yours,
      Joel M. Halpern

      At 03:13 PM 4/4/01 +0000, Iliff, Tina = wrote:

      >Yacine,
      >
      >Like I said, it is just an = assumption or a guess.  Someone else will have
      >to answer.  The Accounting = PIB may be a good place for a
      >counter.  However, I have = not taken a look at that draft in a while.
      >
      >Tina Iliff
      >-----Original Message-----  = From:   Yacine El Mghazli
      >[<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.= alcate
      >l.fr]  Sent:   = Wednesday, April 04, 2001 10:07 AM  To:     = Iliff, Tina;
      >diffserv@ietf.org  = Subject:        Re: [Diffserv] = CountActTable
      >
      > > I am just guessing here but = it makes more sense to me to only have a
      > count  > action in the = MIB and not in the PIB.  I do not consider
      > counting of  packets  = > traversing certain datapath functional elements a
      > piece of policy;  = however,  > I do consider it as part of a network nodes
      > management.
      >
      >Do you mean that counting packets = is only managed using SNMP ?
      >
      > > Tina Iliff  >  = >  > -----Original Message-----  > From: Yacine El =
      > Mghazli  >
      > [<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr]
       >   > Sent: = Wednesday, April 04, 2001 7:39 AM  > To: = diffserv@ietf.org  >
      > Subject: [Diffserv] = CountActTable  >  > In the lattest DS PIB :  = >  >
      > Quoted from the = draft-ietf-diffserv-pib-03.txt (page 5) :  > > Action =
      > Tables  > = >      A general extensible framework and = examples of  >
      > parameterization  > = >      tables for Absolute Drop, Mark and = Count
      > actions.  >  > = and page 11 :  > > 4.5.1.  DSCP Mark Action PRC  = > >
      > (...)  > > = 4.5.2.  Absolute Drop Action  >  > So why is there = no Count
      > Action Table in the PIB ?  = > However there is an CountActTable in the
      > MIB...I feel  > = confused.  >  > Thanx  >  > -- Yacine = El Mghazli  >  >
      > = ----------------------------------------------------------------------&n= bsp; >
       >   Alcatel = R&I  >   Software and Services Strategic Program = -
      > VIPeR  >   = Marcoussis, France  >   Tel  +33 1 69 63 41 = 87  >   Fax  +33 1
      > 69 63 11 69  = >   yacine.el_mghazli@ms.alcatel.fr  >  > =
      > = ----------------------------------------------------------------------&n= bsp; >
       >  >  > = _______________________________________________  > diffserv =
      > mailing list  > = diffserv@ietf.org  >
      > <http://www1.ietf.org/mailman/listinfo/diffserv>= http://www1.ietf.org/mailm
      > an/listinfo/diffserv  > =
      > Archive:  >
      > <http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillis
      > t.h>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mail
      > list.h  > tml  = >


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_vzhUzbgymonVtA0MQUjsMA)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 15:43:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29815 for ; Wed, 4 Apr 2001 15:43:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19387; Wed, 4 Apr 2001 15:28:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19360 for ; Wed, 4 Apr 2001 15:27:56 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29529 for ; Wed, 4 Apr 2001 15:27:56 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA40472; Wed, 4 Apr 2001 12:27:18 -0700 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA23200; Wed, 4 Apr 2001 12:27:25 -0700 Message-ID: <3ACB7544.97E1174F@hursley.ibm.com> Date: Wed, 04 Apr 2001 14:25:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iliff, Tina" CC: diffserv@ietf.org Subject: Re: [Diffserv] CountActTable References: <492EB4A3F68CD411ABE800508B69362E3F56B9@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I don't see the issue for the MIB: it does have counters and nobody is proposing to take them away. If you want counters in the PIB, now is the time to say so since there will be a new version very soon. The model isn't going to answer that question for you. Brian > "Iliff, Tina" wrote: > > Here are some excerpts from diffserv-model-06: > > At the lowest level considered here, are individual functional datapath elements, each with their own configuration parameters > and management counters and flags. > > using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management > functions such as billing applications. > > I find these excerpts unclear as to determining if a PIB or MIB or both should implement a data structure to support the > definition of a Counter Action. > > Tina Iliff > > -----Original Message----- > From: Joel M. Halpern [mailto:joel@longsys.com] > Sent: Wednesday, April 04, 2001 12:14 PM > To: diffserv@ietf.org > Subject: RE: [Diffserv] CountActTable > > The Count Action is a diffserv packet handling action. Including it in a > configuration causes counting to be done. It sure seems that this action > ought to be configurable with the PIB, just like every other Diffserv > packet handling action (Meter, Mark, Drop). Otherwise, one would have to > use SNMP to CONFIGURE this element in order to later use SNMP to retreive > the counts. > > This Action is not itself a counter that would go in an Accounting PIB, or > only in an SNMP MIB. > > Yours, > Joel M. Halpern > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > > > >Like I said, it is just an assumption or a guess. Someone else will have > >to answer. The Accounting PIB may be a good place for a > >counter. However, I have not taken a look at that draft in a while. > > > >Tina Iliff > >-----Original Message----- From: Yacine El Mghazli > >[mailto:yacine.el_mghazli@ms.alcate > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; > >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > > > I am just guessing here but it makes more sense to me to only have a > > count > action in the MIB and not in the PIB. I do not consider > > counting of packets > traversing certain datapath functional elements a > > piece of policy; however, > I do consider it as part of a network nodes > > management. > > > >Do you mean that counting packets is only managed using SNMP ? > > > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > > Mghazli > > > [mailto:yacine.el_mghazli@alcatel.fr] > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 16:19:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00752 for ; Wed, 4 Apr 2001 16:19:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19779; Wed, 4 Apr 2001 15:35:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19678 for ; Wed, 4 Apr 2001 15:35:48 -0400 (EDT) Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29683 for ; Wed, 4 Apr 2001 15:35:47 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GBA004IS92UMI@firewall.mcit.com> for diffserv@ietf.org; Wed, 4 Apr 2001 19:35:18 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GBA0090192KEB@pmismtp01.wcomnet.com>; Wed, 04 Apr 2001 19:35:18 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GBA004MH92H40@pmismtp01.wcomnet.com>; Wed, 04 Apr 2001 19:35:06 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 04 Apr 2001 19:35:05 +0000 Content-return: allowed Date: Wed, 04 Apr 2001 19:35:03 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Brian E Carpenter'" Cc: diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56BA@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_QeMa+AUmtT1leN9qA9IKfQ)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_QeMa+AUmtT1leN9qA9IKfQ) Content-type: text/plain; charset=iso-8859-1 I am still of the opinion that the Counter should only be included in the MIB. Tina Iliff -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Wednesday, April 04, 2001 2:26 PM To: Iliff, Tina Cc: diffserv@ietf.org Subject: Re: [Diffserv] CountActTable I don't see the issue for the MIB: it does have counters and nobody is proposing to take them away. If you want counters in the PIB, now is the time to say so since there will be a new version very soon. The model isn't going to answer that question for you. Brian > "Iliff, Tina" wrote: > > Here are some excerpts from diffserv-model-06: > > At the lowest level considered here, are individual functional datapath elements, each with their own configuration parameters > and management counters and flags. > > using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management > functions such as billing applications. > > I find these excerpts unclear as to determining if a PIB or MIB or both should implement a data structure to support the > definition of a Counter Action. > > Tina Iliff > > -----Original Message----- > From: Joel M. Halpern [mailto:joel@longsys.com] > Sent: Wednesday, April 04, 2001 12:14 PM > To: diffserv@ietf.org > Subject: RE: [Diffserv] CountActTable > > The Count Action is a diffserv packet handling action. Including it in a > configuration causes counting to be done. It sure seems that this action > ought to be configurable with the PIB, just like every other Diffserv > packet handling action (Meter, Mark, Drop). Otherwise, one would have to > use SNMP to CONFIGURE this element in order to later use SNMP to retreive > the counts. > > This Action is not itself a counter that would go in an Accounting PIB, or > only in an SNMP MIB. > > Yours, > Joel M. Halpern > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > > > >Like I said, it is just an assumption or a guess. Someone else will have > >to answer. The Accounting PIB may be a good place for a > >counter. However, I have not taken a look at that draft in a while. > > > >Tina Iliff > >-----Original Message----- From: Yacine El Mghazli > >[mailto:yacine.el_mghazli@ms.alcate > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; > >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > > > I am just guessing here but it makes more sense to me to only have a > > count > action in the MIB and not in the PIB. I do not consider > > counting of packets > traversing certain datapath functional elements a > > piece of policy; however, > I do consider it as part of a network nodes > > management. > > > >Do you mean that counting packets is only managed using SNMP ? > > > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > > Mghazli > > > [mailto:yacine.el_mghazli@alcatel.fr] > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > --Boundary_(ID_QeMa+AUmtT1leN9qA9IKfQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

I am still of the opinion that the = Counter should only be included in the MIB. 
Tina Iliff


      -----Original = Message-----
      From:   Brian E = Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
      Sent:   Wednesday, April 04, 2001 2:26 PM
      To:     Iliff, Tina
      Cc:     diffserv@ietf.org
      Subject:       = Re: [Diffserv] CountActTable

      I don't see the issue for the MIB: it = does have counters and nobody is
      proposing to take them away. If you = want counters in the PIB, now
      is the time to say so since there = will be a new version very soon.
      The model isn't going to answer that = question for you.

         Brian

      > "Iliff, Tina" = wrote:
      >
      > Here are some excerpts from = diffserv-model-06:
      >
      > At the lowest level considered = here, are individual functional datapath elements, each with their own = configuration parameters

      > and management counters and = flags.
      >
      > using a Counter element = downstream of the Meter, it might also be used to help in collecting = data for out-of-band management

      > functions such as billing = applications.
      >
      > I find these excerpts unclear as = to determining if a PIB or MIB or both should implement a data = structure to support the

      > definition of a Counter = Action.
      >
      > Tina Iliff
      >
      >         = ;  -----Original Message-----
      >         = ;  From:   Joel M. Halpern [mailto:joel@longsys.com]
      >         = ;  Sent:   Wednesday, April 04, 2001 12:14 PM
      >         = ;  To:     diffserv@ietf.org
      >         = ;  Subject:        RE: = [Diffserv] CountActTable
      >
      >         = ;  The Count Action is a diffserv packet handling action.  = Including it in a
      >         = ;  configuration causes counting to be done.  It sure seems = that this action
      >         = ;  ought to be configurable with the PIB, just like every other = Diffserv
      >         = ;  packet handling action (Meter, Mark, Drop).  Otherwise, = one would have to
      >         = ;  use SNMP to CONFIGURE this element in order to later use SNMP = to retreive
      >         = ;  the counts.
      >
      >         = ;  This Action is not itself a counter that would go in an = Accounting PIB, or
      >         = ;  only in an SNMP MIB.
      >
      >         = ;  Yours,
      >         = ;  Joel M. Halpern
      >
      >         = ;  At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote:
      >
      >         = ;  >Yacine,
      >         = ;  >
      >         = ;  >Like I said, it is just an assumption or a guess.  = Someone else will have
      >         = ;  >to answer.  The Accounting PIB may be a good place for = a
      >         = ;  >counter.  However, I have not taken a look at that = draft in a while.
      >         = ;  >
      >         = ;  >Tina Iliff
      >         = ;  >-----Original Message-----  From:   Yacine = El Mghazli
      >         = ;  >[<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.= alcate
      >         = ;  >l.fr]  Sent:   Wednesday, April 04, 2001 = 10:07 AM  To:     Iliff, Tina;
      >         = ;  >diffserv@ietf.org  = Subject:        Re: [Diffserv] = CountActTable
      >         = ;  >
      >         = ;  > > I am just guessing here but it makes more sense to me = to only have a
      >         = ;  > count  > action in the MIB and not in the = PIB.  I do not consider
      >         = ;  > counting of  packets  > traversing certain = datapath functional elements a
      >         = ;  > piece of policy;  however,  > I do consider = it as part of a network nodes
      >         = ;  > management.
      >         = ;  >
      >         = ;  >Do you mean that counting packets is only managed using = SNMP ?
      >         = ;  >
      >         = ;  > > Tina Iliff  >  >  > = -----Original Message-----  > From: Yacine El
      >         = ;  > Mghazli  >
      >         = ;  > [<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr]
      >         = ;   >   > Sent: Wednesday, April 04, 2001 = 7:39 AM  > To: diffserv@ietf.org  >
      >         = ;  > Subject: [Diffserv] CountActTable  >  > In = the lattest DS PIB :  >  >
      >         = ;  > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) = :  > > Action
      >         = ;  > Tables  > >      A = general extensible framework and examples of  >
      >         = ;  > parameterization  > = >      tables for Absolute Drop, Mark and = Count
      >         = ;  > actions.  >  > and page 11 :  > = > 4.5.1.  DSCP Mark Action PRC  > >
      >         = ;  > (...)  > > 4.5.2.  Absolute Drop = Action  >  > So why is there no Count
      >         = ;  > Action Table in the PIB ?  > However there is an = CountActTable in the
      >         = ;  > MIB...I feel  > confused.  >  > = Thanx  >  > -- Yacine El Mghazli  >  = >
      >         = ;  > = ----------------------------------------------------------------------&n= bsp; >
      >         = ;   >   Alcatel R&I  >   = Software and Services Strategic Program -
      >     &nbs= p;     > VIPeR  >   = Marcoussis, France  >   Tel  +33 1 69 63 41 = 87  >   Fax  +33 1
      >         = ;  > 69 63 11 69  >   = yacine.el_mghazli@ms.alcatel.fr  >  >
      >         = ;  > = ----------------------------------------------------------------------&n= bsp; >

--Boundary_(ID_QeMa+AUmtT1leN9qA9IKfQ)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 18:53:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03939 for ; Wed, 4 Apr 2001 18:53:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22805; Wed, 4 Apr 2001 18:40:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22773 for ; Wed, 4 Apr 2001 18:40:52 -0400 (EDT) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03635 for ; Wed, 4 Apr 2001 18:40:50 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GBA006DRHN9WG@firewall.mcit.com> for diffserv@ietf.org; Wed, 4 Apr 2001 22:40:22 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBA00701HN5TT@dgismtp02.wcomnet.com> for diffserv@ietf.org; Wed, 04 Apr 2001 22:40:21 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBA004JIHN46E@dgismtp02.wcomnet.com> for diffserv@ietf.org; Wed, 04 Apr 2001 22:40:16 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 04 Apr 2001 22:40:16 +0000 Content-return: allowed Date: Wed, 04 Apr 2001 22:40:15 +0000 From: "Iliff, Tina" To: "Iliff, Tina" , "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F56C9@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_9LmGqXM9e/Q60UGXqpT5EA)" Subject: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_9LmGqXM9e/Q60UGXqpT5EA) Content-type: text/plain; charset=ISO-8859-1 Tina Iliff MCIWorldCom ENSD (972)729-1620 -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff --Boundary_(ID_9LmGqXM9e/Q60UGXqpT5EA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: diffserv-pib-03: qosAssuredRate PRIORITY

Tina Iliff
MCIWorldCom ENSD
(972)729-1620


      -----Original = Message-----
      From:   Iliff, Tina =
      Sent:   Tuesday, April 03, 2001 12:45 PM
      To:     'diffserv@ietf.org'
      Subject:       = qosAssuredRate PRIORITY

      All,

      It is not clear to me from reading = both the diffserv-pib-03 and the diffserv-model-06 drafts in which = order the values of the PRIORITY field in the qosAssuredRate PRC are = processed.  In other words, would 1 indicate a higher priority = than 2 or vice versa?

      Regards,
      Tina Iliff

--Boundary_(ID_9LmGqXM9e/Q60UGXqpT5EA)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 4 19:48:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04674 for ; Wed, 4 Apr 2001 19:48:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23610; Wed, 4 Apr 2001 19:35:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23584 for ; Wed, 4 Apr 2001 19:35:38 -0400 (EDT) Received: from avocet.prod.itd.earthlink.net ([207.217.121.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04560 for ; Wed, 4 Apr 2001 19:35:37 -0400 (EDT) Received: from ANDREWHOME (user-vcauoi2.dsl.mindspring.com [216.175.98.66]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA10153; Wed, 4 Apr 2001 16:35:33 -0700 (PDT) From: "Andrew Smith" To: "Iliff, Tina" Cc: Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Date: Wed, 4 Apr 2001 16:47:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <492EB4A3F68CD411ABE800508B69362E3F56C9@RIPEXCH002.wcomnet.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Tina, The Model draft does not and should not attempt to define the syntax of "priority": there is an example there in section 7.1.2 that uses "1", "2" and "3" as priorities without defining what they mean but I don't think that is confusing enough to need changing. But your comment does apply for http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt as well as for the PIB so that ought to be changed there. Andrew -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 07:07:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27450 for ; Thu, 5 Apr 2001 07:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09450; Thu, 5 Apr 2001 06:38:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09419 for ; Thu, 5 Apr 2001 06:38:16 -0400 (EDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26441 for ; Thu, 5 Apr 2001 06:38:15 -0400 (EDT) Message-Id: <200104051038.GAA26441@ietf.org> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:00:42 -0100 From: "Rita de Groot" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:58:13 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] huidziekte Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 09:56:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02396 for ; Thu, 5 Apr 2001 09:55:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13535; Thu, 5 Apr 2001 09:39:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13507 for ; Thu, 5 Apr 2001 09:39:28 -0400 (EDT) Received: from avocet.prod.itd.earthlink.net ([207.217.121.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01838 for ; Thu, 5 Apr 2001 09:39:25 -0400 (EDT) Received: from ANDREWHOME (user-vcauoi2.dsl.mindspring.com [216.175.98.66]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id GAA04773; Thu, 5 Apr 2001 06:39:25 -0700 (PDT) From: "Andrew Smith" To: "Iliff, Tina" Cc: Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Date: Thu, 5 Apr 2001 06:51:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <492EB4A3F68CD411ABE800508B69362E3F56CA@RIPEXCH002.wcomnet.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit For the PIB and MIB? I don't know. That's why it needs fixing :-) Andrew -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, April 05, 2001 6:31 AM To: 'Andrew Smith' Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Andrew, So does a higher value for the PRIORITY attribute indicate a higher priority? I am gathering yes. Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Wednesday, April 04, 2001 6:48 PM To: Iliff, Tina Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Tina, The Model draft does not and should not attempt to define the syntax of "priority": there is an example there in section 7.1.2 that uses "1", "2" and "3" as priorities without defining what they mean but I don't think that is confusing enough to need changing. But your comment does apply for http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt as well as for the PIB so that ought to be changed there. Andrew -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 09:57:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02497 for ; Thu, 5 Apr 2001 09:57:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13438; Thu, 5 Apr 2001 09:32:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13409 for ; Thu, 5 Apr 2001 09:32:30 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01623 for ; Thu, 5 Apr 2001 09:32:28 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GBB00KR3MW23D@firewall.mcit.com> for diffserv@ietf.org; Thu, 5 Apr 2001 13:31:14 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GBB00B01MW0V6@pmismtp01.wcomnet.com>; Thu, 05 Apr 2001 13:31:13 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GBB008EUMVMVD@pmismtp01.wcomnet.com>; Thu, 05 Apr 2001 13:30:58 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 05 Apr 2001 13:30:58 +0000 Content-return: allowed Date: Thu, 05 Apr 2001 13:30:56 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY To: "'Andrew Smith'" Cc: diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56CA@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_76FD4LuJbrodOezu79EZaw)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_76FD4LuJbrodOezu79EZaw) Content-type: text/plain; charset=iso-8859-1 Andrew, So does a higher value for the PRIORITY attribute indicate a higher priority? I am gathering yes. Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Wednesday, April 04, 2001 6:48 PM To: Iliff, Tina Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Tina, The Model draft does not and should not attempt to define the syntax of "priority": there is an example there in section 7.1.2 that uses "1", "2" and "3" as priorities without defining what they mean but I don't think that is confusing enough to need changing. But your comment does apply for http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt as well as for the PIB so that ought to be changed there. Andrew -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff --Boundary_(ID_76FD4LuJbrodOezu79EZaw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate = PRIORITY

Andrew,

So does a higher value for the = PRIORITY attribute indicate a higher priority?  I am gathering = yes.

Tina Iliff


      -----Original = Message-----
      From:   Andrew Smith [mailto:andrew@allegronetworks= .com]
      Sent:   Wednesday, April 04, 2001 6:48 PM
      To:     Iliff, Tina
      Cc:     diffserv@ietf.org
      Subject:       = RE: [Diffserv] RE: = diffserv-pib-03:  qosAssuredRate PRIORITY

      Tina,

      The Model draft does not and should = not attempt to define the syntax of
      "priority": there is an = example there in section 7.1.2 that uses "1", = "2"
      and "3" as priorities = without defining what they mean but I don't think that
      is confusing enough to need = changing.

      But your comment does apply for
      http://www.ietf.org/internet-drafts/draft-ietf-diffser= v-mib-09.txt as well
      as for the PIB so that ought to be = changed there.

      Andrew


      -----Original Message-----
      From:   Iliff, Tina
      Sent:   Tuesday, April 03, = 2001 12:45 PM
      To:     = 'diffserv@ietf.org'
      Subject:        = qosAssuredRate PRIORITY
      All,
      It is not clear to me from reading = both the diffserv-pib-03 and the
      diffserv-model-06 drafts in which = order the values of the PRIORITY field in
      the qosAssuredRate PRC are = processed.  In other words, would 1 indicate a
      higher priority than 2 or vice = versa?
      Regards,
      Tina Iliff

--Boundary_(ID_76FD4LuJbrodOezu79EZaw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 11:34:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05464 for ; Thu, 5 Apr 2001 11:34:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14397; Thu, 5 Apr 2001 10:16:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14364 for ; Thu, 5 Apr 2001 10:16:26 -0400 (EDT) Received: from scaup.prod.itd.earthlink.net ([207.217.121.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02903 for ; Thu, 5 Apr 2001 10:16:24 -0400 (EDT) Received: from ANDREWHOME (user-vcaurtl.dsl.mindspring.com [216.175.111.181]) by scaup.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id HAA23129; Thu, 5 Apr 2001 07:16:24 -0700 (PDT) From: "Andrew Smith" To: "Iliff, Tina" Cc: Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Date: Thu, 5 Apr 2001 07:28:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <492EB4A3F68CD411ABE800508B69362E3F56CA@RIPEXCH002.wcomnet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit For the PIB and MIB? I don't know. That's why it needs fixing :-) Andrew -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, April 05, 2001 6:31 AM To: 'Andrew Smith' Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Andrew, So does a higher value for the PRIORITY attribute indicate a higher priority? I am gathering yes. Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Wednesday, April 04, 2001 6:48 PM To: Iliff, Tina Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Tina, The Model draft does not and should not attempt to define the syntax of "priority": there is an example there in section 7.1.2 that uses "1", "2" and "3" as priorities without defining what they mean but I don't think that is confusing enough to need changing. But your comment does apply for http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt as well as for the PIB so that ought to be changed there. Andrew -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 12:18:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06810 for ; Thu, 5 Apr 2001 12:18:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16507; Thu, 5 Apr 2001 12:00:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16445 for ; Thu, 5 Apr 2001 12:00:24 -0400 (EDT) Received: from avocet.prod.itd.earthlink.net ([207.217.121.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06308 for ; Thu, 5 Apr 2001 12:00:21 -0400 (EDT) Received: from ANDREWHOME (user-vcaunsp.dsl.mindspring.com [216.175.95.153]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA19568; Thu, 5 Apr 2001 09:00:20 -0700 (PDT) From: "Andrew Smith" To: "Iliff, Tina" Cc: Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Date: Thu, 5 Apr 2001 09:12:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <492EB4A3F68CD411ABE800508B69362E3F56CA@RIPEXCH002.wcomnet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit For the PIB and MIB? I don't know. That's why it needs fixing :-) Andrew -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, April 05, 2001 6:31 AM To: 'Andrew Smith' Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Andrew, So does a higher value for the PRIORITY attribute indicate a higher priority? I am gathering yes. Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Wednesday, April 04, 2001 6:48 PM To: Iliff, Tina Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Tina, The Model draft does not and should not attempt to define the syntax of "priority": there is an example there in section 7.1.2 that uses "1", "2" and "3" as priorities without defining what they mean but I don't think that is confusing enough to need changing. But your comment does apply for http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt as well as for the PIB so that ought to be changed there. Andrew -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 12:36:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07396 for ; Thu, 5 Apr 2001 12:36:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16775; Thu, 5 Apr 2001 12:17:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16745 for ; Thu, 5 Apr 2001 12:17:09 -0400 (EDT) Received: from anti_vir1.rad.co.il ([192.116.244.108]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06792 for ; Thu, 5 Apr 2001 12:17:06 -0400 (EDT) Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id SAA01838 for ; Thu, 5 Apr 2001 18:15:14 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id SAA01821; Thu, 5 Apr 2001 18:15:12 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Thu, 5 Apr 2001 17:19:38 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 18:15:35 +0200 Message-ID: From: Sasha Vainshtein To: "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com Cc: mpls@UU.NET, "'diffserv@ietf.org'" Date: Thu, 5 Apr 2001 18:15:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: Diff-Serv over MPLS Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, The reordering issue has been addressed in , "New Terminology for Diffserv" with an explicit reference to work on MPLS Support of Differentiated Services. Section 5 of this I-D introduces the notion of an Ordering Aggregate (OA) as A set of Behavior Aggregates that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class. I suggest that should be updated to allow only grouping of multiple OAs (and not BAs as it does) into a single E-LSP. The current I-D version explicitly states that L-LSP is established for a given (OA, FEC) class but is ambiguous when it comes to E-LSPs. Nabil, in his message in this thread, has noticed that RFC 2597 defines AF (y=1,2,3) as an OA for any fixed value of x (1-4). The suggested modification would prohibit configurations like one described in the original message. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] >>Sent: Thursday, April 05, 2001 3:39 PM >>To: flefauch@cisco.com; liwwu@cisco.com >>Cc: mpls@UU.NET >>Subject: Diff-Serv over MPLS >> >> >>hi all >> Could any of you please explain about the following >>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. >> >>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) >> >>"A single LSP can be used to support up to eight BAs >>of >>a given FEC, regardless of how many OAs these BAs >>span." >> >>A small doubt >> Suppose PHBs related to a PSC have been assigned to >>different E-LSPs (say AF11 to one LSP and AF12 to >>another LSP)and first few (say 1-10)Packets belonging >>to a microflow have been assigned to AF11 and later >>packets (say 10-15) to AF12. >>Is it not possible for the packets in AF12 LSP to get >>transferred before the packets in AF11 LSP? If that is >>the case the ordering constraint is violated i.e >>packets are reordered. (I think this may happen in >>the following case- if the LSPs are on different >>interfaces of a router and there may be some packets >>which are required to be served in the AF11 while the >>packets in AF12 may get immediately served as there >>are >>no packets before these which require service). >> >>thanks >>kk >> >>__________________________________________________ >>Do You Yahoo!? >>Get email at your own domain with Yahoo! Mail. >>http://personal.mail.yahoo.com/ >> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 12:44:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07593 for ; Thu, 5 Apr 2001 12:44:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17018; Thu, 5 Apr 2001 12:27:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16990 for ; Thu, 5 Apr 2001 12:27:06 -0400 (EDT) Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07072 for ; Thu, 5 Apr 2001 12:27:03 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GBB0020AUZRXR@firewall.mcit.com> for diffserv@ietf.org; Thu, 5 Apr 2001 16:26:15 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GBB00801UZC1C@pmismtp01.wcomnet.com>; Thu, 05 Apr 2001 16:26:15 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GBB0075NUZ9HE@pmismtp01.wcomnet.com>; Thu, 05 Apr 2001 16:25:58 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 05 Apr 2001 16:25:56 +0000 Content-return: allowed Date: Thu, 05 Apr 2001 16:25:52 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY To: "'Andrew Smith'" Cc: diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56D0@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_f+E3+8YTM1DpG4UB0tOfQg)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_f+E3+8YTM1DpG4UB0tOfQg) Content-type: text/plain; charset=iso-8859-1 I have received several copies of this response. Is there something wrong with the mailing list? Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Thursday, April 05, 2001 11:13 AM To: Iliff, Tina Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY For the PIB and MIB? I don't know. That's why it needs fixing :-) Andrew -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, April 05, 2001 6:31 AM To: 'Andrew Smith' Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Andrew, So does a higher value for the PRIORITY attribute indicate a higher priority? I am gathering yes. Tina Iliff -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Wednesday, April 04, 2001 6:48 PM To: Iliff, Tina Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY Tina, The Model draft does not and should not attempt to define the syntax of "priority": there is an example there in section 7.1.2 that uses "1", "2" and "3" as priorities without defining what they mean but I don't think that is confusing enough to need changing. But your comment does apply for http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-09.txt as well as for the PIB so that ought to be changed there. Andrew -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 03, 2001 12:45 PM To: 'diffserv@ietf.org' Subject: qosAssuredRate PRIORITY All, It is not clear to me from reading both the diffserv-pib-03 and the diffserv-model-06 drafts in which order the values of the PRIORITY field in the qosAssuredRate PRC are processed. In other words, would 1 indicate a higher priority than 2 or vice versa? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_f+E3+8YTM1DpG4UB0tOfQg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RE: diffserv-pib-03: qosAssuredRate = PRIORITY

I have received several copies of this = response.  Is there something wrong with the mailing list?

Tina Iliff


      -----Original = Message-----
      From:   Andrew Smith [mailto:andrew@allegronetworks= .com]
      Sent:   Thursday, April 05, 2001 11:13 AM
      To:     Iliff, Tina
      Cc:     diffserv@ietf.org
      Subject:       = RE: [Diffserv] RE: = diffserv-pib-03:  qosAssuredRate PRIORITY

      For the PIB and MIB? I don't know. = That's why it needs fixing :-)

      Andrew


      -----Original Message-----
      From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
      Sent: Thursday, April 05, 2001 6:31 = AM
      To: 'Andrew Smith'
      Cc: diffserv@ietf.org
      Subject: RE: [Diffserv] RE: = diffserv-pib-03: qosAssuredRate PRIORITY


      Andrew,
      So does a higher value for the = PRIORITY attribute indicate a higher
      priority?  I am gathering = yes.
      Tina Iliff


      -----Original Message-----
      From:   Andrew Smith [mailto:andrew@allegronetworks= .com]
      Sent:   Wednesday, April = 04, 2001 6:48 PM
      To:     Iliff, = Tina
      Cc:     = diffserv@ietf.org
      Subject:        RE: = [Diffserv] RE: diffserv-pib-03:  qosAssuredRate PRIORITY
      Tina,
      The Model draft does not and should = not attempt to define the syntax of
      "priority": there is an = example there in section 7.1.2 that uses "1", = "2"
      and "3" as priorities = without defining what they mean but I don't think that
      is confusing enough to need = changing.
      But your comment does apply = for
      http://www.ietf.org/internet-drafts/draft-ietf-diffser= v-mib-09.txt as well
      as for the PIB so that ought to be = changed there.
      Andrew


      -----Original Message-----
      From:   Iliff, Tina
      Sent:   Tuesday, April 03, = 2001 12:45 PM
      To:     = 'diffserv@ietf.org'
      Subject:        = qosAssuredRate PRIORITY
      All,
      It is not clear to me from reading = both the diffserv-pib-03 and the
      diffserv-model-06 drafts in which = order the values of the PRIORITY field in
      the qosAssuredRate PRC are = processed.  In other words, would 1 indicate a
      higher priority than 2 or vice = versa?
      Regards,
      Tina Iliff


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_f+E3+8YTM1DpG4UB0tOfQg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 5 15:24:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12001 for ; Thu, 5 Apr 2001 15:24:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19924; Thu, 5 Apr 2001 15:04:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19894 for ; Thu, 5 Apr 2001 15:04:55 -0400 (EDT) Received: from father.pmc-sierra.bc.ca ([216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11314 for ; Thu, 5 Apr 2001 15:04:53 -0400 (EDT) Received: (qmail 25157 invoked by uid 104); 5 Apr 2001 19:04:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.459147 secs); 05/04/2001 12:04:23 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 5 Apr 2001 19:04:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f35J4MB17445; Thu, 5 Apr 2001 12:04:22 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Apr 2001 12:05:10 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B9B@BBY1EXM01> From: Shahram Davari To: "'Sasha Vainshtein'" , "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com Cc: mpls@UU.NET, "'diffserv@ietf.org'" Date: Thu, 5 Apr 2001 12:05:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: Diff-Serv over MPLS Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Sasha, The Diffserv over MPLS draft is not introducing any changes to Diffserv. Therefore all the Diffserv standards must be followed including not reordering the packets belonging to a microflow. It is true that in theory it is possible to reorder packets that belong to a microflow if PHBs are not mapped properly to E-LSPs, but that is a misconfiguration. I think everybody knows that they should not misconfigure their network. I don't think we need to tell people how to avoid misordering, all we have to do is to require that no misordering to happen. Just as an example assume that an AF1x aggregate consists of only 2 microflows: A, and B. If A never exceeds its committed policed rate (therefore all packet belonging to A are AF11), and if B's committed rate is zero, in other words it always exceed its committed rate (therefore all its packets are AF12/AF13), then no reordering of microflow will happen if we send the AF11 aggregate through an E-LSP and the AF12/AF13 through another E-LSP. Not that I recommend such a configuration, but the above example shows a scenario that is actually compliant with Diffserv. Yours, -Shahram > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Thursday, April 05, 2001 12:16 PM > To: 'N S S Kishore Kankipati'; flefauch@cisco.com; liwwu@cisco.com > Cc: mpls@UU.NET; 'diffserv@ietf.org' > Subject: RE: Diff-Serv over MPLS > > > > Hi, > The reordering issue has been addressed in > , > "New Terminology for Diffserv" with an explicit > reference to work > on MPLS Support of Differentiated Services. > Section 5 of this I-D introduces the notion of an Ordering > Aggregate (OA) as > A set of Behavior Aggregates that share an ordering > constraint. > The set of PHBs that are applied to this set of > Behavior Aggregates > > constitutes a PHB scheduling class. > > I suggest that should > be updated > to > allow only grouping of multiple OAs (and not BAs as it > does) into > a single E-LSP. The current I-D version explicitly states > that L-LSP is established for a given (OA, FEC) class but is > ambiguous when it comes to E-LSPs. > > Nabil, in his message in this thread, has noticed that RFC 2597 > defines AF (y=1,2,3) as an OA for any fixed value > of x (1-4). > The suggested modification would prohibit > configurations like one > described > in the original message. > ______________________________________________ > With best regards, > Sasha Vainshtein > mailto: sasha@axerra.com > phone: +972-3-7659993 (office) > fax: +972-3-6487779 (office) > > > >>-----Original Message----- > >>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] > >>Sent: Thursday, April 05, 2001 3:39 PM > >>To: flefauch@cisco.com; liwwu@cisco.com > >>Cc: mpls@UU.NET > >>Subject: Diff-Serv over MPLS > >> > >> > >>hi all > >> Could any of you please explain about the following > >>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. > >> > >>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) > >> > >>"A single LSP can be used to support up to eight BAs > >>of > >>a given FEC, regardless of how many OAs these BAs > >>span." > >> > >>A small doubt > >> Suppose PHBs related to a PSC have been assigned to > >>different E-LSPs (say AF11 to one LSP and AF12 to > >>another LSP)and first few (say 1-10)Packets belonging > >>to a microflow have been assigned to AF11 and later > >>packets (say 10-15) to AF12. > >>Is it not possible for the packets in AF12 LSP to get > >>transferred before the packets in AF11 LSP? If that is > >>the case the ordering constraint is violated i.e > >>packets are reordered. (I think this may happen in > >>the following case- if the LSPs are on different > >>interfaces of a router and there may be some packets > >>which are required to be served in the AF11 while the > >>packets in AF12 may get immediately served as there > >>are > >>no packets before these which require service). > >> > >>thanks > >>kk > >> > >>__________________________________________________ > >>Do You Yahoo!? > >>Get email at your own domain with Yahoo! Mail. > >>http://personal.mail.yahoo.com/ > >> > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 05:30:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06768 for ; Fri, 6 Apr 2001 05:30:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07739; Fri, 6 Apr 2001 05:02:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07640 for ; Fri, 6 Apr 2001 05:02:45 -0400 (EDT) Received: from cisco.com ([144.254.52.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06527 for ; Fri, 6 Apr 2001 05:02:43 -0400 (EDT) Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-98.cisco.com [64.103.26.98]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA19097; Fri, 6 Apr 2001 11:01:54 +0200 (MET DST) Message-Id: <4.0.2.20010406101726.0219ae20@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 06 Apr 2001 10:55:08 +0200 To: Sasha Vainshtein From: Francois Le Faucheur Cc: "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com, mpls@UU.NET, "'diffserv@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_5988798==_.ALT" Subject: [Diffserv] RE: Diff-Serv over MPLS Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_5988798==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sasha, Section 1.4 of contains the following= text: " For a given FEC, there may be more than one LSP carrying the same OA, for example for purposes of load balancing of the OA; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) BAs of a given OA. " which applies both to E-LSPs and L-LSPs. So, I believe (i) the ordering constraint and (ii) the requirement for= L-LSPs to support all active BAs of an OA are already accurately addressed. The only question is whether the readability of the document would be= improved by some wordsmithing in section 1.2. If you feel that would help, we can slightly modify the beginning of section 1.2 into: " A single LSP can be used to support one or more OAs. Such LSPs can= support up to eight BAs of a given FEC, regardless of how many OAs these BAs span." Do you feel this would improve readability? If yes, can you confirm the above suggestion is fine? Cheers Francois At 18:15 05/04/2001 +0200, Sasha Vainshtein wrote: > >Hi, > The reordering issue has been addressed in >, > "New Terminology for Diffserv" with an explicit reference to work=20 > on MPLS Support of Differentiated Services. > Section 5 of this I-D introduces the notion of an Ordering >Aggregate (OA) as=20 > A set of Behavior Aggregates that share an ordering >constraint.=20 > The set of PHBs that are applied to this set of Behavior Aggregates > > constitutes a PHB scheduling class. > =20 > I suggest that should be updated >to=20 > allow only grouping of multiple OAs (and not BAs as it does) into > a single E-LSP. The current I-D version explicitly states > that L-LSP is established for a given (OA, FEC) class but is =20 > ambiguous when it comes to E-LSPs.=20 > > Nabil, in his message in this thread, has noticed that RFC 2597 > defines AF (y=3D1,2,3) as an OA for any fixed value of x= (1-4).=20 > The suggested modification would prohibit configurations like one >described > in the original message.=20 >______________________________________________ >With best regards, >Sasha Vainshtein >mailto: sasha@axerra.com >phone: +972-3-7659993 (office) >fax: +972-3-6487779 (office) > > >>>-----Original Message----- >>>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] >>>Sent: Thursday, April 05, 2001 3:39 PM >>>To: flefauch@cisco.com; liwwu@cisco.com >>>Cc: mpls@UU.NET >>>Subject: Diff-Serv over MPLS >>> >>> >>>hi all =20 >>> Could any of you please explain about the following >>>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. >>> >>>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) >>> >>>"A single LSP can be used to support up to eight BAs >>>of >>>a given FEC, regardless of how many OAs these BAs >>>span." >>> >>>A small doubt >>> Suppose PHBs related to a PSC have been assigned to >>>different E-LSPs (say AF11 to one LSP and AF12 to >>>another LSP)and first few (say 1-10)Packets belonging >>>to a microflow have been assigned to AF11 and later >>>packets (say 10-15) to AF12.=20 >>>Is it not possible for the packets in AF12 LSP to get >>>transferred before the packets in AF11 LSP? If that is >>>the case the ordering constraint is violated i.e >>>packets are reordered. (I think this may happen in=20 >>>the following case- if the LSPs are on different=20 >>>interfaces of a router and there may be some packets >>>which are required to be served in the AF11 while the >>>packets in AF12 may get immediately served as there >>>are >>>no packets before these which require service). >>>=20 >>>thanks >>>kk >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Get email at your own domain with Yahoo! Mail.=20 >>>http://personal.mail.yahoo.com/ >>> >=20 PLEASE NOTE NEW CONTACT DETAILS - See below _________________________________________________________________ Francois Le Faucheur =20 Development Engineer, IOS Layer 3 Services=20 Cisco Systems=20 Office Phone: +33 4 97 23 26 19 Mobile : +33 6 89 108 159 Fax: +33 4 97 23 26 26 Email: flefauch@cisco.com _________________________________________________________________ Cisco Systems Europe Domaine Green Side 400, Avenue de Roumanille B=E2timent T3 06 410 BIOT=20 SOPHIA ANTIPOLIS FRANCE _________________________________________________________________ =20 --=====================_5988798==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sasha,

Section 1.4 of <draft-ietf-mpls-diff-ext-08.txt> contains the following text:

"   For a given FEC, there may be more than one LSP carrying the same
   OA, for example for purposes of load balancing of the OA; However in
   order to respect ordering constraints, all packets of a given
   microflow, possibly spanning multiple BAs of a given Ordered
   Aggregate, MUST be transported over the same LSP. Conversely, each
   LSP MUST be capable of supporting all the (active) BAs of a given
   OA.
"

which applies both to E-LSPs and L-LSPs.

So, I believe (i) the ordering constraint and (ii) the requirement for L-LSPs to support all active BAs of an OA are already accurately addressed.


The only question is whether the readability of the document would be improved by some wordsmithing in section 1.2. If you feel that would help, we can slightly modify the beginning of section 1.2 into:
"   A single LSP can be used to support one or more OAs. Such LSPs can support up to eight BAs of a given FEC,
   regardless of how many OAs these BAs=20 span."

Do you feel this would improve readability?
If yes, can you confirm the above suggestion is fine?

Cheers

Francois




At 18:15 05/04/2001 +0200, Sasha Vainshtein wrote:
>
>Hi,
>       The reordering issue has been addressed in
><draft-ietf-diffserv-new-terms-04.txt>,
>       "New Terminology for Diffserv" with an explicit reference to work
>       on MPLS Support of Differentiated Services.
>       Section 5 of this I-D introduces the notion of an Ordering
>Aggregate (OA) as
>       <quote> A set of Behavior Aggregates that share an ordering
>constraint.
>       The set of PHBs that are applied to this set of Behavior Aggregates
>
>       constitutes a PHB scheduling class. <end of quote>
>      
>       I suggest that <draft-ietf-mpls-diff-ext-08.txt> should be updated
>to
>       allow only grouping of multiple OAs (and not BAs as it does) into
>       a single E-LSP. The current I-D version explicitly states
>       that L-LSP is established for a given (OA, FEC) class but is 
>       ambiguous when it comes to E-LSPs.
>
>       Nabil, in his message in this thread, has noticed that RFC 2597
>       defines AF<x><y> (y=3D1,2,3) as an OA for any fixed value of x (1-4).
>       The suggested modification would prohibit configurations like one
>described
>       in the original message.
>______________________________________________
>With best regards,
>Sasha Vainshtein
>mailto: sasha@axerra.com
>phone: +972-3-7659993 (office)
>fax:      +972-3-6487779 (office)
>
>
>>>-----Original Message-----
>>>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com]
>>>Sent: Thursday, April 05, 2001 3:39 PM
>>>To: flefauch@cisco.com; liwwu@cisco.com
>>>Cc: mpls@UU.NET
>>>Subject: Diff-Serv over MPLS
>>>
>>>
>>>hi all      
>>>   Could any of you please explain about the= following
>>>sentence in the draft-ietf-mpls-diff-ext-0.8.txt.
>>>
>>>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP)
>>>
>>>"A single LSP can be used to support up to eight= BAs
>>>of
>>>a given FEC, regardless of how many OAs these BAs
>>>span."
>>>
>>>A small doubt
>>>  Suppose PHBs related to a PSC have been assigned= to
>>>different E-LSPs (say AF11 to one LSP and AF12 to
>>>another LSP)and first few (say 1-10)Packets belonging
>>>to a microflow have been assigned to AF11 and later
>>>packets (say 10-15) to AF12.
>>>Is it not possible for the packets in AF12 LSP to get
>>>transferred before the packets in AF11 LSP? If that= is
>>>the case the ordering constraint is violated i.e
>>>packets are reordered. (I think this may happen in
>>>the following case- if the LSPs are on different
>>>interfaces of a router and  there may be some= packets
>>>which are required to be served in the AF11 while the
>>>packets in AF12 may get immediately served as there
>>>are
>>>no packets before these which require service).
>>>
>>>thanks
>>>kk
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Get email at your own domain with Yahoo! Mail.
>>>
>=20
PLEASE NOTE NEW CONTACT DETAILS - See= below

_________________________________________________________= ________
Francois Le Faucheur  
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97= 23 26 19
Mobile= :            &n= bsp;  +33 6 89 108 159
Fax:            =        +33 4 97 23 26 26
Email:           &nbs= p;      flefauch@cisco.com
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
B=E2timent T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________= --=====================_5988798==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 06:50:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07269 for ; Fri, 6 Apr 2001 06:50:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06816; Fri, 6 Apr 2001 04:26:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06786 for ; Fri, 6 Apr 2001 04:26:33 -0400 (EDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06273 for ; Fri, 6 Apr 2001 04:26:32 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id JAA07145 for ; Fri, 6 Apr 2001 09:12:20 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA25652 for ; Fri, 6 Apr 2001 10:20:04 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA05057 for ; Fri, 6 Apr 2001 10:25:46 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id KAA02986 for ; Fri, 6 Apr 2001 10:25:51 +0200 (MET DST) Message-ID: <003701c0be72$e1470110$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: Subject: Fw: [Diffserv] CountActTable Date: Fri, 6 Apr 2001 10:23:37 +0200 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > Speaking for my company, yes we feel it is very important to have such > counters via COPS reports. > > Because SNMP is not a very scalable way to get counters on a large number of > objects (e.g. IP interfaces which may be as numerous as tens of thousands or > more on a given box) in a reliable way. I hope I will not get flamed for > this statement! ;-) > > Plus differentiated services typically come with differentiated charging > models (and some of these billing models might be based on volume). So it is > key to get service usage (aka accounting) data in association with Diffserv > policies. And in a reliable/scalable way. > > This being said, based on the accounting framework currently defined in the > "rap" group, accounting PIBs are clearly separate from the related > "provisioning" PIB. And related objects (e.g. classifiers & meters) are > referenced via pointers. > > So it makes sense to not have counters in the Diffserv PIB. As long as there > is a "Diffserv accounting PIB" in the works (or the general one described in > the accounting framework is applicable). > > Jerome > > =========================================== > Jerome P. Moisand > Senior Product Manager > Unisphere Networks > One Executive Drive Chelmsford, MA 01824 > Tel: 978-848-0648 Fax: 978-848-0399 > mailto:jmoisand@UnisphereNetworks.com > > > > -----Original Message----- > From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr] > Sent: Thursday, April 05, 2001 4:57 AM > To: rap@ops.ietf.org; Rawlins, Diana > Cc: Iliff, Tina; Joel M. Halpern; Brian E Carpenter > Subject: Re: [Diffserv] CountActTable > > > In the framework of COPS-PR configuration, is it important to be able to > install/remove/report counters via the DiffServ PIB ? What do think people > involved with the accounting PIB ? > To my mind I hardly understand why one could not install a counter with > COPS-PR in order to monitor it by SNMP, or even to report it via COPS-PR... > I'm also interested in the reasons which made DS PIB authors remove the > CountActTable from the PIB... I guess they must have good ones ! > > Thanks > Yacine > > ----- Original Message ----- > From: "Brian E Carpenter" > To: "Iliff, Tina" > Cc: > Sent: Wednesday, April 04, 2001 9:25 PM > Subject: Re: [Diffserv] CountActTable > > > > I don't see the issue for the MIB: it does have counters and nobody is > > proposing to take them away. If you want counters in the PIB, now > > is the time to say so since there will be a new version very soon. > > The model isn't going to answer that question for you. > > > > Brian > > > > > "Iliff, Tina" wrote: > > > > > > Here are some excerpts from diffserv-model-06: > > > > > > At the lowest level considered here, are individual functional datapath > elements, each with their own configuration parameters > > > and management counters and flags. > > > > > > using a Counter element downstream of the Meter, it might also be used > to help in collecting data for out-of-band management > > > functions such as billing applications. > > > > > > I find these excerpts unclear as to determining if a PIB or MIB or both > should implement a data structure to support the > > > definition of a Counter Action. > > > > > > Tina Iliff > > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@longsys.com] > > > Sent: Wednesday, April 04, 2001 12:14 PM > > > To: diffserv@ietf.org > > > Subject: RE: [Diffserv] CountActTable > > > > > > The Count Action is a diffserv packet handling action. > Including it in a > > > configuration causes counting to be done. It sure seems that > this action > > > ought to be configurable with the PIB, just like every other > Diffserv > > > packet handling action (Meter, Mark, Drop). Otherwise, one > would have to > > > use SNMP to CONFIGURE this element in order to later use SNMP > to retreive > > > the counts. > > > > > > This Action is not itself a counter that would go in an > Accounting PIB, or > > > only in an SNMP MIB. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > > > > > >Yacine, > > > > > > > >Like I said, it is just an assumption or a guess. Someone > else will have > > > >to answer. The Accounting PIB may be a good place for a > > > >counter. However, I have not taken a look at that draft in a > while. > > > > > > > >Tina Iliff > > > >-----Original Message----- From: Yacine El Mghazli > > > > >[mailto:yacine.el_mghazli@ms.alcate > > > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: > Iliff, Tina; > > > >diffserv@ietf.org Subject: Re: [Diffserv] > CountActTable > > > > > > > > > I am just guessing here but it makes more sense to me to > only have a > > > > count > action in the MIB and not in the PIB. I do not > consider > > > > counting of packets > traversing certain datapath > functional elements a > > > > piece of policy; however, > I do consider it as part of a > network nodes > > > > management. > > > > > > > >Do you mean that counting packets is only managed using SNMP > ? > > > > > > > > > Tina Iliff > > > -----Original Message----- > From: > Yacine El > > > > Mghazli > > > > > > [mailto:yacine.el_mghazli@alcatel.fr] > > > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: > diffserv@ietf.org > > > > > Subject: [Diffserv] CountActTable > > In the lattest DS > PIB : > > > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > > Action > > > > Tables > > A general extensible framework and examples > of > > > > > parameterization > > tables for Absolute Drop, Mark > and Count > > > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action > PRC > > > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is > there no Count > > > > Action Table in the PIB ? > However there is an > CountActTable in the > > > > MIB...I feel > confused. > > Thanx > > -- Yacine El > Mghazli > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Alcatel R&I > Software and Services Strategic > Program - > > > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > > Fax +33 1 > > > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 10:18:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10006 for ; Fri, 6 Apr 2001 10:18:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11377; Fri, 6 Apr 2001 09:46:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11354 for ; Fri, 6 Apr 2001 09:46:02 -0400 (EDT) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09056 for ; Fri, 6 Apr 2001 09:46:01 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GBD0068TI7J1R@firewall.mcit.com> for diffserv@ietf.org; Fri, 6 Apr 2001 13:45:19 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBD00J01I7CWH@dgismtp02.wcomnet.com>; Fri, 06 Apr 2001 13:45:19 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBD00J7UI789L@dgismtp02.wcomnet.com>; Fri, 06 Apr 2001 13:45:08 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 06 Apr 2001 13:45:08 +0000 Content-return: allowed Date: Fri, 06 Apr 2001 13:45:05 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Joel M. Halpern'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56E2@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_rJ7LRcHIuR5UO31w7AyLLw)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_rJ7LRcHIuR5UO31w7AyLLw) Content-type: text/plain; charset=ISO-8859-1 However, it seems logical that the count action would be implicit and therefore, does not need configuration parameters within a policy set. For example, if the Accounting Timer is set, then the PEP should "turn on" its counters; otherwise, the counters are "disabled". Tina Iliff -----Original Message----- From: Joel M. Halpern [mailto:joel@longsys.com] Sent: Wednesday, April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: [Diffserv] CountActTable The Count Action is a diffserv packet handling action. Including it in a configuration causes counting to be done. It sure seems that this action ought to be configurable with the PIB, just like every other Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would have to use SNMP to CONFIGURE this element in order to later use SNMP to retreive the counts. This Action is not itself a counter that would go in an Accounting PIB, or only in an SNMP MIB. Yours, Joel M. Halpern At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: >Yacine, > >Like I said, it is just an assumption or a guess. Someone else will have >to answer. The Accounting PIB may be a good place for a >counter. However, I have not taken a look at that draft in a while. > >Tina Iliff >-----Original Message----- From: Yacine El Mghazli >[mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > I am just guessing here but it makes more sense to me to only have a > count > action in the MIB and not in the PIB. I do not consider > counting of packets > traversing certain datapath functional elements a > piece of policy; however, > I do consider it as part of a network nodes > management. > >Do you mean that counting packets is only managed using SNMP ? > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > Mghazli > > [mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > Tables > > A general extensible framework and examples of > > parameterization > > tables for Absolute Drop, Mark and Count > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > Action Table in the PIB ? > However there is an CountActTable in the > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > ---------------------------------------------------------------------- > > Alcatel R&I > Software and Services Strategic Program - > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > ---------------------------------------------------------------------- > > > > _______________________________________________ > diffserv > mailing list > diffserv@ietf.org > > http://www1.ietf.org/mailm > an/listinfo/diffserv > > Archive: > > t.h>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > list.h > tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_rJ7LRcHIuR5UO31w7AyLLw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

However, it seems logical that the = count action would be implicit and therefore, does not need = configuration parameters within a policy set.  For example, if the = Accounting Timer is set, then the PEP should "turn on" its counters; = otherwise, the counters are "disabled".

Tina Iliff


      -----Original = Message-----
      From:   Joel M. Halpern = [mailto:joel@longsys.com]=
      Sent:   Wednesday, April 04, 2001 12:14 PM
      To:     diffserv@ietf.org
      Subject:       = RE: [Diffserv] CountActTable

      The Count Action is a diffserv packet = handling action.  Including it in a
      configuration causes counting to be = done.  It sure seems that this action
      ought to be configurable with the = PIB, just like every other Diffserv
      packet handling action (Meter, Mark, = Drop).  Otherwise, one would have to
      use SNMP to CONFIGURE this element in = order to later use SNMP to retreive
      the counts.

      This Action is not itself a counter = that would go in an Accounting PIB, or
      only in an SNMP MIB.

      Yours,
      Joel M. Halpern

      At 03:13 PM 4/4/01 +0000, Iliff, Tina = wrote:

      >Yacine,
      >
      >Like I said, it is just an = assumption or a guess.  Someone else will have
      >to answer.  The Accounting = PIB may be a good place for a
      >counter.  However, I have = not taken a look at that draft in a while.
      >
      >Tina Iliff
      >-----Original Message-----  = From:   Yacine El Mghazli
      >[<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.= alcate
      >l.fr]  Sent:   = Wednesday, April 04, 2001 10:07 AM  To:     = Iliff, Tina;
      >diffserv@ietf.org  = Subject:        Re: [Diffserv] = CountActTable
      >
      > > I am just guessing here but = it makes more sense to me to only have a
      > count  > action in the = MIB and not in the PIB.  I do not consider
      > counting of  packets  = > traversing certain datapath functional elements a
      > piece of policy;  = however,  > I do consider it as part of a network nodes
      > management.
      >
      >Do you mean that counting packets = is only managed using SNMP ?
      >
      > > Tina Iliff  >  = >  > -----Original Message-----  > From: Yacine El =
      > Mghazli  >
      > [<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr]
       >   > Sent: = Wednesday, April 04, 2001 7:39 AM  > To: = diffserv@ietf.org  >
      > Subject: [Diffserv] = CountActTable  >  > In the lattest DS PIB :  = >  >
      > Quoted from the = draft-ietf-diffserv-pib-03.txt (page 5) :  > > Action =
      > Tables  > = >      A general extensible framework and = examples of  >
      > parameterization  > = >      tables for Absolute Drop, Mark and = Count
      > actions.  >  > = and page 11 :  > > 4.5.1.  DSCP Mark Action PRC  = > >
      > (...)  > > = 4.5.2.  Absolute Drop Action  >  > So why is there = no Count
      > Action Table in the PIB ?  = > However there is an CountActTable in the
      > MIB...I feel  > = confused.  >  > Thanx  >  > -- Yacine = El Mghazli  >  >
      > = ----------------------------------------------------------------------&n= bsp; >
       >   Alcatel = R&I  >   Software and Services Strategic Program = -
      > VIPeR  >   = Marcoussis, France  >   Tel  +33 1 69 63 41 = 87  >   Fax  +33 1
      > 69 63 11 69  = >   yacine.el_mghazli@ms.alcatel.fr  >  > =
      > = ----------------------------------------------------------------------&n= bsp; >
       >  >  > = _______________________________________________  > diffserv =
      > mailing list  > = diffserv@ietf.org  >
      > <http://www1.ietf.org/mailman/listinfo/diffserv>= http://www1.ietf.org/mailm
      > an/listinfo/diffserv  > =
      > Archive:  >
      > <http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillis
      > t.h>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mail
      > list.h  > tml  = >


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_rJ7LRcHIuR5UO31w7AyLLw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 11:22:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11921 for ; Fri, 6 Apr 2001 11:22:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12708; Fri, 6 Apr 2001 11:00:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12685 for ; Fri, 6 Apr 2001 11:00:28 -0400 (EDT) Received: from longsys.com ([63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11298 for ; Fri, 6 Apr 2001 11:00:28 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f36F07l03167 for ; Fri, 6 Apr 2001 15:00:07 GMT Message-Id: <4.2.2.20010406105853.00be5bc0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 06 Apr 2001 10:59:59 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] CountActTable In-Reply-To: <492EB4A3F68CD411ABE800508B69362E3F56E2@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org There are no defined implicit count actions. The point of including the actions explicitily in the MIB / Model (and presumably PIB) is that depending upon the particular usage intended by the administrator, one may want to count at different points. The Count Actions define where counting is done. Yours, Joel M. Halpern At 01:45 PM 4/6/01 +0000, Iliff, Tina wrote: >However, it seems logical that the count action would be implicit and >therefore, does not need configuration parameters within a policy >set. For example, if the Accounting Timer is set, then the PEP should >"turn on" its counters; otherwise, the counters are "disabled". > >Tina Iliff >-----Original Message----- From: Joel M. Halpern >[mailto:joel@longsys.com] Sent: Wednesday, >April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: >[Diffserv] CountActTable > >The Count Action is a diffserv packet handling action. Including it in >a configuration causes counting to be done. It sure seems that this >action ought to be configurable with the PIB, just like every other >Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would >have to use SNMP to CONFIGURE this element in order to later use SNMP to >retreive the counts. > >This Action is not itself a counter that would go in an Accounting PIB, >or only in an SNMP MIB. > >Yours, Joel M. Halpern > >At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > >Like I said, it is just an assumption or a guess. Someone > else will have >to answer. The Accounting PIB may be a good place for > a >counter. However, I have not taken a look at that draft in a > while. > >Tina Iliff >-----Original Message----- From: Yacine El > Mghazli > >[<mailto:yacine.el_mghazli@ms.a > lcatel.fr>mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, > April 04, 2001 10:07 AM To: Iliff, > Tina; >diffserv@ietf.org Subject: Re: [Diffserv] > CountActTable > > > I am just guessing here but it makes more sense to > me to only have a > count > action in the MIB and not in the PIB. I do > not consider > counting of packets > traversing certain datapath > functional elements a > piece of policy; however, > I do consider it as > part of a network nodes > management. > >Do you mean that counting > packets is only managed using SNMP ? > > > Tina Iliff > > > > -----Original Message----- > From: Yacine El > Mghazli > > > [<mailto:yacine.el_mghazli@alcatel.fr > >mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, > 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] > CountActTable > > In the lattest DS PIB : > > > Quoted from the > draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 > 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > > > > > _______________________________________________ > diffserv > > mailing list > diffserv@ietf.org > > > <http://www1.ietf.org/mail > man/listinfo/diffserv>http://www1.ietf.org/mailm > > an/listinfo/diffserv > > Archive: > > > < s>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s > > t.h> l>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > > list.h > tml > > >_______________________________________________ diffserv mailing >list diffserv@ietf.org >http://www1.ietf.org/mailma >n/listinfo/diffserv Archive: >.html>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai >llist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 13:26:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15053 for ; Fri, 6 Apr 2001 13:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14796; Fri, 6 Apr 2001 13:03:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14771 for ; Fri, 6 Apr 2001 13:03:28 -0400 (EDT) Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14525 for ; Fri, 6 Apr 2001 13:03:29 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GBD0016YRCTJR@firewall.mcit.com> for diffserv@ietf.org; Fri, 6 Apr 2001 17:02:53 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBD00F01RCK3H@dgismtp02.wcomnet.com>; Fri, 06 Apr 2001 17:02:52 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBD00AOPRCF2Y@dgismtp02.wcomnet.com>; Fri, 06 Apr 2001 17:02:39 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 06 Apr 2001 17:02:39 +0000 Content-return: allowed Date: Fri, 06 Apr 2001 17:02:36 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Joel M. Halpern'" , diffserv@ietf.org, "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F56E5@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g) Content-type: text/plain; charset=ISO-8859-1 So, in other words, you are implying that a boolean value should be added to each PIB PRC to specify whether or not to count? I see the use; however, I do not think it is applicable to the Diffserv PIB since a counter is not a specific piece of QoS information. I would recommend adding it to the Framework PIB (for example, add a boolean value to the frwkPrcSupport PRC) if it is added to a PIB at all. Tina Iliff -----Original Message----- From: Joel M. Halpern [mailto:joel@longsys.com] Sent: Friday, April 06, 2001 10:00 AM To: diffserv@ietf.org Subject: RE: [Diffserv] CountActTable There are no defined implicit count actions. The point of including the actions explicitily in the MIB / Model (and presumably PIB) is that depending upon the particular usage intended by the administrator, one may want to count at different points. The Count Actions define where counting is done. Yours, Joel M. Halpern At 01:45 PM 4/6/01 +0000, Iliff, Tina wrote: >However, it seems logical that the count action would be implicit and >therefore, does not need configuration parameters within a policy >set. For example, if the Accounting Timer is set, then the PEP should >"turn on" its counters; otherwise, the counters are "disabled". > >Tina Iliff >-----Original Message----- From: Joel M. Halpern >[mailto:joel@longsys.com] Sent: Wednesday, >April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: >[Diffserv] CountActTable > >The Count Action is a diffserv packet handling action. Including it in >a configuration causes counting to be done. It sure seems that this >action ought to be configurable with the PIB, just like every other >Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would >have to use SNMP to CONFIGURE this element in order to later use SNMP to >retreive the counts. > >This Action is not itself a counter that would go in an Accounting PIB, >or only in an SNMP MIB. > >Yours, Joel M. Halpern > >At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > >Like I said, it is just an assumption or a guess. Someone > else will have >to answer. The Accounting PIB may be a good place for > a >counter. However, I have not taken a look at that draft in a > while. > >Tina Iliff >-----Original Message----- From: Yacine El > Mghazli > >[<mailto:yacine.el_mghazli@ms.a > lcatel.fr>mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, > April 04, 2001 10:07 AM To: Iliff, > Tina; >diffserv@ietf.org Subject: Re: [Diffserv] > CountActTable > > > I am just guessing here but it makes more sense to > me to only have a > count > action in the MIB and not in the PIB. I do > not consider > counting of packets > traversing certain datapath > functional elements a > piece of policy; however, > I do consider it as > part of a network nodes > management. > >Do you mean that counting > packets is only managed using SNMP ? > > > Tina Iliff > > > > -----Original Message----- > From: Yacine El > Mghazli > > > [<mailto:yacine.el_mghazli@alcatel.fr > >mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, > 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] > CountActTable > > In the lattest DS PIB : > > > Quoted from the > draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 > 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > > > > > _______________________________________________ > diffserv > > mailing list > diffserv@ietf.org > > > <http://www1.ietf.org/mail > man/listinfo/diffserv>http://www1.ietf.org/mailm > > an/listinfo/diffserv > > Archive: > > > < s>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s > > t.h> l>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > > list.h > tml > > >_______________________________________________ diffserv mailing >list diffserv@ietf.org >http://www1.ietf.org/mailma >n/listinfo/diffserv Archive: >.html>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai >llist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

So, in other words, you are implying = that a boolean value should be added to each PIB PRC to specify whether = or not to count?  I see the use; however, I do not think it is = applicable to the Diffserv PIB since a counter is not a specific piece = of QoS information.  I would recommend adding it to the Framework = PIB (for example, add a boolean value to the frwkPrcSupport PRC) if it = is added to a PIB at all.

Tina Iliff


      -----Original = Message-----
      From:   Joel M. Halpern = [mailto:joel@longsys.com]=
      Sent:   Friday, April 06, 2001 10:00 AM
      To:     diffserv@ietf.org
      Subject:       = RE: [Diffserv] CountActTable

      There are no defined implicit count = actions.  The point of including the
      actions explicitily in the MIB / = Model (and presumably PIB) is that
      depending upon the particular usage = intended by the administrator, one may
      want to count at different = points.  The Count Actions define where counting
      is done.

      Yours,
      Joel M. Halpern

      At 01:45 PM 4/6/01 +0000, Iliff, Tina = wrote:

      >However, it seems logical that the = count action would be implicit and
      >therefore, does not need = configuration parameters within a policy
      >set.  For example, if the = Accounting Timer is set, then the PEP should
      >"turn on" its counters; = otherwise, the counters are "disabled".
      >
      >Tina Iliff
      >-----Original Message-----  = From:   Joel M. Halpern
      >[<mailto:joel@longsys.com>mailto:joel@longsys.com]  = Sent:   Wednesday,
      >April 04, 2001 12:14 PM  = To:     diffserv@ietf.org  = Subject:        RE:
      >[Diffserv] CountActTable
      >
      >The Count Action is a diffserv = packet handling action.  Including it in
      >a  configuration causes = counting to be done.  It sure seems that this
      >action ought to be configurable = with the PIB, just like every other
      >Diffserv packet handling action = (Meter, Mark, Drop).  Otherwise, one would
      >have to use SNMP to CONFIGURE = this element in order to later use SNMP to
      >retreive the counts.
      >
      >This Action is not itself a = counter that would go in an Accounting PIB,
      >or  only in an SNMP = MIB.
      >
      >Yours,  Joel M. = Halpern
      >
      >At 03:13 PM 4/4/01 +0000, Iliff, = Tina wrote:
      >
      > >Yacine,  >  = >Like I said, it is just an assumption or a guess.  Someone =
      > else will have  >to = answer.  The Accounting PIB may be a good place for
      > a >counter.  However, I = have not taken a look at that draft in a
      > while.  >  >Tina = Iliff  >-----Original Message-----  From:   = Yacine El
      > Mghazli
       >  >[<<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.a=
      > lcatel.fr>mailto:yacine.el_mghazli@ms.= alcate >l.fr]  Sent:   Wednesday,
      > April 04, 2001 10:07 AM  = To:     Iliff,
      > Tina; = >diffserv@ietf.org  = Subject:        Re: [Diffserv] =
      > CountActTable  >  = > > I am just guessing here but it makes more sense to
      > me to only have a  > = count  > action in the MIB and not in the PIB.  I do =
      > not consider > counting = of  packets  > traversing certain datapath
      > functional elements a > piece = of policy;  however,  > I do consider it as
      > part of a network nodes > = management.  >  >Do you mean that counting
      > packets is only managed using = SNMP ?  >  > > Tina Iliff  >  = >  >
      > -----Original Message-----  = > From: Yacine El  > Mghazli  > >
      > [<<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr
       > >mailto:yacine.el_mghazli@al= catel.fr]  >   > Sent: Wednesday, April 04, =
      > 2001 7:39 AM  > To: = diffserv@ietf.org  > > Subject: [Diffserv]
      > CountActTable  >  = > In the lattest DS PIB :  >  > > Quoted from the =
      > draft-ietf-diffserv-pib-03.txt = (page 5) :  > > Action >
      > Tables  > = >      A general extensible framework and = examples of  > >
      > parameterization  > = >      tables for Absolute Drop, Mark and = Count >
      > actions.  >  > = and page 11 :  > > 4.5.1.  DSCP Mark Action PRC  = > > >
      > (...)  > > = 4.5.2.  Absolute Drop Action  >  > So why is there = no Count >
      > Action Table in the PIB ?  = > However there is an CountActTable in the >
      > MIB...I feel  > = confused.  >  > Thanx  >  > -- Yacine = El Mghazli  >  > >
      > = ----------------------------------------------------------------------&n= bsp; >
       >  >   = Alcatel R&I  >   Software and Services Strategic = Program - >
      > VIPeR  >   = Marcoussis, France  >   Tel  +33 1 69 63 41 = 87  >   Fax  +33
      > 1 > 69 63 11 69  = >   yacine.el_mghazli@ms.alcatel.fr  >  > = >
      > = ----------------------------------------------------------------------&n= bsp; >
       >  >  = >  > _______________________________________________  = > diffserv >
      > mailing list  > = diffserv@ietf.org  > >
      > <<http://www1.ietf.org/mailman/listinfo/diffserv>= http://www1.ietf.org/mail
      > man/listinfo/diffserv>http://www1.ietf.org/mailm >
      > an/listinfo/diffserv  > = > Archive:  > >
      > <<http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mailli
      > s>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mailli
      > s >
      > t.h><http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mai
      > l>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mail >
       >  list.h  > = tml  >
      >
      >_______________________________________________ = diffserv mailing
      >list  diffserv@ietf.org =
      ><http://www1.ietf.org/mailman/listinfo/diffserv>= http://www1.ietf.org/mailma
      >n/listinfo/diffserv  = Archive:
      ><http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist
      >.html>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mai
      >llist.html


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 14:31:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16672 for ; Fri, 6 Apr 2001 14:31:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15654; Fri, 6 Apr 2001 14:00:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15623 for ; Fri, 6 Apr 2001 14:00:40 -0400 (EDT) Received: from longsys.com ([63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15811 for ; Fri, 6 Apr 2001 14:00:41 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f36I0IL08813 for ; Fri, 6 Apr 2001 18:00:18 GMT Message-Id: <4.2.2.20010406135912.00c08100@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 06 Apr 2001 14:00:00 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] CountActTable In-Reply-To: <492EB4A3F68CD411ABE800508B69362E3F56E5@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org No, I just think that there should be a PRC for creating a Count Action just as there is one for creating a Drop Action or a Meter Action. Yours, Joel At 05:02 PM 4/6/01 +0000, Iliff, Tina wrote: >So, in other words, you are implying that a boolean value should be added >to each PIB PRC to specify whether or not to count? I see the use; >however, I do not think it is applicable to the Diffserv PIB since a >counter is not a specific piece of QoS information. I would recommend >adding it to the Framework PIB (for example, add a boolean value to the >frwkPrcSupport PRC) if it is added to a PIB at all. > >Tina Iliff >-----Original Message----- From: Joel M. Halpern >[mailto:joel@longsys.com] Sent: Friday, April >06, 2001 10:00 AM To: diffserv@ietf.org Subject: RE: >[Diffserv] CountActTable > >There are no defined implicit count actions. The point of including >the actions explicitily in the MIB / Model (and presumably PIB) is that >depending upon the particular usage intended by the administrator, one may >want to count at different points. The Count Actions define where >counting is done. > >Yours, Joel M. Halpern > >At 01:45 PM 4/6/01 +0000, Iliff, Tina wrote: > > >However, it seems logical that the count action would be implicit > and >therefore, does not need configuration parameters within a > policy >set. For example, if the Accounting Timer is set, then the PEP > should >"turn on" its counters; otherwise, the counters are > "disabled". > >Tina Iliff >-----Original Message----- From: Joel M. > Halpern > >[<mailto:joel@longsys.com>mailto:joel@longsys. > com] Sent: Wednesday, >April 04, 2001 12:14 > PM To: diffserv@ietf.org Subject: RE: >[Diffserv] > CountActTable > >The Count Action is a diffserv packet handling > action. Including it in >a configuration causes counting to be > done. It sure seems that this >action ought to be configurable with the > PIB, just like every other >Diffserv packet handling action (Meter, Mark, > Drop). Otherwise, one would >have to use SNMP to CONFIGURE this element > in order to later use SNMP to >retreive the counts. > >This Action is > not itself a counter that would go in an Accounting PIB, >or only in an > SNMP MIB. > >Yours, Joel M. Halpern > >At 03:13 PM 4/4/01 +0000, > Iliff, Tina wrote: > > >Yacine, > >Like I said, it is just an > assumption or a guess. Someone > else will have >to answer. The > Accounting PIB may be a good place for > a >counter. However, I have not > taken a look at that draft in a > while. > >Tina Iliff >-----Original > Message----- From: Yacine El > > Mghazli > > >[<<mailto:yacine.el_mghazli@ms. > alcatel.fr>mailto:yacine.el_mghazli@ms.a > > lcatel.fr>mailto:yacine.el_mghazli@ms. > alcate >l.fr] Sent: Wednesday, > April 04, 2001 10:07 > AM To: Iliff, > Tina; >diffserv@ietf.org Subject: Re: > [Diffserv] > CountActTable > > > I am just guessing here but it makes > more sense to > me to only have a > count > action in the MIB and not > in the PIB. I do > not consider > counting of packets > traversing > certain datapath > functional elements a > piece of policy; however, > > I do consider it as > part of a network nodes > management. > >Do you > mean that counting > packets is only managed using SNMP ? > > > Tina > Iliff > > > > -----Original Message----- > From: Yacine El > > Mghazli > > > > [<<mailto:yacine.el_mghazli@alcatel.f > r>mailto:yacine.el_mghazli@alcatel.fr > > >mailto:yacine.el_mghazli@alcatel > .fr] > > Sent: Wednesday, April 04, > 2001 7:39 AM > To: > diffserv@ietf.org > > Subject: [Diffserv] > CountActTable > > In the > lattest DS PIB : > > > Quoted from the > draft-ietf-diffserv-pib-03.txt > (page 5) : > > Action > > Tables > > A general extensible > framework and examples of > > > parameterization > > tables for > Absolute Drop, Mark and Count > > actions. > > and page 11 : > > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop > Action > > So why is there no Count > > Action Table in the PIB ? > > However there is an CountActTable in the > > MIB...I feel > > confused. > > Thanx > > -- Yacine El Mghazli > > > > > ---------------------------------------------------------------------- > > > > Alcatel R&I > Software and Services Strategic Program - > > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 > > 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > > diffserv > > mailing list > diffserv@ietf.org > > > > <<http://www1.ietf.org/mai > lman/listinfo/diffserv>http://www1.ietf.org/mail > > man/listinfo/diffserv>http://www1.ietf.org/mai > lm > > an/listinfo/diffserv > > Archive: > > > > << i>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > > > s> i>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > > s > > > t.h>< i>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai > > l> > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > > > list.h > > tml > > >_______________________________________________ diffserv > mailing >list > diffserv@ietf.org ><http:/ > /www1.ietf.org/mailman/listinfo/diffserv>http://www1.ietf.org/mailma >n/li > stinfo/diffserv > Archive: >< ent/maillist>http://www2.ietf.org/mail-archive/working-groups/diffserv/cur > rent/maillist >.html> fserv/current/mai>http://www2.ietf.org/mail-archive/working-groups/diffser > v/current/mai >llist.html > >_______________________________________________ diffserv mailing >list diffserv@ietf.org >http://www1.ietf.org/mailma >n/listinfo/diffserv Archive: >.html>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai >llist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 15:01:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17505 for ; Fri, 6 Apr 2001 15:01:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15977; Fri, 6 Apr 2001 14:26:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15871 for ; Fri, 6 Apr 2001 14:26:33 -0400 (EDT) Received: from hypnos.cps.intel.com ([192.198.165.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16538 for ; Fri, 6 Apr 2001 14:26:29 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id SAA04199; Fri, 6 Apr 2001 18:25:19 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 06 Apr 2001 18:25:18 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2FLLY8V6>; Fri, 6 Apr 2001 11:25:16 -0700 Message-ID: From: "Kulkarni, Amol" To: "'Iliff, Tina'" , "'Joel M. Halpern'" , diffserv@ietf.org, "'rap@ops.ietf.org'" Subject: RE: [Diffserv] CountActTable Date: Fri, 6 Apr 2001 11:25:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BEC6.EC934390" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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_01C0BEC6.EC934390 Content-Type: text/plain; charset="iso-8859-1" I'd like to comment that the Accounting Framework does allow one to configure accounting. It is a general framework, which can be applied to any PIB with some small additions. We plan to come up with a draft for Diffserv Accounting based on this framework. Although we haven't started working on it yet, it'll probably be similar to the accounting info in the MIB. In the future PIBs, I would expect accounting PRCs to be included within the PIBs. Here's a link to the accounting framework PIB: http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-01.txt -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Friday, April 06, 2001 10:03 AM To: 'Joel M. Halpern'; diffserv@ietf.org; 'rap@ops.ietf.org' Subject: RE: [Diffserv] CountActTable So, in other words, you are implying that a boolean value should be added to each PIB PRC to specify whether or not to count? I see the use; however, I do not think it is applicable to the Diffserv PIB since a counter is not a specific piece of QoS information. I would recommend adding it to the Framework PIB (for example, add a boolean value to the frwkPrcSupport PRC) if it is added to a PIB at all. Tina Iliff BM__MailData-----Original Message----- From: Joel M. Halpern [ mailto:joel@longsys.com ] Sent: Friday, April 06, 2001 10:00 AM To: diffserv@ietf.org Subject: RE: [Diffserv] CountActTable There are no defined implicit count actions. The point of including the actions explicitily in the MIB / Model (and presumably PIB) is that depending upon the particular usage intended by the administrator, one may want to count at different points. The Count Actions define where counting is done. Yours, Joel M. Halpern At 01:45 PM 4/6/01 +0000, Iliff, Tina wrote: >However, it seems logical that the count action would be implicit and >therefore, does not need configuration parameters within a policy >set. For example, if the Accounting Timer is set, then the PEP should >"turn on" its counters; otherwise, the counters are "disabled". > >Tina Iliff >-----Original Message----- From: Joel M. Halpern >[< mailto:joel@longsys.com > mailto:joel@longsys.com ] Sent: Wednesday, >April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: >[Diffserv] CountActTable > >The Count Action is a diffserv packet handling action. Including it in >a configuration causes counting to be done. It sure seems that this >action ought to be configurable with the PIB, just like every other >Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would >have to use SNMP to CONFIGURE this element in order to later use SNMP to >retreive the counts. > >This Action is not itself a counter that would go in an Accounting PIB, >or only in an SNMP MIB. > >Yours, Joel M. Halpern > >At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > >Like I said, it is just an assumption or a guess. Someone > else will have >to answer. The Accounting PIB may be a good place for > a >counter. However, I have not taken a look at that draft in a > while. > >Tina Iliff >-----Original Message----- From: Yacine El > Mghazli > >[<< mailto:yacine.el_mghazli@ms.alcatel.fr > mailto:yacine.el_mghazli@ms.a > lcatel.fr> mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, > April 04, 2001 10:07 AM To: Iliff, > Tina; >diffserv@ietf.org Subject: Re: [Diffserv] > CountActTable > > > I am just guessing here but it makes more sense to > me to only have a > count > action in the MIB and not in the PIB. I do > not consider > counting of packets > traversing certain datapath > functional elements a > piece of policy; however, > I do consider it as > part of a network nodes > management. > >Do you mean that counting > packets is only managed using SNMP ? > > > Tina Iliff > > > > -----Original Message----- > From: Yacine El > Mghazli > > > [<< mailto:yacine.el_mghazli@alcatel.fr > mailto:yacine.el_mghazli@alcatel.fr > > mailto:yacine.el_mghazli@alcatel.fr ] > > Sent: Wednesday, April 04, > 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] > CountActTable > > In the lattest DS PIB : > > > Quoted from the > draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 > 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > > > > > _______________________________________________ > diffserv > > mailing list > diffserv@ietf.org > > > << http://www1.ietf.org/mailman/listinfo/diffserv > http://www1.ietf.org/mail > man/listinfo/diffserv> http://www1.ietf.org/mailm > > an/listinfo/diffserv > > Archive: > > > << http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s > > t.h>< http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai > l> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > > list.h > tml > > >_______________________________________________ diffserv mailing >list diffserv@ietf.org >< http://www1.ietf.org/mailman/listinfo/diffserv > http://www1.ietf.org/mailma >n/listinfo/diffserv Archive: >< http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist >.html> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai >llist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C0BEC6.EC934390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable
I'd=20 like to comment that the Accounting Framework does allow one to = configure=20 accounting. It is a general framework, which can be applied to any PIB = with some=20 small additions.
 
We=20 plan to come up with a draft for Diffserv Accounting based on this = framework. Although we haven't started working on it yet, it'll = probably be=20 similar to the accounting info in the MIB.
 
In the=20 future PIBs, I would expect accounting PRCs to be included within the=20 PIBs.
 
Here's=20 a link to the accounting framework PIB: http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-01= .txt
-----Original Message-----
From: Iliff, Tina=20 [mailto:Tina.Iliff@WCOM.Com]
Sent: Friday, April 06, 2001 = 10:03=20 AM
To: 'Joel M. Halpern'; diffserv@ietf.org;=20 'rap@ops.ietf.org'
Subject: RE: [Diffserv]=20 CountActTable

So, in other words, you are implying = that a boolean=20 value should be added to each PIB PRC to specify whether or not to=20 count?  I see the use; however, I do not think it is applicable = to the=20 Diffserv PIB since a counter is not a specific piece of QoS = information. =20 I would recommend adding it to the Framework PIB (for example, add a = boolean=20 value to the frwkPrcSupport PRC) if it is added to a PIB at = all.

Tina Iliff =


      -----Original=20 Message-----
      From:  =20 Joel M. Halpern [mailto:joel@longsys.com]= =20
      Sent:   = Friday, April 06, 2001 10:00 AM       =
      To:           = diffserv@ietf.org
      Subject:        = RE: [Diffserv] CountActTable

      There are no defined implicit = count=20 actions.  The point of including the
      actions explicitily in the MIB / Model (and presumably = PIB) is that=20
      depending upon the = particular usage=20 intended by the administrator, one may
      want to count at different points.  The Count = Actions define=20 where counting
      is = done.

      Yours,
      Joel=20 M. Halpern

      At 01:45 PM 4/6/01 +0000, Iliff, = Tina=20 wrote:

      >However, it seems logical that = the count=20 action would be implicit and
      >therefore, does not need configuration parameters = within a=20 policy
      >set.  For = example, if=20 the Accounting Timer is set, then the PEP should
      >"turn on" its counters; otherwise, the = counters are=20 "disabled".
      > =
      >Tina Iliff
      >-----Original Message-----  From:   = Joel M.=20 Halpern
      >[<mailto:joel@longsys.com>mailto:joel@longsys.com] =20 Sent:   Wednesday,
      >April=20 04, 2001 12:14 PM  To:    =20 diffserv@ietf.org  = Subject:       =20 RE:
      >[Diffserv] = CountActTable=20
      >
      >The Count Action is a diffserv packet handling = action. =20 Including it in
      >a =20 configuration causes counting to be done.  It sure seems = that this=20
      >action ought to be = configurable=20 with the PIB, just like every other
      >Diffserv packet handling action (Meter, Mark, = Drop). =20 Otherwise, one would
      >have to use=20 SNMP to CONFIGURE this element in order to later use SNMP to=20
      >retreive the = counts.=20
      >
      >This Action is not itself a counter that would go in = an=20 Accounting PIB,
      >or  only in an=20 SNMP MIB.
      > =
      >Yours,  Joel M. Halpern =
      >
      >At 03:13 PM=20 4/4/01 +0000, Iliff, Tina wrote:
      >
      > = >Yacine, =20 >  >Like I said, it is just an assumption or a = guess. =20 Someone
      > else will = have =20 >to answer.  The Accounting PIB may be a good place for=20
      > a >counter.  = However, I=20 have not taken a look at that draft in a
      > while.  >  >Tina Iliff  = >-----Original=20 Message-----  From:   Yacine El
      > Mghazli
       > =20 >[<<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.a= =20
      > lcatel.fr>mailto:yacine.el_mghazli@ms.= alcate=20 >l.fr]  Sent:   Wednesday,
      > April 04, 2001 10:07 AM  = To:    =20 Iliff,
      > Tina;=20 >diffserv@ietf.org =20 Subject:        Re: [Diffserv] =
      > CountActTable  = > =20 > > I am just guessing here but it makes more sense to=20
      > me to only have = a  >=20 count  > action in the MIB and not in the PIB.  I do =
      > not consider > = counting=20 of  packets  > traversing certain datapath =
      > functional elements a > piece of = policy; =20 however,  > I do consider it as
      > part of a network nodes > management.  = > =20 >Do you mean that counting
      >=20 packets is only managed using SNMP ?  >  > > = Tina=20 Iliff  >  >  >
      > -----Original Message-----  > From: Yacine = El =20 > Mghazli  > >
      >=20 [<<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr=20
       > >mailto:yacine.el_mghazli@al= catel.fr] =20 >   > Sent: Wednesday, April 04,
      > 2001 7:39 AM  > To: = diffserv@ietf.org =20 > > Subject: [Diffserv]
      >=20 CountActTable  >  > In the lattest DS PIB :  = >  > > Quoted from the
      > draft-ietf-diffserv-pib-03.txt (page 5) :  = > >=20 Action >
      > = Tables  >=20 >      A general extensible framework = and=20 examples of  > >
      >=20 parameterization  > >      = tables for=20 Absolute Drop, Mark and Count >
      >=20 actions.  >  > and page 11 :  > > = 4.5.1. =20 DSCP Mark Action PRC  > > >
      > (...)  > > 4.5.2.  Absolute Drop = Action =20 >  > So why is there no Count >
      > Action Table in the PIB ?  > However there = is an=20 CountActTable in the >
      > MIB...I=20 feel  > confused.  >  > Thanx  = > =20 > -- Yacine El Mghazli  >  > > =
      >=20 = ----------------------------------------------------------------------&n= bsp;=20 >
       >  = >  =20 Alcatel R&I  >   Software and Services = Strategic=20 Program - >
      > = VIPeR =20 >   Marcoussis, France  >   = Tel  +33 1=20 69 63 41 87  >   Fax  +33
      > 1 > 69 63 11 69  = >  =20 yacine.el_mghazli@ms.alcatel.fr  >  > >=20
      >=20 = ----------------------------------------------------------------------&n= bsp;=20 >
       >  = > =20 >  > = _______________________________________________  >=20 diffserv >
      > mailing = list =20 > diffserv@ietf.org  > >
      > <<http://www1.ietf.org/mailman/listinfo/diffserv>http://www1.ietf.org/mail
      > man/listinfo/diffserv>http://www1.ietf.org/mailm > =
      > an/listinfo/diffserv  > > = Archive: =20 > >
      > <<http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mailli=20
      > s>http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mailli=20
      > s > =
      > t.h><http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mai=20
      > l>http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mail=20 >
       >  = list.h  >=20 tml  >
      > =
      >_______________________________________________  = diffserv=20 mailing
      >list =20 diffserv@ietf.org
      ><http://www1.ietf.org/mailman/listinfo/diffserv>http://www1.ietf.org/mailma
      >n/listinfo/diffserv  Archive:
      ><http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/maillist=20
      >.html>http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mai=20
      >llist.html =


      _______________________________________________ =
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv=20
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/maillist.html=20

------_=_NextPart_001_01C0BEC6.EC934390-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 6 17:00:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20088 for ; Fri, 6 Apr 2001 17:00:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18281; Fri, 6 Apr 2001 16:38:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18254 for ; Fri, 6 Apr 2001 16:38:08 -0400 (EDT) Received: from zcars04f.ca.nortel.com ([47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19805 for ; Fri, 6 Apr 2001 16:38:06 -0400 (EDT) Message-Id: <200104062038.QAA19805@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 6 Apr 2001 16:11:46 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6KGX91; Fri, 6 Apr 2001 16:11:44 -0400 Received: from tweedy (dhcp223-130.engeast.baynetworks.com [192.32.223.130]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWR540; Fri, 6 Apr 2001 16:11:44 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Apr 2001 16:10:58 -0400 To: Yacine El Mghazli X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: Fw: [Diffserv] CountActTable Cc: diffserv , "Kwok-Ho Chan" In-Reply-To: <003701c0be72$e1470110$c2f809bc@ms.alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Yacine: Yes, currently work is under way for a QoS Accounting Policy PIB (not exact or finalized name, so please don't comment on the name :)). separate from the Accounting Framework PIB. This will include capability of where statistics can be gathered (different device put counters in different ASICs of different QoS datapaths), where statistics need to be gathered (as determined by the PDP), and what statistics need to be gathered. Please note the statistics discussed here are relavant to a specific policy instance at the PEP. Please also note this PIB does not intended to indicate how the statistics will be used. Billing and other applications are considered application layers above the PDP that does not need to be indicated in the information exchanged between the PDP and PEP. Hope this clear some of air up. -- Kwok Ho Chan, Nortel Networks -- At 10:23 AM 4/6/01 +0200, Yacine El Mghazli wrote: >> >> Speaking for my company, yes we feel it is very important to have such >> counters via COPS reports. >> >> Because SNMP is not a very scalable way to get counters on a large number >of >> objects (e.g. IP interfaces which may be as numerous as tens of thousands >or >> more on a given box) in a reliable way. I hope I will not get flamed for >> this statement! ;-) >> >> Plus differentiated services typically come with differentiated charging >> models (and some of these billing models might be based on volume). So it >is >> key to get service usage (aka accounting) data in association with >Diffserv >> policies. And in a reliable/scalable way. >> >> This being said, based on the accounting framework currently defined in >the >> "rap" group, accounting PIBs are clearly separate from the related >> "provisioning" PIB. And related objects (e.g. classifiers & meters) are >> referenced via pointers. >> >> So it makes sense to not have counters in the Diffserv PIB. As long as >there >> is a "Diffserv accounting PIB" in the works (or the general one described >in >> the accounting framework is applicable). >> >> Jerome >> >> =========================================== >> Jerome P. Moisand >> Senior Product Manager >> Unisphere Networks >> One Executive Drive Chelmsford, MA 01824 >> Tel: 978-848-0648 Fax: 978-848-0399 >> mailto:jmoisand@UnisphereNetworks.com >> >> >> >> -----Original Message----- >> From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr] >> Sent: Thursday, April 05, 2001 4:57 AM >> To: rap@ops.ietf.org; Rawlins, Diana >> Cc: Iliff, Tina; Joel M. Halpern; Brian E Carpenter >> Subject: Re: [Diffserv] CountActTable >> >> >> In the framework of COPS-PR configuration, is it important to be able to >> install/remove/report counters via the DiffServ PIB ? What do think people >> involved with the accounting PIB ? >> To my mind I hardly understand why one could not install a counter with >> COPS-PR in order to monitor it by SNMP, or even to report it via >COPS-PR... >> I'm also interested in the reasons which made DS PIB authors remove the >> CountActTable from the PIB... I guess they must have good ones ! >> >> Thanks >> Yacine >> >> ----- Original Message ----- >> From: "Brian E Carpenter" >> To: "Iliff, Tina" >> Cc: >> Sent: Wednesday, April 04, 2001 9:25 PM >> Subject: Re: [Diffserv] CountActTable >> >> >> > I don't see the issue for the MIB: it does have counters and nobody is >> > proposing to take them away. If you want counters in the PIB, now >> > is the time to say so since there will be a new version very soon. >> > The model isn't going to answer that question for you. >> > >> > Brian >> > >> > > "Iliff, Tina" wrote: >> > > >> > > Here are some excerpts from diffserv-model-06: >> > > >> > > At the lowest level considered here, are individual functional >datapath >> elements, each with their own configuration parameters >> > > and management counters and flags. >> > > >> > > using a Counter element downstream of the Meter, it might also be used >> to help in collecting data for out-of-band management >> > > functions such as billing applications. >> > > >> > > I find these excerpts unclear as to determining if a PIB or MIB or >both >> should implement a data structure to support the >> > > definition of a Counter Action. >> > > >> > > Tina Iliff >> > > >> > > -----Original Message----- >> > > From: Joel M. Halpern [mailto:joel@longsys.com] >> > > Sent: Wednesday, April 04, 2001 12:14 PM >> > > To: diffserv@ietf.org >> > > Subject: RE: [Diffserv] CountActTable >> > > >> > > The Count Action is a diffserv packet handling action. >> Including it in a >> > > configuration causes counting to be done. It sure seems >that >> this action >> > > ought to be configurable with the PIB, just like every other >> Diffserv >> > > packet handling action (Meter, Mark, Drop). Otherwise, one >> would have to >> > > use SNMP to CONFIGURE this element in order to later use >SNMP >> to retreive >> > > the counts. >> > > >> > > This Action is not itself a counter that would go in an >> Accounting PIB, or >> > > only in an SNMP MIB. >> > > >> > > Yours, >> > > Joel M. Halpern >> > > >> > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: >> > > >> > > >Yacine, >> > > > >> > > >Like I said, it is just an assumption or a guess. Someone >> else will have >> > > >to answer. The Accounting PIB may be a good place for a >> > > >counter. However, I have not taken a look at that draft in >a >> while. >> > > > >> > > >Tina Iliff >> > > >-----Original Message----- From: Yacine El Mghazli >> > > >> >>[mailto:yacine.el_mghazli@ms.alcate >> > > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: >> Iliff, Tina; >> > > >diffserv@ietf.org Subject: Re: [Diffserv] >> CountActTable >> > > > >> > > > > I am just guessing here but it makes more sense to me to >> only have a >> > > > count > action in the MIB and not in the PIB. I do not >> consider >> > > > counting of packets > traversing certain datapath >> functional elements a >> > > > piece of policy; however, > I do consider it as part of >a >> network nodes >> > > > management. >> > > > >> > > >Do you mean that counting packets is only managed using >SNMP >> ? >> > > > >> > > > > Tina Iliff > > > -----Original Message----- > From: >> Yacine El >> > > > Mghazli > >> > > > >> [mailto:yacine.el_mghazli@alcatel.fr] >> > > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: >> diffserv@ietf.org > >> > > > Subject: [Diffserv] CountActTable > > In the lattest DS >> PIB : > > >> > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : >> >> > Action >> > > > Tables > > A general extensible framework and >examples >> of > >> > > > parameterization > > tables for Absolute Drop, Mark >> and Count >> > > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action >> PRC > > >> > > > (...) > > 4.5.2. Absolute Drop Action > > So why is >> there no Count >> > > > Action Table in the PIB ? > However there is an >> CountActTable in the >> > > > MIB...I feel > confused. > > Thanx > > -- Yacine El >> Mghazli > > >> > > >> >> >> >> >> >> >> > > ---------------------------------------------------------------------- >> > >> > > > Alcatel R&I > Software and Services Strategic >> Program - >> > > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 >> >> Fax +33 1 >> > > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > >> > > >> >> >> >> >> >> >> > > ---------------------------------------------------------------------- >> > >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > http://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: >> >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h >> tml >> > >> > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 9 05:20:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01917 for ; Mon, 9 Apr 2001 05:20:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18626; Mon, 9 Apr 2001 04:41:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18603 for ; Mon, 9 Apr 2001 04:41:07 -0400 (EDT) Received: from anti_vir1.rad.co.il ([192.116.244.108]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01739 for ; Mon, 9 Apr 2001 04:41:04 -0400 (EDT) Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id KAA07627 for ; Mon, 9 Apr 2001 10:39:08 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id KAA07614; Mon, 9 Apr 2001 10:39:06 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Mon, 9 Apr 2001 10:43:36 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 11:40:22 +0200 Message-ID: From: Sasha Vainshtein To: "'Francois Le Faucheur'" , Sasha Vainshtein Cc: "'N S S Kishore Kankipati'" , liwwu@cisco.com, mpls@UU.NET, "'diffserv@ietf.org'" Subject: RE: [Diffserv] RE: Diff-Serv over MPLS Date: Mon, 9 Apr 2001 11:40:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by anti_vir1.rad.co.il id KAA07627 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18604 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id EAA18626 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA01917 Francois, The modification you suggest indeed improves readability of the document. However: 1. I am not sure that people really expect MUST/MUST NOT clauses to appear in the _Introduction_ part of an RFC/I-D as it happens with such clauses in Sections 1.4 and 1.6. Of course, this is my personal opinion only. 2. Just to be on the safe side, I would also add an _explicit_ pointer to Section 1.4 (or whatever number it would be if you decide to move it out of the Intro part) to Section 1.2, e.g.: "Section 1.4. describes overall operation of both E-LSPs and L-LSPs. Detailed operations of E-LSPs are specified in section 3." Hopefully these notes will be helpful and not just disturbing. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) -----Original Message----- From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Friday, April 06, 2001 10:55 AM To: Sasha Vainshtein Cc: 'N S S Kishore Kankipati'; flefauch@cisco.com; liwwu@cisco.com; mpls@UU.NET; 'diffserv@ietf.org' Subject: [Diffserv] RE: Diff-Serv over MPLS Sasha, Section 1.4 of contains the following text: " For a given FEC, there may be more than one LSP carrying the same OA, for example for purposes of load balancing of the OA; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) BAs of a given OA. " which applies both to E-LSPs and L-LSPs. So, I believe (i) the ordering constraint and (ii) the requirement for L-LSPs to support all active BAs of an OA are already accurately addressed. The only question is whether the readability of the document would be improved by some wordsmithing in section 1.2. If you feel that would help, we can slightly modify the beginning of section 1.2 into: " A single LSP can be used to support one or more OAs. Such LSPs can support up to eight BAs of a given FEC, regardless of how many OAs these BAs span." Do you feel this would improve readability? If yes, can you confirm the above suggestion is fine? Cheers Francois At 18:15 05/04/2001 +0200, Sasha Vainshtein wrote: > >Hi, > The reordering issue has been addressed in >, > "New Terminology for Diffserv" with an explicit reference to work > on MPLS Support of Differentiated Services. > Section 5 of this I-D introduces the notion of an Ordering >Aggregate (OA) as > A set of Behavior Aggregates that share an ordering >constraint. > The set of PHBs that are applied to this set of Behavior Aggregates > > constitutes a PHB scheduling class. > > I suggest that should be updated >to > allow only grouping of multiple OAs (and not BAs as it does) into > a single E-LSP. The current I-D version explicitly states > that L-LSP is established for a given (OA, FEC) class but is > ambiguous when it comes to E-LSPs. > > Nabil, in his message in this thread, has noticed that RFC 2597 > defines AF (y=1,2,3) as an OA for any fixed value of x (1-4). > The suggested modification would prohibit configurations like one >described > in the original message. >______________________________________________ >With best regards, >Sasha Vainshtein >mailto: sasha@axerra.com >phone: +972-3-7659993 (office) >fax: +972-3-6487779 (office) > > >>>-----Original Message----- >>>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] >>>Sent: Thursday, April 05, 2001 3:39 PM >>>To: flefauch@cisco.com; liwwu@cisco.com >>>Cc: mpls@UU.NET >>>Subject: Diff-Serv over MPLS >>> >>> >>>hi all >>> Could any of you please explain about the following >>>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. >>> >>>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) >>> >>>"A single LSP can be used to support up to eight BAs >>>of >>>a given FEC, regardless of how many OAs these BAs >>>span." >>> >>>A small doubt >>> Suppose PHBs related to a PSC have been assigned to >>>different E-LSPs (say AF11 to one LSP and AF12 to >>>another LSP)and first few (say 1-10)Packets belonging >>>to a microflow have been assigned to AF11 and later >>>packets (say 10-15) to AF12. >>>Is it not possible for the packets in AF12 LSP to get >>>transferred before the packets in AF11 LSP? If that is >>>the case the ordering constraint is violated i.e >>>packets are reordered. (I think this may happen in >>>the following case- if the LSPs are on different >>>interfaces of a router and there may be some packets >>>which are required to be served in the AF11 while the >>>packets in AF12 may get immediately served as there >>>are >>>no packets before these which require service). >>> >>>thanks >>>kk >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Get email at your own domain with Yahoo! Mail. >>>http://personal.mail.yahoo.com/ >>> > PLEASE NOTE NEW CONTACT DETAILS - See below _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 97 23 26 19 Mobile : +33 6 89 108 159 Fax: +33 4 97 23 26 26 Email: flefauch@cisco.com _________________________________________________________________ Cisco Systems Europe Domaine Green Side 400, Avenue de Roumanille B鈚iment T3 06 410 BIOT SOPHIA ANTIPOLIS FRANCE _________________________________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 9 16:28:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16095 for ; Mon, 9 Apr 2001 16:28:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00239; Mon, 9 Apr 2001 16:06:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00209 for ; Mon, 9 Apr 2001 16:06:41 -0400 (EDT) Received: from workhorse.fictitious.org ([209.66.129.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15763 for ; Mon, 9 Apr 2001 16:06:39 -0400 (EDT) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA04008; Mon, 9 Apr 2001 16:06:33 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104092006.QAA04008@workhorse.fictitious.org> To: Wil.Walkoe@mail.sprint.com cc: diffserv@ietf.org, mpls@UU.NET Reply-To: curtis@avici.com In-reply-to: Your message of "Sun, 08 Apr 2001 18:47:05 CDT." Date: Mon, 09 Apr 2001 16:06:33 -0400 From: Curtis Villamizar Subject: [Diffserv] Re: EndToEndQos.doc Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In message , Wil.Walkoe@mail.sprint.c om writes: > > --openmail-part-238944ed-00000001 > Content-Type: text/plain; charset=US-ASCII > Content-Disposition: inline > ;Creation-Date="Sun, 8 Apr 2001 18:47:03 -0500" > Content-Transfer-Encoding: 7bit > > Dear people, > > The attached document is a working draft from the Broadband Content > Delivery Forum's Infrastructure Working Group, addressing quality of > service in end-to-end data delivery. It addresses QoS from a > perspective that takes account of the many different intermediaries > that play a role in data delivery and contribute to end-to-end delay, > throughput, etc. > > I would be interested in your comments on this material, both on the > content itself (errors, omissions, material from your standards work > that should be addressed) and on where this topic could most > effectively be addressed in the IETF. > > We will be editing this draft at the BCD Forum meeting April 25 - 27 in > Las Vegas, and it would be very helpful to be able to include your > ideas in the process. > > Sincerely, > Wil Walkoe > Vice-Chair, BCD Forum Infrastructure Working Group Documents should not be sent to IETF mailing list in proprietary formats. MS-Word is not a open standard. Curtis _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 9 17:25:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17301 for ; Mon, 9 Apr 2001 17:25:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00977; Mon, 9 Apr 2001 16:58:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05053 for ; Sun, 8 Apr 2001 19:47:10 -0400 (EDT) Received: from kcmgwp01.corp.sprint.com ([208.18.122.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13052 for ; Sun, 8 Apr 2001 19:47:06 -0400 (EDT) Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f38Nl7422089; Sun, 8 Apr 2001 18:47:07 -0500 (CDT) Received: from kcopmp06.corp.sprint.com (KCOPMP06.corp.sprint.com [10.74.0.81]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f38Nl6s13735; Sun, 8 Apr 2001 18:47:06 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp06.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id SAA15517; Sun, 8 Apr 2001 18:47:06 -0500 (CDT) From: Wil.Walkoe@mail.sprint.com X-OpenMail-Hops: 1 Date: Sun, 8 Apr 2001 18:47:05 -0500 Message-Id: MIME-Version: 1.0 TO: diffserv@ietf.org, mpls@uu.net Content-Type: multipart/mixed; boundary="openmail-part-238944ed-00000001" Subject: [Diffserv] EndToEndQos.doc Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --openmail-part-238944ed-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Sun, 8 Apr 2001 18:47:03 -0500" Content-Transfer-Encoding: 7bit Dear people, The attached document is a working draft from the Broadband Content Delivery Forum's Infrastructure Working Group, addressing quality of service in end-to-end data delivery. It addresses QoS from a perspective that takes account of the many different intermediaries that play a role in data delivery and contribute to end-to-end delay, throughput, etc. I would be interested in your comments on this material, both on the content itself (errors, omissions, material from your standards work that should be addressed) and on where this topic could most effectively be addressed in the IETF. We will be editing this draft at the BCD Forum meeting April 25 - 27 in Las Vegas, and it would be very helpful to be able to include your ideas in the process. Sincerely, Wil Walkoe Vice-Chair, BCD Forum Infrastructure Working Group --openmail-part-238944ed-00000001 Content-Type: application/msword Content-Disposition: attachment; filename="EndToEndQos.doc" ;Creation-Date="Sun, 8 Apr 2001 18:47:05 -0500" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAwEAAAAA AAAAEAAABQEAAAEAAAD+////AAAAAAABAAABAQAAAgEAAP////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA 3oUAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAAAAAJBBYA7/UAADd8AAA3fAAAfWsAAJUA AABLAAAAAAAAAAAAAAAAAAAAgBUAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAFQDAAAAAAAAVAMAAFQDAAAKAAAAXgMAAAwAAACmGgAA AAAAAKYaAAAAAAAAphoAACQAAAAAAAAAAAAAAMoaAAAAAAAA9EgAAAAAAAD0SAAAAAAAAPRI AABQAAAAREkAADwAAACASQAArAAAAMoaAAAAAAAAeeQAAK4BAAA4SgAAAAAAADhKAAAAAAAA OEoAAAAAAAA4SgAAAAAAADhKAAAAAAAAs8QAAAAAAACzxAAAAAAAALPEAAAAAAAA+OMAAAIA AAD64wAAAAAAAPrjAAAAAAAA+uMAAAAAAAD64wAAAAAAAPrjAAAAAAAA+uMAACQAAAAn5gAA IAIAAEfoAACwAAAAHuQAABUAAAAAAAAAAAAAAAAAAAAAAAAAphoAAAAAAACzxAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAVuQAAngsAALPEAAAAAAAAs8QAAAAAAACzxAAAAAAAAB7kAAAAAAAA +8oAAAAAAABqAwAAAAAAAGoDAAAAAAAAOEoAAAAAAAAAAAAAAAAAADhKAADdbgAAM+QAABYA AAD7ygAAAAAAAPvKAAAAAAAA+8oAAAAAAACzxAAARgAAAGoDAADGEAAAOEoAAAAAAACmGgAA AAAAADhKAAAAAAAA+OMAAAAAAAAAAAAAAAAAAPvKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs8QAAAAAAAD44wAAAAAAAPvKAAAeBgAA +8oAAAAAAAAZ0QAA/gAAAJfgAAAvAgAAMBQAAHYGAACmGgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzuMAAAAAAAA4SgAA AAAAACxKAAAMAAAAEOq1KKq/wAHKGgAAKi4AAPRIAAAAAAAA+cQAAJoAAADG4gAAGAAAAAAA AAAAAAAA3OMAABwAAABJ5AAAMAAAAHnkAAAAAAAA3uIAAPAAAAD36AAAAAAAAJPFAABoBQAA 9+gAAAAAAADO4wAADgAAAPvKAAAAAAAAyhoAAAAAAADKGgAAAAAAAGoDAAAAAAAAagMAAAAA AABqAwAAAAAAAGoDAAAAAAAAAgDZAAAAQkNEIEZvcnVtIEluZnJhc3RydWN0dXJlIFdvcmtp bmcgR3JvdXANRFJBRlQgUmVxdWlyZW1lbnRzIGZvciB0aGUgRW5kIHRvIEVuZCBNYW5hZ2Vt ZW50IG9mIE5ldHdvcmsgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpDUJDRCBGb3J1bSBDb250 cmlidXRvcnM6IFNpbW9uIEJyeWRlbiwgR2FyeSBEaXNoZXIsIE1pY2hlbCBGaXNoZXIsIERh bmllbCBUZWljaG1hbiwgV2lsIFdhbGtvZSwgJiBTdGV2ZSBXZXN0DVByb2JsZW06DUEgc3Vi c2NyaWJlciByZXF1ZXN0cyBjb250ZW50IGFuZC9vciBhbiBpbnRlcmFjdGl2ZSBzZXJ2aWNl LiBUaGUgbmV0d29yayBtdXN0IHByb3Zpc2lvbiBlbm91Z2ggYmFuZHdpZHRoIGFuZCBtYW5h Z2UgdGhlIGRlbGF5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgc2Vzc2lvbiB0byBzYXRpc2Z5 IHRoaXMgcmVxdWVzdC4NDUluIG9yZGVyIHRvIGJlbmVmaXQgZnJvbSB0aGUgc2NhbGUgYW5k IGVmZmljaWVuY3kgb2Ygc2hhcmVkIFdBTnMgdGhhdCBzdXBwb3J0IG11bHRpcGxlIGFwcGxp Y2F0aW9ucywgdGhlIGVmZmVjdHMgb2YgY29udGVudGlvbiB3aWxsIG5lZWQgdG8gYmUgbWFu YWdlZCBlbmQgdG8gZW5kIGluIGEgd2F5IHRoYXQgdGFrZXMgYWNjb3VudCBvZiB0aGUgc3Bl Y2lmaWMgcmVxdWlyZW1lbnRzIG9mIHRoZSB1c2VyLCB1c2VyIGRldmljZSwgYXBwbGljYXRp b24sIGFuZCBjb250ZW50Lg0NVGhlIHNoYXJlZCBXQU4gbXVzdCBiZSBhYmxlIHRvIGFwcG9y dGlvbiBzZXJ2aWNlIChiYW5kd2lkdGggYW5kIGxhdGVuY3kpIHRvIHVzZXJzIHNvIHRoYXQg dGhlc2UgdXNlcnMgY2FuIHN1YnNjcmliZSB0byBhIGNvbnNpc3RlbnQgYW5kIHByZWRpY3Rh YmxlIGV4cGVyaWVuY2UuICBQcmVkaWN0YWJsZSBzZXJ2aWNlIGxldmVsIGlzIGEgcmVxdWly ZW1lbnQgZm9yIGNvbW1lcmNpYWwgZGVwbG95bWVudCBvZiBtYW55IG5ldyBoaWdoIHZhbHVl IHNlcnZpY2VzIHRoYXQgcmVseSBvbiB0aGUgYnJvYWRiYW5kIG5ldHdvcmsuICANDVdpdGgg dHJhZGl0aW9uYWwgdGVsZWNvbSBuZXR3b3Jrcywgc2VydmljZSBsZXZlbCBpcyBkZXRlcm1p bmVkIGJ5IGEgY29udHJhY3QgYmV0d2VlbiB0aGUgY2FycmllciBhbmQgdGhlIGVuZCB1c2Vy LiAgIFRoZSBlbmQgdXNlciBpcyBub3QgY29uY2VybmVkIHdpdGggdGhlIHN0cnVjdHVyZSBv ZiB0aGUgY2FycmllcpJzIG5ldHdvcmssIGFuZCBpcyBpc29sYXRlZCBmcm9tIHRoZSBlZmZl Y3RzIG9mIHRyYWZmaWMgZGVtYW5kcyBvZiBvdGhlciB1c2Vycy4gIA0NTmV3IGJyb2FkYmFu ZCBzZXJ2aWNlcyBhbmQgYXBwbGljYXRpb25zIHJlcXVpcmUgc2ltaWxhciBwcmVkaWN0YWJp bGl0eSBhbmQgc2ltcGxpY2l0eSwgZXZlbiB3aGVuIG11bHRpcGxlIHNlcnZpY2UgcHJvdmlk ZXJzIHBhcnRpY2lwYXRlIGluIGRlbGl2ZXJpbmcgdGhlIGRhdGEuICAgRW5kLXRvLUVuZCBR b1MgaXMgYW4gZWNvbm9taWMgaW1wZXJhdGl2ZSBmb3IgY2FycmllcnMsIHNlcnZpY2UgcHJv dmlkZXJzIGFuZCBmb3IgZW5kLXVzZXJzLg0NQ2FycmllcnMgcmVxdWlyZSB0aGUgYWJpbGl0 eSB0byBwcmljZSB0cmFuc3BvcnQgYmFzZWQgb24gaXRzIHZhbHVlIHRvIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIGFuZCB0byB0aGUgZW5kLXVzZXIuICBSZXZlbnVlIGlzIHJlcXVpcmVkIHRv IGp1c3RpZnkgdGhlIHJlcXVpcmVkIGludmVzdG1lbnRzIGluIG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUuICBQcmVkaWN0YWJsZSBFbmQtdG8tRW5kIFFvUyB3aWxsIGVuYWJsZSBhIHJhbmdl IG9mIG5ldyBoaWdoIHZhbHVlIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgYnkgY29udGVu dCwgYXBwbGljYXRpb24sIHN0b3JhZ2UgYW5kIHNlcnZpY2UgcHJvdmlkZXJzLiAgUHJpY2Ug ZGlmZmVyZW50aWF0aW9uIGlzIHVsdGltYXRlbHkgaW4gdGhlIGludGVyZXN0IG9mIGVuZC11 c2Vycywgd2hvIHdpbGwgZW5qb3kgYSByYW5nZSBvZiBuZXcgc2VydmljZSBhbHRlcm5hdGl2 ZXMuICANSXNzdWVzOg1UaGUgQnJva2VuIEhvdXJnbGFzcw1UaGUgb3JpZ2luYWwgbW9kZWwg b2YgdGhlIEludGVybmV0LCBhcyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgMSwgd2FzIHRoYXQg bWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgaG9zdCBjb21wdXRlcnMsIGRhdGEgc291cmNlcywg YW5kIGFwcGxpY2F0aW9uIHNlcnZlcnMgY291bGQgZGVsaXZlciBhIHdpZGUgcmFuZ2Ugb2Yg Y29udGVudCBhbmQgYXBwbGljYXRpb25zIHRvIGFuIGVxdWFsbHkgZGl2ZXJzZSByYW5nZSBv ZiBjbGllbnQgZGV2aWNlcywgb3ZlciBhIGxpbmtlZCBzZXQgb2YgaG9tb2dlbmVvdXMgbmV0 d29ya3MgdGhhdCBwcm92aWRlZCBhIHNpbmdsZSwgd2VsbC1kZWZpbmVkIHNlcnZpY2U6ICBj b25uZWN0aW9ubGVzcyB0cmFuc3BvcnQgb2YgZGF0YSBwYWNrZXRzLiAgVGhlIHByb3ZpZGVy cyBvZiB0aGUgdHJhbnNwb3J0IG5ldHdvcmtzIHdvdWxkIG5vdCBuZWVkIGFueSBrbm93bGVk Z2Ugb2YgdGhlIGNvbXBsZXggc2VydmljZXMgY29uc3RydWN0ZWQgYXQgbmV0d29yayBlbmRw b2ludHMsIGJlY2F1c2UgYWxsIHRyYWZmaWMgd291bGQgYmUgZnVubmVsbGVkIGludG8gYSBj b21tb24gSW50ZXJuZXR3b3JraW5nIFByb3RvY29sLg0NQmVjYXVzZSB0aGUgbG93LWZ1bmN0 aW9uIEludGVybmV0IHByb3ZpZGluZyBjb21tb24gdHJhbnNwb3J0IGRpZCBub3QgbmVlZCB0 byBzdXBwb3J0IGFueSBmdW5jdGlvbmFsaXR5IGJleW9uZCB0aGUgYmFzaWMgbmV0d29yayBw cm90b2NvbCwgaXQgZGlkbpJ0IG1hdHRlciB0byB0aGUgZW5kIHN5c3RlbXMgaWYgdGhlIHBh Y2tldHMgdHJhdmVsbGVkIG92ZXIgYSBzaW5nbGUsIG1hbmFnZWQgbmV0d29yayBvciBwYXNz ZWQgdGhyb3VnaCBzZXZlcmFsIG5ldHdvcmtzIHJ1biBieSBkaWZmZXJlbnQgc2VydmljZSBw cm92aWRlcnMuICBJUCBhbmQgaXRzIGFzc29jaWF0ZWQgaGFuZG9mZiBwcm90b2NvbHMgY291 bGQgZGVsaXZlciB0aGUgcGFja2V0czsgZGVsaXZlcnkgY291bGQgYmUgbWFkZSByZWxpYWJs ZSBhbmQgc2VsZi1tYW5hZ2luZyB3aXRoIHRoZSBhZGRpdGlvbiBvZiBhIFRDUCBsYXllciwg YW5kIGFueSBmdXJ0aGVyIHNlcnZpY2UgZGVmaW5pdGlvbiBjb3VsZCBiZSBsZWZ0IGVudGly ZWx5IHRvIHRoZSBjb250ZW50IHNvdXJjZXMgYW5kIGNsaWVudHMuDQ1UaGlzIJNob3VyZ2xh c3OUIG1vZGVsIG9mIHRoZSBJbnRlcm5ldCBzdXBwb3J0ZWQgdGhlIGV2b2x1dGlvbiBvZiBh IHdpZGUgcmFuZ2Ugb2Ygc2VydmljZXMsIGVuY291cmFnaW5nIGlubm92YXRpb24gYnkgbWFr aW5nIG5ldyBzZXJ2aWNlIGNvbmNlcHRzIHZlcnkgZWFzeSB0byBwdXQgaW50byBwcmFjdGlj ZTogIEp1c3QgYnVpbGQgdGhlIHNlcnZpY2UsIG1hcCBpdCB0byBJUCB0cmFuc3BvcnQsIGFu ZCBpbnZpdGUgdXNlcnMgdGhyb3VnaG91dCB0aGUgd29ybGQgdG8gdHJ5IGl0IG91dC4NDVVu Zm9ydHVuYXRlbHksIHRoZXJlIGFyZSBzb21lIHNlcnZpY2UgaW5ub3ZhdGlvbnMgdGhhdCB0 aGUgaG91cmdsYXNzIG1vZGVsIGNhbm5vdCBzdXBwb3J0LiAgVHdvLXdheSBjb21tdW5pY2F0 aW9uIHNlcnZpY2VzIHN1Y2ggYXMgSW50ZXJuZXQgdGVsZXBob255IGFuZCBJbnRlcm5ldCB2 aWRlbyBjb25mZXJlbmNpbmcgYXJlIG9ubHkgZWZmZWN0aXZlIGlmIHRoZSBkYXRhIGlzIHRy YW5zbWl0dGVkIHdpdGggbG93IGRlbGF5LiAgSW50ZXJuZXQgdmlkZW8gY292ZXJhZ2Ugb2Yg YSBsaXZlIGV2ZW50IGxvc2VzIG11Y2ggb2YgaXRzIHZhbHVlIGlmIHRoZSByZWNlaXZlciBt dXN0IGhlYXZpbHkgYnVmZmVyIHRoZSB0cmFmZmljIJYgYnV0IHRoZSBhbHRlcm5hdGl2ZSBp cyB0byBkZWxpdmVyIHRoZSBtZWRpYSBzdHJlYW0gYXQgYSBwcmVkaWN0YWJsZSBtaW5pbXVt IGRhdGEgcmF0ZSBhbmQgd2l0aCBib3VuZGVkIGRlbGF5IHZhcmlhbmNlLiAgSVAsIHdoaWNo IHdhcyBkZWxpYmVyYXRlbHkgc2ltcGxpZmllZCB0byB0aGUgZnVuY3Rpb24gb2YgZ2V0dGlu ZyBkYXRhIGZyb20gcG9pbnQgQSB0byBwb2ludCBCLCBwcm92aWRlcyBubyB3YXkgdG8gbWFu YWdlIGRlbGF5LCB0aHJvdWdocHV0LCBvciBkZWxheSB2YXJpYW5jZS4gIEV2ZW4gYSBtYWlu c3RyZWFtIEludGVybmV0IGFwcGxpY2F0aW9uIHN1Y2ggYXMgV2ViIGJyb3dzaW5nIGNhbiBi ZSBtYWRlIGluZWZmZWN0aXZlIGJ5IJNmbGFzaCBjcm93ZJQgdHJhZmZpYyBhbmQvb3IgdGhl IHRyYW5zbWlzc2lvbiBvZiBsYXJnZSBmaWxlcyBhbmQgcmljaCBtZWRpYSBzdHJlYW1zIHRv IGJyb2FkYmFuZCB1c2Vycy4NDU5ldHdvcmsgZGVsYXlzIGFuZCB0aHJvdWdocHV0IGxpbWl0 YXRpb25zIGFyZSBuYXR1cmFsIGNvbnNlcXVlbmNlcyBvZiBjb25nZXN0aW9uIGF0IHZhcmlv dXMgcGxhY2VzIGFsb25nIHRoZSBkYXRhIHRyYW5zbWlzc2lvbiBwYXRoLiAgSGVhdmlseSBv dmVyLXByb3Zpc2lvbmluZyBuZXR3b3JrIHJlc291cmNlcyBjYW4gb3ZlcmNvbWUgdGhlIHBy b2JsZW1zLCBzbyB0aGF0IGNvbmdlc3Rpb24gZG9lcyBub3Qgb2NjdXIsIGJ1dCB0aGlzIGNh biBiZSBhbiBleHBlbnNpdmUgc29sdXRpb24gdW5sZXNzIGl0IGlzIHVzZWQgc2VsZWN0aXZl bHkuAiAgV2hlbiB0cmFuc3BvcnQgY29zdHMgYXJlIGEgc2lnbmlmaWNhbnQgcGFydCBvZiB0 aGUgdG90YWwgY29zdCBvZiBydW5uaW5nIGFuIGFwcGxpY2F0aW9uIG9yIHNlcnZpY2UsIHRo ZXJlIGFyZSBzdHJvbmcgZmluYW5jaWFsIGluY2VudGl2ZXMgdG8gaW1wcm92ZSBsaW5rIHV0 aWxpemF0aW9uLiAgIE1vcmUgZWZmaWNpZW50IGFwcHJvYWNoZXMgaW52b2x2ZSBtYW5hZ2lu ZyB0aGUgcG90ZW50aWFsIG5ldHdvcmsgYm90dGxlbmVja3MgaW4gc3VjaCBhIHdheSB0aGF0 IHNvbWUgb2YgdGhlIHRyYWZmaWMgZ2V0cyBzcGVjaWFsIGhhbmRsaW5nLCBzZWxlY3RpdmVs eSBtYW5hZ2luZyBhY2Nlc3MgdG8gZGVkaWNhdGVkIGJhbmR3aWR0aCwgYW5kIHNlbGVjdGl2 ZWx5IGJ5cGFzc2luZyB3aWRlLWFyZWEgbmV0d29ya3MgYnkgc3RhZ2luZyBjb250ZW50IGZv ciBsb2NhbCBkZWxpdmVyeS4gIA0NSW4gb3JkZXIgdG8gcHJvdmlkZSB0aGlzIHNvcnQgb2Yg UW9TIG1hbmFnZW1lbnQsIHRvZGF5knMgbmV0d29ya3MgcHJvdmlkZSBhIG51bWJlciBvZiB0 cmFmZmljIGNvbnRyb2wgbWVjaGFuaXNtcyBhdCBldmVyeSBzdGFnZSBpbiB0aGUgY29udGVu dCBkZWxpdmVyeSBjaGFpbiBzaG93biBpbiBGaWd1cmUgMi4gIA0NV2hpbGUgdGhlIGVuZHBv aW50cyBvZiB0aGUgZGF0YSBzZXNzaW9uIGFyZSBzdGlsbCBhY3RpdmVseSBpbnZvbHZlZCBp biBwcm92aWRpbmcgUW9TIHRocm91Z2ggYXJlYXMgb2YgdHJhZmZpYyBjb250ZW50aW9uLCB0 aGVyZSBhcmUgc2V2ZXJhbCBjb250ZW50aW9uIHBvaW50cyB0aGF0IG11c3QgYmUgbWFuYWdl ZCBieSBvdGhlciBwYXJ0aWNpcGFudHMgaW4gdGhlIGRlbGl2ZXJ5IGNoYWluLiAgUmF0aGVy IHRoYW4gYmVpbmcgaGlkZGVuIGJlaGluZCBhIHNpbXBsZSBJUCBpbnRlcmZhY2UsIHRoZSBw cm92aWRlcnMgb2YgdGhlIGFjY2VzcyBuZXR3b3JrLCBkYXRhIGFnZ3JlZ2F0aW9uIJNlZGdl lCBjZW50ZXJzLCBhbmQgbXVsdGlwbGUgd2lkZS1hcmVhIG5ldHdvcmtzIHBsYXkgYW4gYWN0 aXZlIHJvbGUgaW4gbWFuYWdpbmcgdGhyb3VnaHB1dCBhbmQgZGVsYXkuICAgSW5zdGVhZCBv ZiBzaW1wbHkgaGFuZGluZyBkYXRhIG9mZiB0byBhIHNpbXBsZSBJUCBuZXR3b3JrLCB0aGUg ZW5kcG9pbnRzIG11c3Qgbm93IG5lZ290aWF0ZSBhcHByb3ByaWF0ZSBzZXJ2aWNlIGNoYXJh Y3RlcmlzdGljcyB3aXRoIGEgbnVtYmVyIG9mIGludGVybWVkaWFyaWVzLg1XaG8gaXMgaW52 b2x2ZWQgd2l0aCB0aGUgUW9TIGRlY2lzaW9uPw1XaG8gYXJlIHRoZXNlIG5ldyBtYW5hZ2Vy cyBvZiBkYXRhIGRlbGl2ZXJ5PyBDb250ZW50aW9uIG1hbmFnZW1lbnQgaXMgbmVlZGVkIHdo ZXJldmVyIHRoZXJlIGlzIGNvbnRlbnRpb24uICBTdXBwb3NlIHRoYXQgYSBzdWJzY3JpYmVy knMgUEMgb3Igc2V0LXRvcCBib3ggaW5pdGlhdGVzIHRoZSBkb3dubG9hZCBvZiBhbiBpdGVt IG9mIGNvbnRlbnQuICBJZiB0aGUgUEMgaXMgY29ubmVjdGVkIHRvIGEgaG9tZS9vZmZpY2Ug bmV0d29yayBhbmQgYWNjZXNzIGRldmljZSB0aGF0IGlzIHNoYXJlZCB3aXRoIG90aGVyIGVu ZCBlcXVpcG1lbnQsIHRoZXJlIG1heSBiZSBjb250ZW50aW9uIHdpdGhpbiB0aGlzIGJ1aWxk aW5nIGFjY2VzcyBzeXN0ZW0uIEZyb20gdGhlIHByZW1pc2UgbmV0d29yaywgdGhlIHNlc3Np b24gaXMgaGFuZGVkIG9mZiB0byBhbiBhY2Nlc3MgdGVjaG5vbG9neTsgZS5nLiBjYWJsZSwg RFNMLCBFdGhlcm5ldCwgb3Igd2lyZWxlc3MuIFRoZSBhY2Nlc3MgbmV0d29yayBjb3VsZCB0 YWtlIHRoZSBmb3JtIG9mIGEgc2hhcmVkIG1lZGl1bSwgd2hlcmUgdGhlcmUgaXMgY29udGVu dGlvbiBiZXR3ZWVuIHN1YnNjcmliZXJzLCBvciBhIGRlZGljYXRlZCBjb25uZWN0aW9uLg0N TmV4dCwgdGhlcmUgd2lsbCB0eXBpY2FsbHkgYmUgYW4gk2FjY2VzcyBub2RllCBhZ2dyZWdh dGlvbiBkZXZpY2UsIGVnIGNhYmxlIG1vZGVtIGhlYWQtZW5kLCBEU0xBTSwgZGF0YSBzd2l0 Y2ggb3Igd2lyZWxlc3MgY2VsbCB0aGF0IHdpbGwgYWdncmVnYXRlIG1hbnkgc3Vic2NyaWJl cnMgaW50byBvbmUgb3IgbW9yZSB1cGxpbmtzIHRvIGFuIGFjY2VzcyBjb25jZW50cmF0aW9u IHBvaW50LCBvciCTc2VydmljZSBub2RllCBsb2NhdGVkIGF0IGFuIJNlZGdlIGNlbnRlcpQu ICBUaGUgZWRnZSBjZW50ZXIgbWF5IGFwcGx5IHNvbWUga2luZCBvZiBzZXJ2aWNlIHN1Y2gg YXMgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgKEFBQSks IGZpcmV3YWxsLCB0cmFmZmljIGNvbmRpdGlvbmluZyBldGMgYW5kIGNhbiBkaXN0cmlidXRl IGFuZCByZWFnZ3JlZ2F0ZSB0aGUgdHJhZmZpYyBpbnRvIGFuIGFjY2VzcyBjb3JlLCB3aGlj aCB0aGVuIGNvbm5lY3RzIHRvIGFuIEludGVybmV0IFNlcnZpY2UgUHJvdmlkZXIgdG8gcHJv dmlkZSBhY2Nlc3MgdG8gdGhlIGdsb2JhbCBJbnRlcm5ldC4gIEFzIGFuIGFsdGVybmF0aXZl IHRvIEludGVybmV0IHRyYW5zcG9ydCwgdGhlIGVkZ2UgY2VudGVyIG1heSBoYXZlIGxvY2Fs IGNhY2hlcyBhbmQgc2VydmVycywgc2F0ZWxsaXRlIGZlZWRzLCBhbmQgYWNjZXNzIHRvIHNw ZWNpYWxpemVkIG5ldHdvcmtzIHRoYXQgcHJvdmlkZSBwYXJ0aWN1bGFyIHBlcmZvcm1hbmNl IGNoYXJhY3RlcmlzdGljcy4NDUZpbmFsbHksIHRoZSBwcmltYXJ5IGhvc3RpbmcgY2VudGVy IGZvciB0aGUgY29udGVudCBvciBhcHBsaWNhdGlvbiBjb3VsZCBiZSBlaXRoZXIgYSBjZW50 cmFsaXplZCBkYXRhIGNlbnRlciBvciBhIGRpc3RyaWJ1dGVkIGhvc3RpbmcgcmVzb3VyY2Us IGluIGVpdGhlciBjYXNlIG1ha2luZyB1c2Ugb2Ygc29waGlzdGljYXRlZCBsb2FkIGJhbGFu Y2luZyBhbmQgY29udGVudGlvbiBtYW5hZ2VtZW50IHRlY2huaXF1ZXMgdGhyb3VnaCBkYXRh IHN3aXRjaGVzIGFuZCBpbnRlbGxpZ2VudCBzdG9yYWdlLWFyZWEgbmV0d29ya3MuDQ1GaWd1 cmVzIDMgliA4IGRlc2NyaWJlIHNvbWUgb2YgdGhlIGtleSBRb1MgaXNzdWVzIGludm9sdmVk IGluIGVhY2ggc3RhZ2Ugb2YgZGF0YSBkZWxpdmVyeS4NV2hpY2ggZGV2aWNlcyBrbm93IHRo ZSBkYXRhIGRlbGl2ZXJ5IHJlcXVpcmVtZW50cz8NVGhlIFFvUyByZXF1aXJlbWVudHMgb2Yg YSBkYXRhIHNlc3Npb24gYXJlIHR5cGljYWxseSBkZXRlcm1pbmVkIGF0IHRoZSBlbmRwb2lu dHMgb2YgdGhlIHNlc3Npb24uICBGb3IgZXhhbXBsZSwgd2hlbiBhIHJlcXVlc3QgaXMgbWFk ZSB0byBkb3dubG9hZCBzb21lIHN0cmVhbWVkIGJyb2FkYmFuZCBjb250ZW50LCB0aGUgYmFu ZHdpZHRoIHJlcXVpcmVtZW50IG1heSBiZSBkZXRlcm1pbmVkIHNvbGVseSBieSB0aGUgZW5j b2RpbmcgdHlwZSBvZiB0aGUgZGVzaXJlZCBjb250ZW50LiBUaGlzIGVuY29kaW5nIHR5cGUg aXMgc2lnbmFsZWQgdG8gdGhlIGNsaWVudCByZWFkZXIgKGVnIFJlYWxQbGF5ZXIpIGJ5IHdh eSBvZiB0aGUgc3RyZWFtaW5nIHNpZ25hbGluZyBwcm90b2NvbC4gSW4gbW9yZSBjb21wbGlj YXRlZCBzaXR1YXRpb25zLCB0aGUgUW9TIHJlcXVpcmVtZW50cyBtYXkgYmUgZGV0ZXJtaW5l ZCBqb2ludGx5IGJ5IHRoZSBuYXR1cmUgb2YgdGhlIGFwcGxpY2F0aW9uLCB0aGUgY2FwYWJp bGl0aWVzIG9mIGVhY2ggZW5kcG9pbnQgZGV2aWNlLCB0aGUgY29udGVudCBwcm92aWRlcpJz IHF1YWxpdHkgYXNzdXJhbmNlIHBvbGljaWVzLCBhbmQgdGhlIHdpbGxpbmduZXNzIG9mIHRo ZSBjbGllbnQgYW5kIGNvbnRlbnQgcHJvdmlkZXIgdG8gcGF5IGZvciBwcmVtaXVtIGRlbGl2 ZXJ5LiAgQnV0IGl0IGlzIHN0aWxsIHRoZSBjb250ZW50IHNvdXJjZSBhbmQgdGhlIHJlcXVl c3RpbmcgY2xpZW50IHRoYXQgZGV0ZXJtaW5lIHRoZSB1bmNvbnN0cmFpbmVkIHJlcXVpcmVt ZW50cyBmb3IgZGF0YSBkZWxpdmVyeSCWIGkuZS4gdGhlIFFvUyBiZXN0IHN1aXRlZCB0byB0 aGUgZGF0YSBzZXNzaW9uLg0NT3RoZXIgcGFydHMgb2YgdGhlIGRhdGEgZGVsaXZlcnkgcGF0 aCBtdXN0IGhhdmUgdGhlIGNhcGFiaWxpdGllcyB0aGF0IG1ha2UgdGhlIGRlc2lyZWQgUW9T IGF0dGFpbmFibGUuICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudJJzIGFkYXB0ZWQgbGluZSBy YXRlIChhY2Nlc3MgbmV0d29yaykgbXVzdCBzdXBwb3J0IHRoZSCTcmVxdWlyZWSUIGJhbmR3 aWR0aC4gIEhpZ2ggY29uY3VycmVudCBkZW1hbmQgZm9yIHRoZSBjb250ZW50IG1heSByZXF1 aXJlIG11bHRpY2FzdCAoYWNjZXNzIGFuZCB3aWRlLWFyZWEgbmV0d29ya3MpIG9yIGNhY2hp bmcgKGVkZ2UgY2VudGVyKSB0byBtZWV0IHRoZSCTcmVxdWlyZW1lbnRzLpQgIEV2ZW4gd2l0 aGluIHRoZSBlbmQgbm9kZXMsIHRoZSBjYXBhYmlsaXRpZXMgYW5kIGNvbnN0cmFpbnRzIG9m IHRoZSBwcmVtaXNlIExBTiBhbmQgc3RvcmFnZS1hcmVhIG5ldHdvcmsgcGxheSBhIHJvbGUg aW4gZGV0ZXJtaW5pbmcgdGhlIGRlbGl2ZXJhYmxlIFFvUy4NDVFvUyBzcGVjaWZpY2F0aW9u IHdpbGwgcmVxdWlyZSBuZWdvdGlhdGlvbiBhbW9uZyBhbGwgb2YgdGhlc2UgZWxlbWVudHMs IGFuZCBRb1MgZGVsaXZlcnkgd2lsbCByZXF1aXJlIHRoZWlyIGNvb3JkaW5hdGVkIGFjdGlv bi4gIEluc3RlYWQgb2YgZnVubmVsbGluZyBkYXRhIHRocm91Z2ggYSBzaW1wbGUgaG91cmds YXNzLCB0aGUgZW5kLWNsaWVudCBhbmQgZW5kLXNlcnZlciBub3cgZmFjZSBhIGNvbXBsZXgg cHJvYmxlbSBpbiBzdXBwbHkgY2hhaW4gbWFuYWdlbWVudC4NSG93IGRvIHRoZSBuZXR3b3Jr IGVsZW1lbnRzIHByb3ZpZGUgUW9TPw1PbmUgbWVhc3VyZSBvZiB0aGUgZ3Jvd2luZyBpbXBv cnRhbmNlIG9mIHByb3ZpZGluZyBtdWx0aXBsZSBRb1MgY2hhcmFjdGVyaXN0aWNzIGluIHNo YXJlZCBuZXR3b3JrcyBpcyB0aGUgbGFyZ2Ugc2V0IG9mIHRvb2xzIHRoYXQgaGF2ZSBiZWVu IGRldmVsb3BlZCBhbmQgZGVwbG95ZWQgZm9yIHRoaXMgcHVycG9zZS4gIFRoZXkgaW5jbHVk ZToNDVByb3Bvc2VkIHVuaXZlcnNhbCBzb2x1dGlvbnMNDUludFNlcnYgd2l0aCBSU1ZQIGFu ZCBBVE0gU1ZDIHNpZ25hbGxpbmcgd2VyZSBlYWNoIHN1cHBvc2VkIHRvIHByb3ZpZGUgIHVu aXZlcnNhbCBtZWNoYW5pc21zIGZvciBzZXR0aW5nIHVwIGNvbm5lY3Rpb25zIHdpdGggRW5k LXRvLUVuZCBRb1MgZ3VhcmFudGVlcy4gIE5laXRoZXIgcHJvcG9zYWwgaGFzIGFjaGlldmVk IHRoaXMgZ29hbCwgYmVjYXVzZSBvZiBzY2FsaW5nIHByb2JsZW1zIGFuZCB0aGUgZGlmZmlj dWx0eSBvZiBpbXBsZW1lbnRpbmcgYWxsIG9mIHRoZSBjb21wb25lbnRzIGVuZC10by1lbmQu ICANDZNVbml2ZXJzYWwgc29sdXRpb26UIGh5YnJpZHMNDUFUTSBoYXMgYmVlbiB3aWRlbHkg ZGVwbG95ZWQgYXMgYSB0cmFmZmljLWVuZ2luZWVyaW5nIGxheWVyIGZvciBJUCBuZXR3b3Jr cy4gIA0NUlNWUC1URSBhbmQgQ1ItTERQIGFyZSBldm9sdmluZyBhcyBhIHNpZ25hbGxpbmcg aW50ZXJmYWNlIGZvciB0cmFmZmljIGVuZ2luZWVyaW5nIG9mIGFnZ3JlZ2F0ZXMgaW4gTVBM UywgR01QTFMgYW5kIE1QIExhbWJkYSBTIG5ldHdvcmtzLiAgVGhlc2UgdHJhZmZpYy1lbmdp bmVlcmluZyBtZWNoYW5pc21zIGNhbiBiZSBhcHBsaWVkIHdpdGhpbiBhIG5ldHdvcmsgYW5k IGF0IHRoZSBuZXR3b3JrLXRvLW5ldHdvcmsgaW50ZXJmYWNlLg0NQmFuZHdpZHRoIHJlc2Vy dmF0aW9uIGFuZCB2aXJ0dWFsIHRydW5raW5nDQ1EZXRlcm1pbmlzdGljIHJlc2VydmF0aW9u IG9mIGJhbmR3aWR0aCBwcm92aWRlcyB0aGUgc3Ryb25nZXN0IGd1YXJhbnRlZSBvZiBRb1Ms IGJ1dCBpdCBpcyBhbHNvIHRoZSBtb3N0IGRpZmZpY3VsdCB0byBhY2hpZXZlLiAgUlNWUCAo SVApLCBDQlIgYW5kIFZCUiAoQVRNKSwgYW5kIENvbW1pdHRlZCBJbmZvcm1hdGlvbiBSYXRl IChmcmFtZSByZWxheSkgZWFjaCBwcm92aWRlIGEgZGF0YSBzZXNzaW9uIG9yIGdyb3VwIG9m IHNlc3Npb25zIHdpdGggYSBndWFyYW50ZWVkIG1pbmltdW0gYmFuZHdpZHRoLCBidXQgaXQg aXMgZGlmZmljdWx0IHRvIGltcG9zc2libGUgdG8gZXN0YWJsaXNoIHRoZXNlIHJlc2VydmF0 aW9ucyBvbiBkZW1hbmQuICBSU1ZQIGlzIGhhcmQgdG8gc2NhbGUgdG8gY29tcGxleCBuZXR3 b3JrcywgQVRNIFNWQ3MgZG9uknQgc3VwcG9ydCBhIGhpZ2ggY2FsbCBzZXQtdXAgcmF0ZSwg YW5kIGZyYW1lIHJlbGF5IHdhc26SdCBkZXNpZ25lZCBmb3IgcmVhbC10aW1lIGNvbmZpZ3Vy YXRpb24uIA0NV2hpbGUgcmVzZXJ2YXRpb24gbWV0aG9kcyBhcmUgZGlmZmljdWx0IHRvIHNl dCB1cCBvbiBhIGNhbGwtYnktY2FsbCBiYXNpcywgdGhleSBjYW4gcHJvdmlkZSBsYXJnZSwg c2hhcmVkIGRhdGEgcGF0aHMgYmV0d2VlbiBuZXR3b3JrIGVkZ2Ugbm9kZXMgd2l0aCBndWFy YW50ZWVkIGFnZ3JlZ2F0ZSBiYW5kd2lkdGguICBCeSBtYW5hZ2luZyB0aGUgYWRtaXNzaW9u IG9mIGRhdGEgc2Vzc2lvbnMgaW50byB0aGVzZSB2aXJ0dWFsIHRydW5rcyAoaS5lLiBtYXJr aW5nIHRoZSBkYXRhIHBhdGggk2Z1bGyUIHdoZW4gdGhlIHRvdGFsIHJlcXVlc3RlZCBiYW5k d2lkdGggb2YgdGhlIHNlc3Npb25zIGl0IGlzIGNhcnJ5aW5nIGV4Y2VlZHMgc29tZSBsaW1p dCksIGluZGl2aWR1YWwgZGF0YSBzZXNzaW9ucyBjYW4gYmUgcHJvdmlkZWQgd2l0aCBhIGZv cm0gb2Ygc3RhdGlzdGljYWwgYmFuZHdpZHRoIJNyZXNlcnZhdGlvbiyUIGluIHdoaWNoIHRo ZSBwcm9iYWJpbGl0eSBvZiBmYWxsaW5nIGJlbG93IGEgc2Vzc2lvbpJzIHNwZWNpZmllZCBt aW5pbXVtIGJhbmR3aWR0aCBvciBtYXhpbXVtIGRlbGF5IGlzIHF1aXRlIGxvdy4gIE1QTFMg YW5kIEFUTSB2aXJ0dWFsIHBhdGhzIGNhbiBiZSB1c2VkIGluIHRoaXMgd2F5Lg0NUHJpb3Jp dHkNDUluc3RlYWQgb2YgYXR0ZW1wdGluZyB0byBndWFyYW50ZWUgdGhlIGJhbmR3aWR0aCBh bmQgZGVsYXkgY2hhcmFjdGVyaXN0aWNzIG9mIGEgc2Vzc2lvbiwgcHJpb3JpdHkgc2NoZW1l cyBzdWNoIGFzIERpZmZTZXJ2IGdpdmUgUW9TLXNlbnNpdGl2ZSBzZXNzaW9ucyAoZS5nLiB2 b2ljZSBjYWxscykgcHJlZmVyZW50aWFsIHRyZWF0bWVudCBvdmVyIGxlc3Mgc2Vuc2l0aXZl IGFwcGxpY2F0aW9ucyAoc3VjaCBhcyBmaWxlIHRyYW5zZmVycykuICBBcyBsb25nIGFzIHRo ZXJlIGlzIGVub3VnaCBsb3ctcHJpb3JpdHkgdHJhZmZpYyB0byCTcHVzaCBhc2lkZSyUIHRo aXMgY2FuIHByb3ZpZGUgdGhlIGhpZ2gtcHJpb3JpdHkgdHJhZmZpYyB3aXRoIGhpZ2ggdGhy b3VnaHB1dCBhbmQgbG93IGRlbGF5LiAgQXMgdGhlIHZvbHVtZSBvZiBoaWdoLXByaW9yaXR5 IHRyYWZmaWMgaW5jcmVhc2VzIGluIHJlbGF0aW9uIHRvIHRoZSB0b3RhbCBhdmFpbGFibGUg Y2FwYWNpdHksIHRoZSBRb1MgZm9yIHRoZSBoaWdoLXByaW9yaXR5IHRyYWZmaWMgZ3JhZHVh bGx5IGRlZ3JhZGVzLiAgSW4gcHJhY3RpY2UsIHRoZXJlIG1heSBiZSBhIFFvUyB0aHJlc2hv bGQgYmVsb3cgd2hpY2ggdGhlIHNlc3Npb24gbm8gbG9uZ2VyIHN1cHBvcnRzIGl0cyBhcHBs aWNhdGlvbiBhZGVxdWF0ZWx5LCBhbmQgc3RyYXRlZ2llcyBhcmUgbmVlZGVkIHRvIGF2b2lk IHRoaXMgc2l0dWF0aW9uIChzZXNzaW9uIGFkbWlzc2lvbiBjb250cm9sKSBhbmQgdG8gbWFu YWdlIGl0IHdoZW4gaXQgb2NjdXJzIChkeW5hbWljIHJlY29uZmlndXJhdGlvbikuDQ1Mb2Nh bCBkZWxpdmVyeQ0NVHJhZmZpYyBjb25nZXN0aW9uIGluIHRoZSBXQU4gYW5kIHByaW1hcnkg aG9zdGluZyBjZW50ZXIgY2FuIGJlIGJ5cGFzc2VkIGJ5IGRlbGl2ZXJpbmcgY29udGVudCBk aXJlY3RseSBmcm9tIGEgbG9jYWwgc291cmNlIHN1Y2ggYXMgdGhlIGVkZ2UgY2VudGVyLiAg U2V2ZXJhbCBlcXVpcG1lbnQgdmVuZG9ycyBwcm92aWRlIGRlbWFuZCBjYWNoaW5nIHN5c3Rl bXMgdGhhdCBtYWludGFpbiBsb2NhbCBjb3BpZXMgb2YgdGhlIG1vc3QgcmVjZW50bHkgcmVx dWVzdGVkIGRhdGEsIHNvIHRoYXQgcmVwZWF0IHJlcXVlc3RzIGZvciB0aGUgZGF0YSBjYW4g YmUgc2VydmVkIGRpcmVjdGx5IGZyb20gdGhlIGNhY2hlLiAgQ29udGVudCBkZWxpdmVyeSBu ZXR3b3JrcyBwcm92aWRlIG1hbmFnZWQgY2FjaGluZyBzeXN0ZW1zIHRoYXQgZW5hYmxlIGNv bnRlbnQgcHJvdmlkZXJzIHRvIHByZS1wb3NpdGlvbiBjcml0aWNhbCBkYXRhIGFzIHdlbGwg YXMgZHluYW1pY2FsbHkgaW5jcmVhc2luZyB0aGVpciBsb2NhbCBzZXJ2aWNlIGNhcGFjaXR5 IGluIHJlc3BvbnNlIHRvIGRlbWFuZC4gIERpc3RyaWJ1dGVkIGRhdGEgc291cmNpbmcgcGxh Y2VzIHByaW1hcnkgc2VydmVycyBhbmQvb3Igc3RvcmFnZSByZXNvdXJjZXMgaW4gb3IgbmVh ciBlZGdlIGNlbnRlcnMgYW5kIGtleSBJbnRlcm5ldCBsb2NhdGlvbnMsIHRvIHJlZHVjZSB0 aGUgY29zdCBhbmQgcGVyZm9ybWFuY2UgaW1wYWN0cyBvZiB3aWRlLWFyZWEgZGF0YSB0cmFu c3BvcnQuDQ1OZXR3b3JrIHNlbGVjdGlvbg0NQXQgYW4gZWRnZSBjZW50ZXIgKG9yIG90aGVy IHBvaW50IG9mIGZsZXhpYmlsaXR5IGluIHRoZSBkYXRhIHBhdGgpLCB0aGVyZSBtYXkgYmUg bW9yZSB0aGFuIG9uZSBXQU4gYXZhaWxhYmxlIHRvIGNhcnJ5IHRyYWZmaWMgdG8gcmVtb3Rl IGxvY2F0aW9ucy4gIElmIHRoZXNlIFdBTnMgaGF2ZSBkaWZmZXJlbnQgUW9TIGNoYXJhY3Rl cmlzdGljcyAoZWl0aGVyIG92ZXJhbGwgb3IgYXQgYSBwYXJ0aWN1bGFyIHRpbWUpLCByb3V0 aW5nIHRyYWZmaWMgdG8gZGlmZmVyZW50IFdBTnMgcHJvdmlkZXMgYW5vdGhlciB0b29sIHRv IG1hbmFnZSBRb1MuICBUaGlzIGFwcHJvYWNoIGNhbiBhbHNvIGJlIHVzZWQgYnkgdGhlIHBy ZW1pc2UgbmV0d29yaywgaWYgaXQgaGFzIG11bHRpcGxlIGFjY2VzcyBuZXR3b3JrIGNvbm5l Y3Rpb25zLg0NTXVsdGljYXN0DQ1EYXRhIHRoYXQgaXMgdHJhbnNtaXR0ZWQgY29uY3VycmVu dGx5IGZyb20gYSBzbWFsbCBudW1iZXIgb2Ygc291cmNlcyB0byBhIGxhcmdlIG51bWJlciBv ZiB1c2VycyBjYW4gYmVuZWZpdCBmcm9tIG11bHRpY2FzdCB0ZWNobm9sb2d5LCB3aGljaCBy ZXBsaWNhdGVzIHRoZSBkYXRhIG9uIGRlbWFuZCBpbiB2YXJpb3VzIG5ldHdvcmsgZWxlbWVu dHMuICBUaGlzIGltcHJvdmVzIFFvUyBieSByZWR1Y2luZyBjb250ZW50aW9uIHRocm91Z2hv dXQgdGhlIGRhdGEgZGVsaXZlcnkgY2hhaW4uDQ1WYXJpYXRpb25zIGluIHRoZSBhY2Nlc3Mg bmV0d29yaw0NVGhlIGFjY2VzcyBuZXR3b3JrIGhhcyBtb3JlIGxlbmllbnQgc2NhbGFiaWxp dHkgcmVxdWlyZW1lbnRzIHRoYW4gd2lkZS1hcmVhIG5ldHdvcmtzLCBhbmQgdGhleSBjYW4g dGFrZSBhZHZhbnRhZ2Ugb2YgdGVjaG5vbG9neS1zcGVjaWZpYyBhcHByb2FjaGVzLiAgRE9D U0lTIDEuMSAoY2FibGUgbW9kZW0gc3lzdGVtcyksIElFRUUgODAyLjEgUC9RIChGVFRDL0gg d2l0aCBzd2l0Y2hlZCBFdGhlcm5ldCksIGFuZCB0aGUgdXNlIG9mIEFUTSBRb1MgaW4gc29t ZSB4RFNMIGFjY2VzcyBuZXR3b3JrcyBhcmUgdGhyZWUgZGlmZmVyZW50IHdheXMgdG8gbWFu YWdlIGNvbnRlbnRpb24gaW4gdGhlIGFjY2VzcyBuZXR3b3JrLiAgVGhlIFJTVlAgSVAgUW9T IG1lY2hhbmlzbSwgd2hpY2ggaGFzIHNjYWxpbmcgbGltaXRhdGlvbnMgYXMgYW4gZW5kLXRv LWVuZCBzb2x1dGlvbiwgbWlnaHQgYmUgbW9yZSBlZmZlY3RpdmUgYXMgYSBzdWJzeXN0ZW0g bWFuYWdlbWVudCB0b29sLg0NSW50ZXJmYWNlcyBldmVyeXdoZXJlDQ1FYXJseSBRb1MgY29u dHJvbCBtZWNoYW5pc21zIHByb3ZpZGVkIHR3byBiYXNpYyB0eXBlcyBvZiBpbnRlcmZhY2U6 IGEgdXNlciB0byBuZXR3b3JrIGludGVyZmFjZSAoVU5JKSwgYW5kIGEgbmV0d29yay10by1u ZXR3b3JrIGludGVyZmFjZSAoTk5JKS4gIFByb3ZpZGluZyBRb1MgdGhyb3VnaCB0aGUgY3Vy cmVudCBlbnZpcm9ubWVudCBvZiBtdWx0aXBsZSBuZXR3b3JrIHByb3ZpZGVycywgQ0ROcywg ZWRnZSBkZWxpdmVyeSBwcm92aWRlcnMsIHN0b3JhZ2UtYXJlYSBuZXR3b3JrcywgYW5kIHNl cnZlciBjYXBhYmlsaXRpZXMsIG5vdyBpbnZvbHZlcyBhIGxhcmdlIG51bWJlciBvZiBkaWZm ZXJlbnQgaW50ZXJmYWNlcyAgLS0gZXZlbiBpZiBhbGwgb2YgdGhlIHN5c3RlbXMgY29uZm9y bSB0byB2YXJpb3VzIGluZHVzdHJ5IJNzdGFuZGFyZHMulA0NQ2hhb3MgYW5kIENyZWF0aXZp dHkNRWFjaCBzZWdtZW50IG9mIHRoZSBkYXRhIGRlbGl2ZXJ5IGNoYWluIGlzIGRyYXduIGZy b20gYSBzZXQgb2YgY29tcGV0aW5nIHNlcnZpY2UgcHJvdmlkZXJzLiAgRWFjaCBzZXJ2aWNl IHByb3ZpZGVyIHVzZXMgb25lIG9yIG1vcmUgb2YgYSBudW1iZXIgb2YgZGlmZmVyZW50IHRl Y2hub2xvZ2llcyBhbmQgY29udGVudGlvbiBtYW5hZ2VtZW50IHN0cmF0ZWdpZXMuICBBdCBm aXJzdCBnbGFuY2UsIHRoaXMgaXMgYSByZWNpcGUgZm9yIGNoYW9zLg0NV2hhdCBoYXMgaGFw cGVuZWQgaXMgdGhhdCB0aGUgdHlwZSBvZiBmcmVlLW1hcmtldCBjcmVhdGl2aXR5IGFuZCBp bm5vdmF0aW9uIHRoYXQgdGhlIG9yaWdpbmFsIEludGVybmV0IHN1cHBvcnRlZCBhdCB0aGUg bmV0d29yayBlbmRwb2ludHMgaGFzIG5vdyBiZWNvbWUgcGFydCBvZiB0aGUgbmV0d29yayBp dHNlbGYuICCTVGhlIG5ldHdvcmuUIGhhcyBhbHdheXMgYmVlbiBhIGZyZWUgbWFya2V0IGlu IGJ1c2luZXNzIHRlcm1zLCBidXQgd2hlbiBpdCB3YXMgZW50aXJlbHkgZGVmaW5lZCBieSBj b21tb24sIGJhc2ljIHNldCBvZiBwcm90b2NvbHMsIGl0IHJlYWxseSBkaWRuknQgbWF0dGVy IGlmIG9uZZJzIGRhdGEgZ290IGhhbmRlZCBvZmYgZnJvbSBCZWxsU291dGggdG8gTWluZHNw cmluZyB0byBVVU5ldCB0byBTcHJpbnRMaW5rIHRvIEdsb2JhbCBDcm9zc2luZyB0byBNU04g dG8gVS5TLiBXZXN0IGJlZm9yZSByZWFjaGluZyBpdHMgZGVzdGluYXRpb24uICBOZXcgdGVj aG5vbG9naWVzIHdlcmUgc2ltaWxhcmx5IGhpZGRlbiBiZWhpbmQgdGhlIHByb3RvY29sIGN1 cnRhaW4uICAoVGhlIGlubmVyIHdvcmtpbmdzIG9mIGFuIGVhcmx5IHJvdXRlciBoYWQgbGl0 dGxlIGluIGNvbW1vbiB3aXRoIHRoZSBzd2l0Y2hpbmcgZmFicmljcyBpbiBvdXIgcm91dGVy cyB0b2RheSwgYnV0IGEgVENQL0lQIHNlc3Npb24ganVzdCBydW5zIHRocm91Z2ggdGhlIG5l dyBzeXN0ZW0gZmFzdGVyLikNDUJlc3QtZWZmb3J0IG5ldHdvcmtzIGFyZSBzdWl0YWJsZSBv bmx5IGZvciBiZXN0LWVmZm9ydCBzZXJ2aWNlcy4gIEJlY2F1c2UgZnVuZGFtZW50YWwgaW5u b3ZhdGlvbnMgYXJlIG5vdyBhZGRpbmcgdXNlci12aXNpYmxlIGZ1bmN0aW9ucyB0byCTdGhl IG5ldHdvcmuUIGl0c2VsZiwgdGhlIEludGVybmV0IGlzIHN0YXJ0aW5nIHRvIGxvb2sgbGVz cyBsaWtlIGFuIGhvdXJnbGFzcyBhbmQgbW9yZSBsaWtlIGEgY29tcGxleCBjb25zdHJ1Y3Rp b24gcHJvamVjdCwgd2hlcmUgYW4gYXJteSBvZiBzdWJjb250cmFjdG9ycyBtdXN0IGJlIG1h cnNoYWxsZWQgZnJvbSBhIGRpdmVyc2UgbWFya2V0cGxhY2UgYW5kIGZvY3VzZWQgb24gYSBj b21tb24gZ29hbC4gIFdoYXQgaXMgbmVlZGVkIGlzIGEgcHJpbWUgY29udHJhY3Rvciwgd2hv IGNhbiBwcmVzZW50IGEgc2luZ2xlIGZhY2UgdG8gdGhlIGVuZCB1c2VyIGFuZCBzdWJjb250 cmFjdCBkYXRhIGRlbGl2ZXJ5IGNvbXBvbmVudHMgb24gdGhlIHVzZXKScyBiZWhhbGYuICBG dW5jdGlvbmFsbHksIHRoaXMgk3ByaW1lIGNvbnRyYWN0b3KUIGlzIGEgcG9saWN5IG1hbmFn ZXIsIGRlc2lnbmF0ZWQgYnkgdGhlIHVzZXIgdG8gcHJvdmlkZSBhIHZpcnR1YWwgcmVwbGFj ZW1lbnQgZm9yIHRoZSBuZWNrIG9mIHRoZSBJbnRlcm5ldCBob3VyZ2xhc3MuICANDUEgRGF0 YSBTZXNzaW9uIGFzIGEgQ29uc3RydWN0aW9uIENvbnRyYWN0DQ1JbiBvcmRlciBmb3IgTEFO IG1hbmFnZXJzLCBhY2Nlc3MgbmV0d29yayBwcm92aWRlcnMsIGVkZ2Ugc2VydmljZSBwcm92 aWRlcnMsIHdpZGUtYXJlYSBuZXR3b3JrcywgYW5kIGNvbnRlbnQgaG9zdGluZyBzeXN0ZW1z IHRvIHdvcmsgYXMgc3ViY29udHJhY3RvcnMgaW4gYnVpbGRpbmcgZGF0YSBkZWxpdmVyeSB0 byBhIFFvUyBzcGVjLCB0aGV5IHJlcXVpcmUgcG9saWN5IGNvbnRyb2wgdmVoaWNsZXMgKFBD VnMpIG9mIHRoZWlyIG93biB0aGF0IGNhbiBtYXAgdGhlaXIgUW9TIGltcGxlbWVudGF0aW9u cyB0byB0aGUgcGVyZm9ybWFuY2UgdGhleSBkZWxpdmVyLCBlLmcuIGluIHRlcm1zIG9mIGJh bmR3aWR0aCBhbmQgZGVsYXkgYXMgYSBmdW5jdGlvbiBvZiBwcmljZS4NDVRoZSB1c2VyknMg k3ByaW1lIGNvbnRyYWN0b3KUIG9wZXJhdGVzIHdoYXQgaXMsIGZvciB0aGF0IHVzZXIsIHRo ZSBwcmltYXJ5IHBvbGljeSBjb250cm9sIHZlaGljbGUgKFBQQ1YpLCB3aGljaCBpbnRlcmFj dHMgd2l0aCB0aGUgY29tcG9uZW50IHByb3ZpZGVyc5IgUENWcyB0byBtYWludGFpbiBuZXR3 b3JrIHN0YXRlIGluZm9ybWF0aW9uLCBwdXJjaGFzZSBzZXNzaW9uIGRlbGl2ZXJ5IGNvbXBv bmVudHMgb24gYSBwcm92aXNpb25lZCBiYXNpcyAod2l0aCBTTEFzKSwgYW5kIGV4Y2hhbmdl IHNpZ25hbGxpbmcgdG8gc2V0IHVwIHRyYW5zcG9ydCBzZWdtZW50cyB3aXRoIHNwZWNpZmll ZCBRb1MgaW4gcmVhbCB0aW1lLiAgVGhlIFBQQ1Ygd2lsbCBtYWludGFpbiBhIHVzZXIgcHJv ZmlsZSB3aXRoIHN0YXRpYyBpbmZvcm1hdGlvbiBvbiB0aGUgdXNlcpJzIGdlbmVyYWwgcHJl ZmVyZW5jZXMsIGF2YWlsYWJsZSBuZXR3b3JrIHNlZ21lbnQgcHJvdmlkZXJzLCBwcmVtaXNl IExBTiBjYXBhYmlsaXRpZXMsIGFuZCBhdmFpbGFibGUgYWNjZXNzIHNwZWVkIHVwc3RyZWFt IGFuZCBkb3duc3RyZWFtLiAgQXQgdGhlIHRpbWUgb2Ygc2Vzc2lvbiBlc3RhYmxpc2htZW50 LCB0aGUgUFBDViB3aWxsIGFsc28gbmVlZCB0byBrbm93IHRoZSBkZXNpcmVkIGFuZCBtaW5p bXVtIGFjY2VwdGFibGUgUW9TIHBhcmFtZXRlcnMgb2YgdGhlIHJlcXVlc3RlZCBkYXRhIHNl c3Npb24sIHRoZSBhY2NlcHRhYmxlIGNvc3QgbGltaXQsIGFuZCB0aGUgY2FwYWJpbGl0aWVz IG9mIHRoZSBhY2Nlc3MgZGV2aWNlIHRvIHdoaWNoIHRoZSBzZXNzaW9uIGlzIGJlaW5nIGVz dGFibGlzaGVkIChlLmcuIFBDLCBzZXQtdG9wIGJveCwgbW9iaWxlIHBob25lIG9yIFBEQSku ICBGaW5hbGx5LCBzb21lIGluZm9ybWF0aW9uIHdpbGwgYmUgbmVlZGVkIGFib3V0IHRoZSBy ZXF1aXJlbWVudHMgb2YgdGhlIGNvbnRlbnQgaXRzZWxmLCBwcm92aWRlZCBhcyBtZXRhZGF0 YSBieSB0aGUgY29udGVudCBwcm92aWRlciAoZS5nLiB2aWRlbyByZXF1aXJpbmcgYXQgbGVh c3QgNDAwIEticHMpLg0NV2hlbiB0aGUgdXNlciByZXF1ZXN0cyBhIHNlc3Npb24gYXQgYSBz cGVjaWZpZWQgc2VydmljZSBjbGFzcywgdGhlIFBQQ1YgaW50ZXJhY3RzIHdpdGggdGhlIGF2 YWlsYWJsZSCTc3ViY29udHJhY3RvcpQgUENWcyBpbiByZWFsIHRpbWUsIHF1aWNrbHkgYXJy aXZpbmcgYXQgb25lIG9mIHRoZSBmb2xsb3dpbmcgcmVzdWx0czoNDUEgZGF0YSBzZXNzaW9u IGlzIGVzdGFibGlzaGVkIGFjcm9zcyBzb21lIHNldCBvZiBuZXR3b3JrIHN1YmNvbnRyYWN0 b3JzLCBtZWV0aW5nIHRoZSBzZXNzaW9uIHNwZWNpZmljYXRpb25zIHdpdGhpbiBhY2NlcHRh YmxlIHRvbGVyYW5jZS4NSXQgaXMgZGV0ZXJtaW5lZCB0aGF0IG5vIHN1Y2ggc2Vzc2lvbiBj YW4gYmUgc2V0IHVwLCBhbmQgdGhlIHVzZXIgaXMgZ2l2ZW4gdGhlIGVxdWl2YWxlbnQgb2Yg YSBidXN5IHNpZ25hbC4NTm8gc2Vzc2lvbiBjYW4gYmUgc2V0IHVwIHRoYXQgbWVldHMgdGhl IHNwZWNzLCBidXQgYSBzZXQgb2YgIJNuZWFyLW1pc3OUIGFsdGVybmF0aXZlcyBhcmUgaWRl bnRpZmllZCBhbmQgcHJlc2VudGVkIHRvIHRoZSB1c2VyIGZvciBhIGRlY2lzaW9uLg0NSW4g dGhpcyBtb2RlbCwgdGhlIGRlbGl2ZXJ5IGNoYWluIHNlZ21lbnRzIHNob3duIGluIEZpZ3Vy ZSAyIG9wZXJhdGUgYXMgZm9sbG93czoNDQ1QcmVtaXNlIG5ldHdvcmsNTWFwcyBlYWNoIHNl c3Npb24gdG8gYSBRb1MgcmVxdWVzdCBpbiB0ZXJtcyBvZiBhIHN0YW5kYXJkLCBmaW5pdGUg c2V0IG9mIHNlcnZpY2UgY2xhc3NlcyAoUW9TIHBhY2thZ2VzKQ1JbnRlcmFjdHMgd2l0aCB0 aGUgUFBDVg1SZXF1ZXN0cyB0aGUgY2xhc3Mgb2Ygc2VydmljZSBmcm9tIFBQQ1YNUmVjZWl2 ZXMgZnJvbSB0aGUgUFBDViBlaXRoZXIgYSBjb25maXJtYXRpb24gb2YgdGhlIGNsYXNzIG9m IHNlcnZpY2Ugb3IgYSBtZXNzYWdlIHRoYXQgdGhlIG5lZWRlZCBjbGFzcyBvZiBzZXJ2aWNl IGlzIHVuYXZhaWxhYmxlLg1JZiB0aGUgcmVxdWVzdGVkIHNlcnZpY2UgY2xhc3MgaXMgdW5h dmFpbGFibGUsIHRoZSBQUENWIG1heSBvZmZlciBhIHNldCBvZiBhbHRlcm5hdGl2ZXM7IGku ZS4gbmVnb3RpYXRlIGEgZmVhc2libGUgc2VydmljZSBjb250cmFjdCB3aXRoIHRoZSBlbmQt dXNlci4gDVRoZSBwcmVtaXNlIG5ldHdvcmsgY29ubmVjdHMgZGlyZWN0bHkgdG8gYW4gQWNj ZXNzIE5vZGUgbG9jYXRlZCBpbiB0aGUgQWNjZXNzIE5ldHdvcmsNDUFjY2VzcyBOZXR3b3Jr DVdpdGhpbiB0aGUgQWNjZXNzIE5ldHdvcmssIEFjY2VzcyBOb2RlcyBwcm92aWRlIHRoZSBw aHlzaWNhbCBjb25uZWN0aW9uIHRvIHRoZSBjdXN0b21lciBwcmVtaXNlIG5ldHdvcmsuICBJ biB0aGUgYWNjZXNzIG5ldHdvcmssIGRhdGEgaXMgdHJhbnNwb3J0ZWQgdGhyb3VnaCBvbmUg b3IgbW9yZSBUcmFuc2l0IE5vZGVzLCB0byBhIFNlcnZpY2UgTm9kZSBsb2NhdGVkIGF0IGFu IEVkZ2UgQ2VudGVyLg1UaGUgYWNjZXNzIG5ldHdvcmsgaXMgcmVzcG9uc2libGUgZm9yIHRy YW5zcG9ydGluZyB0aGUgZGF0YSBmcm9tIHRoZSBBY2Nlc3MgTm9kZSB0byB0aGUgU2Vydmlj ZSBOb2RlLCB3aGlsZSBtZWV0aW5nIEFjY2VzcyBOZXR3b3JrIFFvUyByZXF1aXJlbWVudHMu DVRoZSBhY2Nlc3MgbmV0d29yayBtYXkgcHJvdmlkZSBwZXItc2Vzc2lvbiB0dW5uZWxsaW5n IGZyb20gdGhlIHByZW1pc2UgbmV0d29yayB0byB0aGUgU2VydmljZSBOb2RlLiAgVHVubmVs cyBpc29sYXRlIHRyYWZmaWMgZnJvbSBzZXNzaW9ucyB3aXRoIGRpZmZlcmVudCByZXF1aXJl bWVudHMgYW5kL29yIGZyb20gZGlmZmVyZW50IHVzZXJzLCBmb3IgUW9TIGVuZm9yY2VtZW50 IGFuZCBiaWxsaW5nIHB1cnBvc2VzLg1UdW5uZWxzIG1heSBiZSBhZ2dyZWdhdGVkIHVzaW5n IGVpdGhlciBUaW1lLURpdmlzaW9uLU11bHRpcGxleGluZyAoVERNKSBvciBRb1MgYXdhcmUg cGFja2V0L2NlbGwgbXVsdGlwbGV4aW5nLg1BIHNpbmdsZSBlbmQtdXNlciBtYXkgYmUgY29u bmVjdGVkIHRvIG11bHRpcGxlIGFjY2VzcyBuZXR3b3JrcyAoZS5nLiBBRFNMIGFuZCBEQlMp LCB3aGljaCBtYXkgaGF2ZSBkaWZmZXJlbnQgcHJvdmlkZXJzIGFuZCByZXF1aXJlIHRyYW5z cG9ydCB0byBkaWZmZXJlbnQgU2VydmljZSBOb2RlcyBwb3NzaWJseSBhdCBkaWZmZXJlbnQg RWRnZSBDZW50ZXJzLiAgVGhlIFBQQ1Ygd2lsbCBpZGVhbGx5IG9wdGltaXplIHRoZSB1c2Ug b2YgdGhlc2UgYWNjZXNzIG5ldHdvcmtzLCBiYXNlZCBvbiB0aGUgdXNlcpJzIHByb2ZpbGUu ICBBcHByb3ByaWF0ZSBzaWduYWxsaW5nIG1ldGhvZHMgd2lsbCBiZSByZXF1aXJlZCB0byBz ZXQgdXAgYW5kIGFja25vd2xlZGdlIHRoZSByZXF1aXJlZCBRb1MuDQ1FZGdlIGNlbnRlcg1U aGUgRWRnZSBDZW50ZXIgaXMgYSBTZXJ2aWNlIFBlZXJpbmcgUG9pbnQuICBTZXJ2aWNlIE5v ZGVzIGxvY2F0ZWQgYXQgdGhlIEVkZ2UgQ2VudGVyIHBlZXIgd2l0aCBzZXJ2aWNlIGRlbGl2 ZXJ5IGVudGl0aWVzIGluIHRoZSBBY2Nlc3MgTm9kZS4NVGhlIEVkZ2UgQ2VudGVyIGlzIGEg ZGF0YSBhZ2dyZWdhdGlvbiBwb2ludCB0aGF0IG1heSBzZXJ2ZSBtdWx0aXBsZSBhY2Nlc3Mg bmV0d29ya3MgYW5kIGhhdmUgY29ubmVjdGlvbnMgdG8gbXVsdGlwbGUgd2lkZS1hcmVhIG5l dHdvcmtzLg1Rb1MtcmVsYXRlZCBmdW5jdGlvbnMgdGhhdCBjYW4gYmUgcGVyZm9ybWVkIGF0 IHRoaXMgbmV0d29yayBjb21wb25lbnQgaW5jbHVkZSBpbnRlbGxpZ2VudCBzZXNzaW9uIGFn Z3JlZ2F0aW9uIGFuZCBmaWx0ZXJpbmcsIGxvYWQgYmFsYW5jaW5nLCBzZWxlY3Rpb24gb2Yg ZGF0YSBzb3VyY2UgYW1vbmcgbG9jYWwgY2FjaGVzLCBzZXJ2ZXJzLCBldGMuIGFuZCBtdWx0 aXBsZSBXQU5zLg1TZXJ2aWNlIE1hbmFnZW1lbnQgaW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9u LCBhdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIChBQUEpIGNhbiBiZSBjYXJyaWVkIG91 dCBhdCB0aGUgRWRnZSBDZW50ZXIuICANVGhlIEVkZ2UgQ2VudGVyIG1heSBhbHNvIHByb3Zp ZGUgdGhlIE5vcnRoIEJvdW5kIEludGVyZmFjZSB0byB0aGUgT3BlcmF0aW9ucyBTdXBwb3J0 IFN5c3RlbXMgKE9TUykgcmVxdWlyZWQgdG8gbWFuYWdlIHRoZSBBY2Nlc3MgTmV0d29yay4g DUEgU2VydmljZSBOb2RlIGF0IGFuIEVkZ2UgQ2VudGVyIG1heSBkaXN0cmlidXRlIGFuZCBy ZWFnZ3JlZ2F0ZSBkYXRhIGZvciBvbmUgb3IgbW9yZSB3aWRlIGFyZWEsIG1ldHJvIGNvcmUg b3Igc3BlY2lhbCBzZXJ2aWNlIG5ldHdvcmtzLiAgRm9yIGV4YW1wbGUgdGhlIFNlcnZpY2Ug Tm9kZSBtYXkgaW50ZXJmYWNlIHdpdGggdGhlIEludGVybmV0LCBwcml2YXRlIGludHJhbmV0 cyAoVlBOcyksIHRoZSBQU1ROIG5ldHdvcmssIEFUTSBuZXR3b3JrcyBhbmQgTVBMUyBuZXR3 b3Jrcy4NVGhlIFNlcnZpY2UgTm9kZSBhdCB0aGUgRWRnZSBDZW50ZXIgY2FuIHByb3ZpZGUg dHJhZmZpYyBlbmdpbmVlcmluZyBvZiBhZ2dyZWdhdGVzIHRvIG1lZXQgdGhlIEVuZC10by1F bmQgUW9TIG5lZWRzIGZvciB0aGUgY29tcG9uZW50IGZsb3dzLiAgTmVnb3RpYXRpb24gd2l0 aCB0aGUgV0FOIG1heSBiZSBhY2NvbXBsaXNoZWQgdXNpbmcgZWl0aGVyIHNpZ25hbGxpbmcg b3IgdGhlIG1hbmFnZW1lbnQgaW50ZXJmYWNlLg0NV2lkZS1hcmVhIG5ldHdvcmtzDU11bHRp cGxlIFdBTnMgYW5kIFdBTiBzZXJ2aWNlIGNvbnRyYWN0cyBtYXkgYmUgYXZhaWxhYmxlIGZv ciBkYXRhIGRlbGl2ZXJ5DVFvUyBpbXBsZW1lbnRhdGlvbnMgYXQgdGhpcyBsZXZlbCBpbmNs dWRlIHRoZSBzZWxlY3Rpb24gb2YgYSBzdGF0aWMgV0FOIGludGVyZmFjZSB3aXRoIGtub3du IFFvUyBjaGFyYWN0ZXJpc3RpY3MgYW5kIGxvYWRpbmcsIHNpZ25hbGxpbmcgdG8gV0FOcyB3 aXRoIGR5bmFtaWMgUW9TIGNhcGFiaWxpdGllcywgYW5kIHRoZSBpbXBsZW1lbnRhdGlvbiBv ZiBsb2FkIGxpbWl0cyBvbiBzcGVjaWZpYyBXQU4gY29ubmVjdGlvbnMuDVRoZSBJbnRlcm5l dCBpcyBvbmx5IG9uZSBvZiB0aGUgV0FOIG9wdGlvbnMuICBPdGhlciB0eXBlcyBvZiBkYXRh IG5ldHdvcmsgbWF5IGJlIGVtcGxveWVkLCBvciB0aGUgZGF0YSBjYW4gYmUgY2FycmllZCBv biBhIHByaXZhdGUgbGluZS4gIEluIHRoZSBzaW1wbGVzdCBjYXNlLCB0aGUgZGF0YSBpcyBh dmFpbGFibGUgZnJvbSBhIGxvY2FsIGNhY2hlIG9yIHNlcnZlciBhbmQgbm8gV0FOIGlzIGVt cGxveWVkLg0NUHJpbWFyeSBob3N0aW5nIHN5c3RlbQ1JbiBhIHRyYWRpdGlvbmFsIGhvc3Rp bmcgY29uZmlndXJhdGlvbiwgdHJhZmZpYyBpcyBsb2FkLWJhbGFuY2VkIGFtb25nIHNlcnZl cnMgd2l0aCBkaXJlY3RseSBhdHRhY2hlZCBzdG9yYWdlLg1JbiBhbiBpbnRlbGxpZ2VudCBz dG9yYWdlLWFyZWEgbmV0d29yayAoU0FOKSwgYSBwb29sIG9mIHN0b3JhZ2UgZGV2aWNlcyBp cyBpbnRlcmNvbm5lY3RlZCBvbiBhIGZhc3QgY29ubmVjdGlvbiBzeXN0ZW0sIGFuZCB0aGUg k3NlcnZlcnOUIGFyZSBzaW1wbGUgZGV2aWNlcyB0aGF0IHByb3ZpZGUgcG9ydCBjb25uZWN0 aW9ucyB0byB0aGUgc3lzdGVtLg1Cb3RoIGZvcm1zIG9mIHByaW1hcnkgc3RvcmFnZSBjb3Vs ZCBiZSBlaXRoZXIgY2VudHJhbGl6ZWQgaW4gYSBzaW5nbGUgZGF0YSBjZW50ZXIgb3IgbWFp bnRhaW4gbWlycm9yZWQgY29waWVzIG9mIHRoZSBkYXRhIGF0IG11bHRpcGxlIGdlb2dyYXBo aWMgbG9jYXRpb25zLCBvbiBtdWx0aXBsZSBXQU5zIChvciwgaW4gc29tZSBjYXNlcywgYXQg ZWRnZSBjZW50ZXJzKS4NDVRoZSByZWxhdGlvbnNoaXAgb2YgdGhlc2UgZGVsaXZlcnkgY2hh aW4gc2VnbWVudHMgdG8gdGhlIFBQQ1YgaXMgc2hvd24gaW4gRmlndXJlIDkuDQ0NDQ0NDVdo YXQgU3RhbmRhcmRzIEFyZSBOZWVkZWQgdG8gRW5hYmxlIFRoaXMgTW9kZWw/DVNlcnZpY2Ug Y2xhc3MgZGVmaW5pdGlvbnMgYW5kIHNwZWNpZmljYXRpb24gcHJvdG9jb2wNDUl0IHdvdWxk IGJlIGluZmVhc2libGUgdG8gbWFuYWdlIHRoZSBwcm9jZXNzIGRlc2NyaWJlZCBhYm92ZSB3 aXRoIGFuIGluZmluaXRlIHJhbmdlIG9mIFFvUyBwYXJhbWV0ZXJzLCBzbyB0aGVyZSBpcyBj bGVhcmx5IGEgbmVlZCBmb3IgYSBmaW5pdGUgc2V0IG9mIHN0YW5kYXJkIHNlcnZpY2UgY2xh c3Nlcywgb3IgUW9TIHBhcmFtZXRlciBwYWNrYWdlcywgZm9yIHRoZSBQUENWIHRvIGNvbnN0 cnVjdC4gIFRoZSBlbmQgdXNlciAob3IgdGhlIGVuZCB1c2VyknMgc29mdHdhcmUpIHNob3Vs ZCBiZSByZXNwb25zaWJsZSBmb3Igc2VsZWN0aW5nIHRoZSBzZXJ2aWNlIGNsYXNzIHJlcXVl c3QsIGUuZy4gYmFzZWQgb24gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgYXBwbGljYXRp b24gYW5kIGEgcHJlZmVyZW5jZSBwcm9maWxlLiAgVGhlIHJlcXVlc3Qgc2hvdWxkIHNwZWNp ZnkgYSBkZXNpcmVkIGFuZCBtaW5pbXVtLWFjY2VwdGFibGUgc2VydmljZSBjbGFzcywgc28g dGhhdCB0aGUgUFBDViBjYW4gcnVuIGEgY29uc2lzdGVuY3kgY2hlY2sgb2YgdGhlIHJlcXVl c3QgYWdhaW5zdCBhdmFpbGFibGUgbmV0d29yayBpbmZvcm1hdGlvbiBhbmQgdGhlIGNvbnRl bnQgbWV0YWRhdGEsIHRvIHJlc29sdmUgdGhlIHNlcnZpY2UgY2xhc3MgcmVxdWVzdCB0byBh IGZlYXNpYmxlIGFsdGVybmF0aXZlIG9yIGVsc2UgcmVwb3J0IGNvbm5lY3Rpb24gZmFpbHVy ZSB0byB0aGUgdXNlci4NDVBhcmFtZXRlcnMgc3BlY2lmaWVkIGJ5IHRoZSBzdGFuZGFyZCBl bmQtdG8tZW5kIHNlcnZpY2UgY2xhc3NlcyAoaS5lLiB0aGUgc3BlY2lmaWNhdGlvbnMgcHJv dmlkZWQgYnkgdGhlIGVuZC11c2VyIHdoZW4gc3Vic2NyaWJpbmcgdG8gYW4gU0xBIG9yIHNp Z25hbGxpbmcgZm9yIGEgc2Vzc2lvbiBpbiByZWFsIHRpbWUpIG1heSBpbmNsdWRlIGFueSBv ZiB0aGUgZm9sbG93aW5nOg0NQmFuZHdpZHRoDUNvbW1pdHRlZCBtaW5pbXVtIGJhbmR3aWR0 aA1BbGxvd2FibGUgYnVyc3QgcmF0ZQ1EZWxheSBDaGFyYWN0ZXJpc3RpY3MNTWF4aW11bSBz ZXQtdXAgdGltZQ1NYXhpbXVtIGRlbGF5DU1heGltdW0gZGVsYXkgdmFyaWFuY2UNUHJpb3Jp dHkNW1N0YW5kYXJkIHNldCBvZiBwcmlvcml0eSBsZXZlbHNdDQ1Qb2xpY3kgQ29udHJvbCBW ZWhpY2xlIHN0YW5kYXJkcyBmb3IgZWFjaCBkYXRhIGRlbGl2ZXJ5IHNlZ21lbnQNDVRoZSBQ Q1YgZm9yIGVhY2ggc2VnbWVudCBtdXN0IHByb3ZpZGU6DQ1NZWNoYW5pc21zIHRvIGVzdGFi bGlzaCBRb1MgbWFuYWdlZCBwYXRocyB3aXRoaW4gdGhlIGRvbWFpbg0NTWVjaGFuaXNtcyB0 byBleGNoYW5nZSBwYXRoIGluZm9ybWF0aW9uIHdpdGggb3RoZXJzIG91dHNpZGUgdGhlIGRv bWFpbiAob3RoZXIgbmV0d29ya3Mgb3Igb3RoZXIgk3Nlc3Npb24gb3duZXJzlCkNSWYgcmVh bC10aW1lLCB2aWEgYSBzaWduYWxsaW5nIHByb3RvY29sIHRoYXQgc3VwcG9ydHMgc2Vzc2lv biBzZXQtdXAsIGFja25vd2xlZGdlbWVudCwgYW5kIHRha2UtZG93bg0NQSBtZWFzdXJlbWVu dCBtZXRob2QgdG8gdmFsaWRhdGUgdGhhdCB0aGUgY29tbWl0dGVkIFFvUyBpcyBkZWxpdmVy ZWQuDVJlcXVpcmVkIGZvciBTTEFzDURlc2lyYWJsZSBhdCB0aGUgc2Vzc2lvbiBsZXZlbA0N U2Vzc2lvbiBkZXRhaWwgYWNjb3VudGluZywgdG8gc3VwcG9ydCBiaWxsaW5nIGFuZCBzZXR0 bGVtZW50cw1EZXNpcmFibGUgdG8gaGF2ZSBhbiBhdWRpdGluZyBtZWNoYW5pc20gdG8gbWFr ZSBiaWxsaW5nIG5vbi1yZWZ1dGFibGUNDVRoZSBQUENWIGFsc28gcmVxdWlyZXMgc3RhbmRh cmQgcHJvdG9jb2xzIGZvciBpbnRlcmFjdGlvbiB3aXRoIHRoZSBlbmQtdXNlciBhbmQgdmFs aWRhdGlvbiBvZiBlbmQtdG8tZW5kIFFvUyBjb21taXRtZW50cy4NDVNvbWUgSW1wbGVtZW50 YXRpb24gSXNzdWVzDUhvdyBjYW4gd2Ugc2lnbmFsIGJhbmR3aWR0aCByZXF1ZXN0cyBpbiBh biBJUCBuZXR3b3JrPw1UaGUgUlNWUCBhbmQgKGV4KSBpbnRzZXJ2IFdHIGluIHRoZSBJRVRG IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHJlc2VydmluZyBiYW5kd2lkdGggZm9yIGEgZ2l2 ZW4gSVAgZmxvdy4gRHVyaW5nIGZsb3cgc2V0dXAsIHRoZSBiYW5kd2lkdGggcmVxdWlyZW1l bnRzIGFyZSBzaWduYWxlZCBhbmQgZWFjaCBpbnRlcnZlbmluZyBub2RlIHJlc2VydmVzIHN1 ZmZpY2llbnQgcmVzb3VyY2VzIGluIG9yZGVyIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50Lg0N SG93IGRvIG5vbi1JUCBkZXZpY2VzIChlZyBEU0xBTXMpIGtub3cgaG93IG11Y2ggYmFuZHdp ZHRoIHRvIHJlc2VydmU/DUFsbCBvZiB0aGUgYWJvdmUgZGVzY3JpYmVzIGFuIGVuZC10by1l bmQgcmVzZXJ2YXRpb24gc29sdXRpb24sIGJ1dCB0eXBpY2FsbHkgdGhlIHN1YnNjcmliZXIg J2VuZCcgaXMgbm90IHRoZSBzdWJzY3JpYmVyIFBDIGJ1dCB0aGUgYWNjZXNzIG5vZGUgdG8g d2hpY2ggaGUgaXMgY29ubmVjdGVkLiBUaHVzIHdlIG5lZWQgc29tZSB3YXkgb2YgcmVzZXJ2 aW5nIGJhbmR3aWR0aCBpbiB0aGUgJ2xhc3QgbWlsZScgdG8gdGhlIHN1YnNjcmliZXIuIFR5 cGljYWxseSB0aGlzIG1lYW5zIGNvbnRyb2xsaW5nIGJhbmR3aWR0aCBpbiBhIERTTEFNIG9y IENNIEhlYWQtRW5kLCBhbmQgcG90ZW50aWFsbHkgbWFuYWdpbmcgY29udGVudGlvbiBiZXR3 ZWVuIGRldmljZXMgb24gc2hhcmVkIG1lZGlhLCBzdWNoIGFzIGEgY2FibGUgbW9kZW0gb3Ig ZXRoZXJuZXQgaW5mcmFzdHJ1Y3R1cmUuIEluIHRoZSBmb3JtZXIgY2FzZSBRb1MgbWVjaGFu aXNtcyBhcmUgb2Z0ZW4gYXZhaWxhYmxlLCBidXQgdGhleSBuZWVkIHRvIGJlIGR5bmFtaWNh bGx5IGNvbnRyb2xsZWQgYXMgZGVzY3JpYmVkIGFib3ZlIGZvciB0aGUgb3RoZXIgY29tcG9u ZW50cy4gSW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgc29sdXRpb24gbWF5IGJlIHRvIHVzZSB1 cC1zdHJlYW0gc2hhcGluZyB0byBjb250cm9sIHBhY2tldCBhZ2dyZWdhdGlvbiBvciB0byBs aW1pdCB0aGUgdXNlIG9mIHNoYXJlZCBzZWdtZW50cy4gVXAtc3RyZWFtIGFkbWlzc2lvbiBj b250cm9sIGFuZCBzaGFwaW5nIG1heSBiZSBzdWZmaWNpZW50IHRvIHNlZ3JlZ2F0ZSB0cmFm ZmljIGluIHNvbWUgY2FzZXM7IGluIG90aGVyIGNhc2VzLCBsaW1pdGluZyBjb250ZW50aW9u IGFuZCBvdmVyIHByb3Zpc2lvbmluZyBvZiBiYW5kd2lkdGggbWF5IHRoZSBvbmx5IHNvbHV0 aW9uLg0NV2hhdCBkbyB3ZSBkbyBpZiB0aGUgYmFuZHdpZHRoIHJlcXVlc3QgY2Fubm90IGJl IHNhdGlzZmllZD8NICBJZiB0aGVyZSBpcyBubyBzdWl0YWJsZSBwYXRoIHRocm91Z2ggdGhl IG5ldHdvcmsgdGhhdCBjYW4gc2F0aXNmeSB0aGUgYmFuZHdpZHRoIHJlcXVlc3QsIHRoZW4g dGhlIG9yaWdpbmF0aW5nIGRldmljZSB3aWxsIGJlIHVuYWJsZSB0byBjb21wbGV0ZSB0aGUg cmVzZXJ2YXRpb24gcmVxdWVzdC4gSW4gYSBjb250ZW50IGRlbGl2ZXJ5IHNjZW5hcmlvLCB0 aGlzIGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIGNvbW11bmljYXRlZCB0byB0aGUgdXNlciwg YW5kIGEgZGVjaXNpb24gbWFkZSBhYm91dCBob3cgdG8gcHJvY2VlZC4gT3B0aW9ucyBtYXkg YmUgdG8gY2FuY2VsIHRoZSBhdHRlbXB0LCBvciB0byBhY2NlcHQgYSBsb3dlci1ncmFkZSBj b3B5IG9mIHRoZSBjb250ZW50IHRoYXQgaGFzIGxvd2VyIGJhbmR3aWR0aCByZXF1aXJlbWVu dHMuIFRoaXMgbmVjZXNzaXRhdGVzIHNvbWUgaW50ZWxsaWdlbmNlIGluIHRoZSBvcmlnaW5h dGluZyBkZXZpY2UgdG8ga25vdyB3aGF0IGFsdGVybmF0aXZlcyBhcmUgYXZhaWxhYmxlIGFu ZCB0byBjb21tdW5pY2F0ZSB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSB1c2VyLiANV2hhdCBp ZiBzdWJzY3JpYmVyIG5lZWRzIHRvIGNoYW5nZSBoaXMgc3Vic2NyaXB0aW9uIGZvciB0aGlz IHNlc3Npb24/DUluIHNvbWUgY2FzZXMsIHRoZSBzdWJzY3JpYmVyIG1heSBoYXZlIGEgYmFu ZHdpZHRoIGNvbnRyYWN0IHdpdGggaGlzL2hlciBBY2Nlc3MgUHJvdmlkZXIgdGhhdCBjYW5u b3Qgc3VwcG9ydCBkZWxpdmVyeSBvZiB0aGUgY29udGVudCB3aXRoIGFwcHJvcHJpYXRlIFFv Uy4gSW4gdGhpcyBjYXNlLCB0aGUgY2xpZW50IHNob3VsZCBiZSBpbmZvcm1lZCBvZiB0aGlz IGFuZCBvbmUgb2YgdGhlIGZvbGxvd2luZyBtYXkgaGFwcGVuOg0NMS4gVGhlIHN1YnNjcmli ZXIgYWJvcnRzIHRoZSBkb3dubG9hZA0yLiBUaGUgc3Vic2NyaWJlciB0ZW1wb3JhcmlseSBv ciBwZXJtYW5lbnRseSBpbmNyZWFzZXMgaGlzIGNvbnRyYWN0IHdpdGggdGhlIGFjY2VzcyBw cm92aWRlcg0zLiBUaGUgc3Vic2NyaWJlciBhY2NlcHRzIGEgbG93ZXIgZ3JhZGUgdmVyc2lv biBvZiB0aGUgY29udGVudA00LiBFaXRoZXIgb2YgICgyKSBvciAoMykgaGFwcGVucyBhdXRv bWF0aWNhbGx5Lg0NSW4gYW55IGNhc2UsIHRoZXJlIGlzIGFnYWluIGEgcmVxdWlyZW1lbnQg dG8gaGF2ZSBzb21lIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgYmFuZHdpZHRoIHJlc2Vy dmF0aW9uIGVuZHBvaW50IGFuZCB0aGUgdXNlciBhbmQgaXQgaXMgZXhwZWN0ZWQgdGhhdCB0 aGlzIHdvdWxkIGJlIHZpYSBhbiBpbnRlbGxpZ2VudCBhY2Nlc3MgY29uY2VudHJhdG9yLg0M CAgICAgMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgMCAgICAgMCAgICAwI CAgIDAgICAgMCAgICAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgI DQIgIEl0IGlzIG5vdCB1bnVzdWFsIGZvciBwcml2YXRlIG5ldHdvcmtzIHRoYXQgYXJlIGRl c2lnbmVkIHdpdGggYSBnb29kIG1hcmdpbiBmb3IgcGVhayB0cmFmZmljIGxvYWRzIHRvIG9w ZXJhdGUgYXQgYW4gYXZlcmFnZSBvY2N1cGFuY3kgYXJvdW5kIDUlLg0NQkNEIEZvcnVtIElu ZnJhc3RydWN0dXJlIFdvcmtpbmcgR3JvdXAgZHJhZnQgZG9jdW1lbnQgliAxOSBGZWJydWFy eSAyMDAxDQ0NRmlndXJlIDINDUtub3dsZWRnZSBvZiBzZXNzaW9uIHJlcXVpcmVtZW50cyBp cyBvbmx5IGd1YXJhbnRlZWQgdG8gYmUgYXZhaWxhYmxlIGF0IHRoZSB1c2VyIGRldmljZSAm IHByaW1hcnkgaG9zdC4NDUNvbG9yIEtleToNIHBvc3NpYmxlIGNvbnRlbnRpb24NIG1hbmFn ZWQgY29udGVudGlvbg0gdHlwaWNhbGx5IHVubWFuYWdlZCBjb250ZW50aW9uDQ1XaWRlLUFy ZWEgTmV0d29yayAmIEhvc3RpbmcNDVByZW1pc2UgTmV0d29yaw0NQWNjZXNzIE5ldHdvcmsN DUVkZ2UgQ2VudGVyDQ1Mb2NhbCBDb250ZW50IFNlcnZlcg0NSW50ZXJuZXQNDVByaW1hcnkg Q29udGVudC9TZXJ2aWNlIEhvc3RpbmcNDVNlc3Npb24gQWdncmVnYXRvcg0NVHJ1bmsvTUFO DQ1BY2Nlc3MgQ29uY2VudHJhdGlvbiBOb2RlDQ1BY2Nlc3MgTWVkaXVtDQ1JQUQNDUhvbWUv T2ZmaWNlIExBTg0NVXNlciBEZXZpY2UNDURlbGl2ZXJ5IENoYWluDQ0qIE5vdGU6ICBPdmVy LWNhcGFjaXR5IGlzIGEgdW5pdmVyc2FsIJNRb1Mgb3B0aW9ulCB0aGF0IGlzIGltcGxpY2l0 IGluIHRoaXMgYW5kIHRoZSBmb2xsb3dpbmcgdGFibGVzLg0NS2V5IGlzc3VlczoNbWFwcGlu ZyBhcHBsaWNhdGlvbnMgdG8gYXBwcm9wcmlhdGUgUW9TDW1hcHBpbmcgUW9TIHRvIHByZW1p c2UgdHJhbnNwb3J0IGNvbnRyb2wNbWFwcGluZyBiZXR3ZWVuIHByZW1pc2UgUW9TIGNvbnRy b2wgYW5kIFdBTiBRb1MgY29udHJvbA0NQ29uZmlndXJhdGlvbg0NQ29udGVudGlvbg0NUW9T IE9wdGlvbnMqDQ1Db250cm9sIEluZm8gQXQNDVN0YXINDUNvbmN1cnJlbnQgcHJvY2Vzc2Vz IGZyb20gZGV2aWNlDQ1JUCBwb3J0IG1hcHBpbmcsIFZMQU4sIEFUTSwgSVAgUW9TIChlLmcu IERpZmZTZXJ2LCBNUExTKQ0NRW5kIGRldmljZSAmIElBRA0NTEFODQ1NdWx0aXBsZSBkZXZp Y2VzDQ1MQU4gcHJpb3JpdHk7IElQIHBvcnQgbWFwcGluZywgVkxBTiwgSVAgUW9TLCBvciBB VE0gYXQgSUFEDQ1FbmQgZGV2aWNlLCBMQU4gY29udHJvbGxlciwgJiBJQUQNDVByZW1pc2Ug TmV0d29yaw0NRmlndXJlIDMNDUZpZ3VyZSA0DQ1LZXkgaXNzdWU6DUNvbW11bmljYXRpbmcg UW9TIGNvbnRyb2wgdG8gYWNjZXNzIGNvbmNlbnRyYXRpb24gbm9kZSBvciBkYXRhIHN3aXRj aA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1BY2Nlc3MgTmV0d29yaw0NRmlndXJlIDUNDUtleSBp c3N1ZXM6DUNvbW11bmljYXRpbmcgUW9TIGNvbnRyb2wgdG8gYWdncmVnYXRpb24gZGV2aWNl DU1hcHBpbmcgZGlmZmVyZW50IFFvUyBtZWNoYW5pc21zIGFtb25nIGFjY2VzcyBuZXR3b3Jr cyBhbmQgV0FOcw0NQ29uZmlndXJhdGlvbg0NQ29udGVudGlvbg0NUW9TIE9wdGlvbnMNDUNv bnRyb2wgSW5mbyBBdA0NU2ltcGxlIGRhdGEgY29uY2VudHJhdG9yDQ1EYXRhIGNvbmNlbnRy YXRvciAmIEludGVybmV0IHRydW5rcw0NUW9TIG1lY2hhbmlzbXMgaW4gY29uY2VudHJhdG9y IChlLmcuIE1QTFMpDQ1EYXRhIGNvbmNlbnRyYXRvcg0NU2Vzc2lvbiBhZ2dyZWdhdG9yIHdp dGggbG9jYWwgcmVzb3VyY2VzIChlLmcuIENETnMpDQ1TZXNzaW9uIGFnZ3JlZ2F0b3I7IGxv Y2FsIHNlcnZlcnM7IHBvcnRzIHRvIEludGVybmV0DQ1TZXNzaW9uIGFnZ3JlZ2F0b3IgbWVj aGFuaXNtczsgQ0ROIG1hbmFnZW1lbnQ7IGNvbnRlbnQgcGVlcmluZyBwcm90b2NvbHMNDVNl c3Npb24gYWdncmVnYXRvciAmIENETnMNDURhdGEgc3dpdGNoIG9yIHNlc3Npb24gYWdncmVn YXRvciB3aXRoIG1hbmFnZWQgV0FOcw0NU3dpdGNoIG9yIHNlc3Npb24gYWdncmVnYXRvcjsg V0FODQ1Rb1MgbWVjaGFuaXNtcyBpbiBjb25jZW50cmF0b3Igb3Igc2Vzc2lvbiBhZ2dyZWdh dG9yOyBXQU4gc2VsZWN0aW9uICYgbWd0Lg0NU3dpdGNoIG9yIHNlc3Npb24gYWdncmVnYXRv cg0NRWRnZSBDZW50ZXINDUZpZ3VyZSA2DQ1LZXkgaXNzdWU6DUNvb3JkaW5hdGlvbiBvZiBR b1MgbWFuYWdlbWVudCBhbW9uZyBtdWx0aXBsZSBuZXR3b3JrcyB3aGljaCBtYXkgdXNlIGRp ZmZlcmVudCBzdGFuZGFyZHMNDUNvbmZpZ3VyYXRpb24NDUNvbnRlbnRpb24NDVFvUyBPcHRp b25zDQ1Db250cm9sIEluZm8gQXQNDUludGVybmV0IJYgc2luZ2xlIGJhY2tib25lIGNhcnJp ZXINDUJhY2tib25lIG5ldHdvcmsNDUlQIFFvUzsgY2FjaGluZyBvciBtaXJyb3JpbmcgYXQg YmFja2JvbmUgbm9kZXMNDUJhY2tib25lIGNhcnJpZXI7IGFmZmlsaWF0ZWQgb3IgY29sbG9j YXRlZCBob3N0aW5nIGNlbnRlcnMgJiBDRE5zDQ1JbnRlcm5ldCCWIG11bHRpcGxlIGJhY2ti b25lIGNhcnJpZXJzDQ1CYWNrYm9uZSAgbmV0d29ya3M7IGV4Y2hhbmdlIHBvaW50cw0NQ29v cmRpbmF0ZWQgSVAgUW9TIG1lY2hhbmlzbXMgYW1vbmcgY2FycmllcnMgJiBleGNoYW5nZSBw b2ludHM7IHNlcnZlciByZXBsaWNhdGlvbiAmIENETnMNDU11bHRpcGxlIGNhcnJpZXJzOyBl eGNoYW5nZSBwb2ludHM7IGRpc3RyaWJ1dGVkIGhvc3Rpbmcgc2VydmljZXM7IENETnMNDUV4 dHJhbmV0DQ1FeHRyYW5ldCBmYWNpbGl0aWVzDQ1BbnkgY29tYmluYXRpb24gb2YgbGF5ZXIg MyBRb1MgbWVjaGFuaXNtcyAmIHNlcnZlciByZXBsaWNhdGlvbiBpbiBiYWNrYm9uZQ0NRXh0 cmFuZXQgY2FycmllcjsgYWZmaWxpYXRlZCBvciBjb2xsb2NhdGVkIGhvc3RpbmcgY2VudGVy cyAmIENETnMNDVdpZGUtQXJlYSBOZXR3b3Jrcw0NRmlndXJlIDcNDUtleSBpc3N1ZXM6DVF1 ZXJ5aW5nIGhvc3QgZGF0YSBmb3IgY29udGVudC1kcml2ZW4gUW9TIHJlcXVpcmVtZW50cw1Q cm92aWRpbmcgUW9TIGNvbnRyb2wgc2lnbmFsaW5nIHRvIGhvc3Rpbmcgc3lzdGVtDQ1Db25m aWd1cmF0aW9uDQ1Db250ZW50aW9uDQ1Rb1MgT3B0aW9ucw0NQ29udHJvbCBJbmZvIEF0DQ1T ZXJ2ZXIgRmFybQ0NTG9hZCBiYWxhbmNlciAoZS5nLiBMNCBzd2l0Y2gpOyBzZXJ2ZXIgcG9y dHMsIHNlcnZlcnM7IGF0dGFjaGVkIHN0b3JhZ2UNDVNlcnZlciByZXBsaWNhdGlvbiBvciBy ZXZlcnNlIHByb3h5IGNhY2hlcyAoY2VudHJhbCBvciBkaXN0cmlidXRlZCkNDUxvYWQgYmFs YW5jZXINDUludGVsbGlnZW50IFN0b3JhZ2UtQXJlYSBOZXR3b3JrDQ1TQU4gY29udHJvbCBz eXN0ZW0sIGNvbm5lY3Rpb24gbmV0d29yayhzKSwgYW5kIHN0b3JhZ2UgZGV2aWNlcw0NRXhw YW5zaW9uIGFuZC9vciBkaXN0cmlidXRpb24gb2YgU0FODQ1TQU4gY29udHJvbCBzeXN0ZW0N DUhvc3RpbmcgU3lzdGVtDQ1GaWd1cmUgOA0NV2lkZS1BcmVhIE5ldHdvcmsgJiBIb3N0aW5n DQ1Fc3RhYmxpc2ggcmVxdWlyZWQgUW9TIGFjcm9zcyBleHRyYW5ldCwgIHNpbmdsZS1jYXJy aWVyIGJhY2tib25lLCBvciBtdWx0aXBsZSBjYXJyaWVycyAmIGV4Y2hhbmdlIHBvaW50czsg bWFuYWdlIFFvUyBjYXBhYmlsaXRpZXMgb2YgaG9zdGluZyBzeXN0ZW0NDVRyYWNrIFFvUyBm b3IgZWFjaCBzZXNzaW9uOyBwZXJzb25hbGl6ZSBRb1MgY29udHJvbCBmb3IgZWFjaCB1c2Vy knMgYWNjZXNzIG5ldHdvcms7IHNlbGVjdCBXQU4gJiBXQU4gUW9TDQ1Qcm92aWRlIFFvUyBh dCBhY2Nlc3MgY29uY2VudHJhdGlvbiBub2RlOyBjb29yZGluYXRlIHdpdGggIGVkZ2UgY2Vu dGVyIG9yIHByZW1pc2UgbmV0d29yaw0NTWFwIGFwcGxpY2F0aW9ucyB0byBRb1M7IGNvbW11 bmljYXRlIHJlcXVpcmVtZW50cywgYnkgc2Vzc2lvbiwgdG8gdXBzdHJlYW0gZWxlbWVudHMu DQ1QcmVtaXNlIE5ldHdvcmsNDUFjY2VzcyBOZXR3b3JrDQ1FZGdlIENlbnRlcg0NTG9jYWwg Q29udGVudCBTZXJ2ZXINDUludGVybmV0DQ1QcmltYXJ5IENvbnRlbnQvU2VydmljZSBIb3N0 aW5nDQ1TZXNzaW9uIEFnZ3JlZ2F0b3INDVRydW5rL01BTg0NQWNjZXNzIENvbmNlbnRyYXRp b24gTm9kZQ0NQWNjZXNzIE1lZGl1bQ0NSUFEDQ1Ib21lL09mZmljZSBMQU4NDVVzZXIgRGV2 aWNlDQ1LZXkgSXNzdWVzIGFsb25nIHRoZSBDaGFpbg0NRmlndXJlIDkNDUNvbmZpZ3VyYXRp b24NDUNvbnRlbnRpb24NDVFvUyBPcHRpb25zDQ1Db250cm9sIEluZm8gQXQNDUNhYmxlIE1v ZGVtDQ1NdWx0aXBsZSB1c2VycyBvbiBjYWJsZSBzZWdtZW50DQ1ET0NTSVMgMS4xIGZvciBj dXJyZW50IHN5c3RlbXM7IDgwMi4xLCBJUCBRb1MsIEFUTSBwb3NzaWJsZQ0NUHJlbWlzZSBu ZXR3b3JrICYgYWNjZXNzIGNvbmNlbnRyYXRpb24gbm9kZQ0NeERTTA0NTXVsdGlwbGUgbGlu ZXMgb24gYWNjZXNzIGNvbmNlbnRyYXRpb24gbm9kZQ0NQVRNIGZvciBjdXJyZW50IHN5c3Rl bXM7IDgwMi4xIG9yIElQIFFvUyBwb3NzaWJsZQ0NUHJlbWlzZSBuZXR3b3JrICYgYWNjZXNz IGNvbmNlbnRyYXRpb24gbm9kZQ0NRml4ZWQgV2lyZWxlc3MNDU11bHRpcGxlIHVzZXJzIGlu IGNlbGwNDURPQ1NJUyAxLjE7IDgwMi4xOyBJUCBRb1MNDVRhYmxlIDENDVByZW1pc2UgbmV0 d29yaw1FdGhlcm5ldCAoQ2F0ZWdvcnkgNSBvciBIUE5BKQ1XaXJlbGVzcyBMQU4NQWNjZXNz IG5ldHdvcmsNSEZDOyBjb25jZW50cmF0aW9uIGF0IGZpYmVyIGFjY2VzcyBub2RlDXhEU0w7 IGNvbmNlbnRyYXRpb24gYXQgRFNMQU0NRml4ZWQgd2lyZWxlc3M7IGNvbmNlbnRyYXRpb24g YXQgdG93ZXINRlRUQy9IOyBjb25jZW50cmF0aW9uIGF0IGRhdGEgc3dpdGNoDUVkZ2UgY2Vu dGVyDUNhYmxlIGhlYWRlbmQgd2l0aCBsb2NhbCBjYWNoZXMgJiBzZXJ2ZXJzDU11bHRpc2Vy dmljZSBzZXNzaW9uIGFnZ3JlZ2F0b3Igd2l0aCBsb2NhbCBjYWNoZXMgJiBzZXJ2ZXJzIGFu ZCBtdWx0aXBsZSBXQU4gY29ubmVjdGlvbnMNU2ltcGxlIGRhdGEgYWdncmVnYXRpb247IGUu Zy4gd2l0aCBhbiBBVE0gc3dpdGNoDVdBTg1JbnRlcm5ldCAob25lIG9yIG1vcmUgYmFja2Jv bmUgY2FycmllcnMpDURpcmVjdCBjb25uZWN0aW9uIG9yIG1hbmFnZWQgZXh0cmFuZXQNUHJp bWFyeSBkYXRhIHNvdXJjZSBtYXkgb3IgbWF5IG5vdCBiZSBkaXN0cmlidXRlZA0NRXhhbXBs ZXMgb2YgTmV0d29yayBFbGVtZW50cw0NRmlndXJlIDENDVVuaXZlcnNhbCB0cmFuc3BvcnQg d2l0aCBhIGZsZXhpYmxlIGludGVyZmFjZSCWIElQIJYgdGhhdCBpcyBrZXB0IHNpbXBsZSBi eSBsaW1pdGluZyBpdHMgZmVhdHVyZXMgdG8gcHVyZSB0cmFuc3BvcnQgDQ1NYW55IGRpZmZl cmVudCB0eXBlcyBvZiBjbGllbnQgZGV2aWNlcywgZWFjaCBlcXVpcHBlZCB0byBkZWFsIHdp dGggYW55IHNwZWNpYWxpemVkIHNlcnZpY2VzIGl0IHJlcXVpcmVzDQ1NYW55IGRpZmZlcmVu dCB0eXBlcyBvZiBob3N0IGNvbXB1dGVycywgZGF0YSBzb3VyY2VzLCBhcHBsaWNhdGlvbnMs IGFuZCBzZXJ2aWNlcywgZWFjaCB3aXRoIGl0cyBvd24gY3VzdG9tIGZlYXR1cmVzDQ1JbnRl cm5ldA0Nk0hvdXJnbGFzc5QgbW9kZWwgb2YgdGhlIEludGVybmV0DQ1QcmVtaXNlIG5ldHdv cmsgJiBhY2Nlc3MgY29uY2VudHJhdGlvbiBub2RlDQ1GVFRDL0ggd2l0aCBkYXRhIHN3aXRj aA0NQXQgZGF0YSBzd2l0Y2ggYW5kIGl0cyB0cnVua3MNDTgwMi4xOyBBVE07IElQIFFvUzsg cHJvcHJpZXRhcnkgcHJvdG9jb2xzDQ1QcmVtaXNlIG5ldHdvcmsgJiBkYXRhIHN3aXRjaA0N DQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAADZFQAA2hUAAKMwAACkMAAA 1TMAANYzAADYNgAA2TYAAIE4AACCOAAAujkAALs5AADpYQAAJWIAACZiAACXYgAAQ2MAAERj AAB2YwAAs2MAABBvAAAVbwAAFm8AADVvAAA2bwAAOW8AADpvAAA/bwAAQG8AAERvAABFbwAA SW8AAEpvAABObwAAT28AAFNvAABUbwAAeW8AAHpvAAB8bwAAfW8AAH5vAAAScAAASnAAAFpw AABbcAAAXXAAAGZwAABncAAAz3AAANBwAADacAAA8HAAAARxAAAkcQAAJXEAAAD4APQA9AD0 APQA9ADyAPIA8ADyAOMA4wDjAOMA4wDjAOMA4wDjAOMA+ADh2+EAzQC+AK+mnZQAAAAAAAAA AAAAAAAAEUIqBkNKKABhSigAcGj/AAAAEUIqAkNKKABhSigAcGgzM8wAEUIqAUNKKABhSigA cGgAAAAAHTUIgTYIgUIqAUNKKABcCIFdCIFhSigAcGgAAAAAHTUIgTYIgUIqAUNKJABcCIFd CIFhSiQAcGgAAAAAGjUIgT4qAUIqAUNKMABcCIFhSjAAcGgAAAAAAAs2CIFtSAkEc0gJBAM2 CIEYA2oAAAAAVQgBbUgABG5IAARzSAkEdQgBAAM+KgEDPioABjYIgV0IgQANA2oAAAAAMEoT AFUIAQA4AAQAACcEAAB8BAAA6AQAAPEEAACnBQAAqAUAALcGAAC4BgAA5AcAAOUHAADrCAAA 7AgAAOoJAADrCQAAvAsAAMQLAADZCwAAKA4AACkOAABMEAAATRAAAGURAABmEQAApBQAAKUU AACaFwAAmxcAAE4YAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQMAAAECAAABAAAAAQEAABwABAAAfW8AABJwAABdcAAA3YUAAP7+ /v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AgEBBE4YAABPGAAAphoAAM0aAAA3HQAAOB0AAD4gAAA/IAAAayEAAGwhAADHIQAA+iEAAE0l AABOJQAARicAAEcnAABUKAAAfSgAAEEpAABCKQAAXykAAGApAACFKgAAhioAAKMqAACkKgAA 8yoAAPQqAADsKwAA7SsAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAABFwAAAQMAAAEAAAAd7SsAABgsAAAZLAAAIC4AACEuAACZMAAA mjAAAKMwAACkMAAAxTMAAMYzAADVMwAA1jMAAMU2AADGNgAA2DYAANk2AAB2OAAAdzgAAIE4 AACCOAAAmDkAAJk5AAC6OQAAuzkAAKk7AACqOwAAwDsAAME7AAD9AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRQACiYAC0YAAAABAAAAARcA ABzBOwAAaz0AAGw9AACBPQAAfz4AAIA+AABcQQAAXUEAAAJEAAADRAAALUQAAC5EAACsRQAA rUUAAMhJAADJSQAAg0oAAIRKAAANSwAAeUsAAAhMAAAJTAAAWkwAAFtMAABcTAAAbEwAANRM AADsTAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA6gAAAAAA AAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAAAAABFAAAARcABQAACiYAC0YHAAUU AAomAAtGBwAAAQMABRQACiYAC0YAAAABAAAAG+xMAAAUTQAAl00AAC9OAACFTgAAhk4AAJVO AAB6TwAAD1AAAP1QAABsUQAA9FIAAPVSAAABUwAAj1MAABhUAADzVAAAbFUAAPdVAAAKVwAA +VcAAPpXAAANWAAAWFgAAEtZAAA2WgAAN1oAAE5aAAC9WgAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAARcACRQACiYAC0YAAA+EaAFehGgBAAEUAAAc vVoAAIZbAABZXAAAWlwAAK5cAACvXAAAsFwAALFcAACyXAAAs1wAALRcAADkXAAAGV0AABpd AADvXwAA8F8AAMlgAADKYAAA1GAAAPBgAAAFYQAAG2EAAC9hAAA9YQAAVGEAAF1hAAB/YQAA gGEAAMBhAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA +wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAA AAEFAAABEgAAAQMAAAECAAABAAAAARQAABzAYQAAwWEAAOhhAADpYQAAJWIAACZiAACYYgAA /WIAAP5iAABEYwAAVmMAAHVjAAB2YwAAtGMAAPpjAAD7YwAAdWQAAHZkAACRZAAAyGQAAMdl AADIZQAADmYAAJlpAACaaQAA1mkAABZsAABcbAAAUG0AAP0AAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAECAAABFAAAAQUAAAEXAAABAAAAHFBt AABRbQAAd20AANRtAAATbgAAQ24AAERuAAAPbwAAEG8AAH1vAAARcAAAEnAAAFtwAABccAAA XXAAAGZwAABncAAAz3AAANBwAADbcAAA8HAAAARxAAAkcQAAJXEAAEFxAABCcQAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACQAACiYAC0YBADckADgkAEgkAAYAADckADgkAEgkAAkAAAMkATckADgkAEgk AGEkAQAEEQADJAFhJAEAARIAAAEAAAAZJXEAAEFxAABCcQAAUnEAAFNxAABicQAAY3EAAG9x AABwcQAAhXEAAIZxAACPcQAAkHEAALBxAACxcQAAxHEAAMVxAADPcQAA0HEAAOpxAADrcQAA +XEAAPpxAAD+cQAA/3EAAA9yAAAQcgAAHHIAAB1yAAAscgAALXIAAJNyAACUcgAAoHIAAClz AAAqcwAAOHMAADlzAABEcwAARXMAAFBzAADzAPMA8wDzAOoA3gDPAOoAxgDGAL0A6gC9AK4A nwCTAINzAGYAZgBmGUIqAUNKKABPSgQAUUoEAGFKKABwaAAAAAAfNgiBQioBQ0owAE9KBABR SgQAXQiBYUowAHBoAAAAAB82CIFCKgFDSjgAT0oEAFFKBABdCIFhSjgAcGgAAAAAFzYIgUIq AUNKIABdCIFhSiAAcGgAAAAAHDkIgUIqBkNKSABPSgMAUUoDAGFKSABwaMwAAAAAHTUIgTYI gUIqAUNKHABcCIFdCIFhShwAcGgAAAAAEUIqAUNKHABhShwAcGgAAAAAEUIqBkNKHABhShwA cGj/AAAAHTUIgTYIgUIqAkNKHABcCIFdCIFhShwAcGgzM8wAFzUIgUIqBkNKIABcCIFhSiAA cGj/AAAAEUIqAkNKHABhShwAcGgzM8wAFzUIgUIqBENKKABcCIFhSigAcGgzmTMAAChCcQAA UnEAAFNxAABicQAAY3EAAG9xAABwcQAAhXEAAIZxAACPcQAAkHEAALBxAACxcQAAxHEAAMVx AADPcQAA0HEAAOpxAADrcQAA+XEAAPpxAAD+cQAA/3EAAA9yAAAQcgAAHHIAAB1yAAAscgAA 9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAAAB AAAJAAADJAE3JAA4JABIJABhJAEAGyxyAAAtcgAAk3IAAJRyAACgcgAAyHIAAPFyAAApcwAA KnMAADhzAAA5cwAARHMAAEVzAABScwAAU3MAAGNzAABkcwAAaXMAAGpzAACLcwAAjHMAAMVz AADGcwAA13MAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOUAAAAA AAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAAygAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAMoAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQB NyQAOCQASCQAYSQBABEAAAomAAtGAwAPhJIEEYQ+/jckADgkAEgkAF6EkgRghD7+ABEAAAom AAtGAgAPhBwCEYTk/TckADgkAEgkAF6EHAJghOT9BgAANyQAOCQASCQAAAEAAAAXUHMAAFFz AABScwAAU3MAAGNzAABkcwAAaXMAAGpzAACLcwAAjHMAAMVzAADGcwAA13MAANhzAADccwAA 3XMAAO5zAADvcwAAKnQAACt0AABNdAAATnQAAF50AABfdAAAaHQAAGl0AABydAAAc3QAAH50 AADEdAAA2XQAAOh0AADpdAAA8nQAAPN0AAD/dAAAb3UAAHB1AAB+dQAAf3UAAIp1AACLdQAA l3UAAJh1AACodQAAqXUAAMJ1AADDdQAA53UAAOh1AAATdgAAFHYAACZ2AAAndgAAW3YAAFx2 AACRdgAAknYAANt2AADcdgAA9nYAAPHkAOQA1wDXANcA1wDXANcA1wDXAMgAugC6AKqaAMgA ugCqmgDkAOQA5ADkANcA1wDXANcA1wDXANcA1wAAAAAfNgiBQioBQ0owAE9KBABRSgQAXQiB YUowAHBoAAAAAB82CIFCKgFDSjgAT0oEAFFKBABdCIFhSjgAcGgAAAAAGjUIgT4qAUIqAUNK MABcCIFhSjAAcGgAAAAAABw5CIFCKgZDSkgAT0oDAFFKAwBhSkgAcGjMAAAAABlCKgFDSiQA T0oEAFFKBABhSiQAcGgAAAAAGUIqAUNKKABPSgQAUUoEAGFKKABwaAAAAAAcQioBQ0ooAEgq AU9KBABRSgQAYUooAHBoAAAAADzXcwAA2HMAANxzAADdcwAA7nMAAO9zAAAqdAAAK3QAAE10 AABOdAAAXnQAAF90AABodAAAaXQAAHJ0AABzdAAAfnQAAMR0AADFdAAAxnQAAMd0AADIdAAA yXQAAMp0AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA ygAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAKJgAL RgMAD4SSBBGEPv43JAA4JABIJABehJIEYIQ+/gARAAAKJgALRgIAD4QcAhGE5P03JAA4JABI JABehBwCYITk/QkAAAMkATckADgkAEgkAGEkAQYAADckADgkAEgkAAABAAAAF8p0AADLdAAA zHQAAM10AADOdAAAz3QAANB0AADRdAAA0nQAANN0AADUdAAA1XQAANZ0AADXdAAA2HQAANl0 AADodAAA6XQAAPJ0AADzdAAA/3QAAC91AABvdQAAcHUAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAADcAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAMoAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAABEAAAomAAtGAwAPhJIEEYQ+/jckADgkAEgkAF6EkgRghD7+ ABEAAAomAAtGAgAPhBwCEYTk/TckADgkAEgkAF6EHAJghOT9CQAAAyQBNyQAOCQASCQAYSQB BgAANyQAOCQASCQAAAEAAAAXcHUAAH51AAB/dQAAinUAAIt1AACXdQAAmHUAAKh1AACpdQAA wnUAAMN1AADndQAA6HUAABN2AAAUdgAAJnYAACd2AABbdgAAXHYAAJF2AACSdgAA23YAANx2 AAD2dgAA93YAACt3AAAsdwAATncAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAAA3JAA4JABIJAAAAQAACQAAAyQBNyQAOCQASCQAYSQBABv2dgAA93YAACt3 AAAsdwAATncAAE93AACadwAAm3cAALh3AAC5dwAAxXcAAMZ3AADPdwAA0HcAANt3AAA0eAAA NXgAAEN4AABEeAAAT3gAAFB4AABceAAAXXgAAG14AABueAAAkXgAAJJ4AACjeAAApHgAANN4 AADUeAAAFnkAABd5AAA9eQAAPnkAAGJ5AABjeQAAvXkAAL55AAAFegAABnoAAA96AAAQegAA JHoAACV6AABwegAAcXoAALN6AAC0egAAx3oAAMh6AADRegAA0noAAN56AABHewAASHsAAFZ7 AABXewAAYnsAAGN7AABvewAAcHsAAIB7AACBewAAjXsAAI57AADWewAAAPIA8gDyAPIA4wDV AMW1AKgAqACoAKgA8gDyAPIA8gDyAPIA8gDyAPIA8gDyAPIA4wDVAMW1AKgAqACoAKgA8gDy AAAZQioBQ0ooAE9KBABRSgQAYUooAHBoAAAAAB82CIFCKgFDSjAAT0oEAFFKBABdCIFhSjAA cGgAAAAAHzYIgUIqAUNKOABPSgQAUUoEAF0IgWFKOABwaAAAAAAaNQiBPioBQioBQ0owAFwI gWFKMABwaAAAAAAAHDkIgUIqBkNKSABPSgMAUUoDAGFKSABwaMwAAAAAGUIqAUNKJABPSgQA UUoEAGFKJABwaAAAAAAAQk53AABPdwAAmncAAJt3AAC4dwAAuXcAAMV3AADGdwAAz3cAANB3 AADbdwAANHgAADV4AABDeAAARHgAAE94AABQeAAAXHgAAF14AABteAAAbngAAJF4AACSeAAA o3gAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAomAAtGAwAP hJIEEYQ+/jckADgkAEgkAF6EkgRghD7+ABEAAAomAAtGAgAPhBwCEYTk/TckADgkAEgkAF6E HAJghOT9CQAAAyQBNyQAOCQASCQAYSQBBgAANyQAOCQASCQAAAEAAAAXo3gAAKR4AADTeAAA 1HgAABZ5AAAXeQAAPXkAAD55AABieQAAY3kAAL15AAC+eQAABXoAAAZ6AAAPegAAEHoAACR6 AAAlegAAcHoAAHF6AACzegAAtHoAAMd6AADIegAA0XoAANJ6AAD9AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAE3JAA4JABIJABhJAEGAAA3 JAA4JABIJAAAAQAAABnSegAA3noAABV7AABHewAASHsAAFZ7AABXewAAYnsAAGN7AABvewAA cHsAAIB7AACBewAAjXsAAI57AADWewAA13sAABt8AAAcfAAAKnwAACt8AABMfAAATXwAAIx8 AADtAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA 0AAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANAA AAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADKAAAA AAAAAAAAAAAA2QAAAAAAAAAAAAAAAMoAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAAygAAAAAA AAAAAAAAANkAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAAMoAAAAAAAAA AAAAAADZAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAAkA AAMkATckADgkAEgkAGEkAQABAAAAEQAACiYAC0YDAA+EkgQRhD7+NyQAOCQASCQAXoSSBGCE Pv4AEQAACiYAC0YCAA+EHAIRhOT9NyQAOCQASCQAXoQcAmCE5P0AF9Z7AADXewAAG3wAABx8 AAAqfAAAK3wAAEx8AABNfAAAjHwAAI18AACyfAAAs3wAAMZ8AADHfAAA1nwAANd8AADgfAAA 4XwAAP18AAD+fAAAQ30AAGZ9AABvfQAAcn0AAHN9AACSfQAAk30AAPx9AAD9fQAAJ34AAFd+ AABYfgAAcX4AAK1+AACufgAAvn4AAL9+AADOfgAAz34AANt+AADcfgAA8X4AAPJ+AAD7fgAA /H4AABx/AAAdfwAAMH8AADF/AAAA8gDyAPIA8gDyAPIA4wDVAMkAuqm6qbqpAKkAuqkAuqkA yQDJAMkAoACUAIUAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHTUIgTYIgUIqAkNKHABcCIFd CIFhShwAcGgzM8wAFzUIgUIqBkNKIABcCIFhSiAAcGj/AAAAEUIqAkNKHABhShwAcGgzM8wA IDUIgTYIgT4qAUIqBkNKHABcCIFdCIFhShwAcGjMAAAAAB01CIE2CIFCKgZDShwAXAiBXQiB YUocAHBozAAAABc1CIFCKgRDSigAXAiBYUooAHBoM5kzABo1CIE+KgFCKgFDSjAAXAiBYUow AHBoAAAAAAAcOQiBQioGQ0pIAE9KAwBRSgMAYUpIAHBozAAAAAAZQioBQ0okAE9KBABRSgQA YUokAHBoAAAAAAAwjHwAAI18AACyfAAAs3wAAMZ8AADHfAAA1nwAANd8AADgfAAA4XwAAP18 AAD+fAAAkn0AAJN9AAD8fQAA/X0AAFd+AABYfgAArX4AAK5+AAC+fgAAv34AAM5+AADPfgAA 234AANx+AADxfgAA8n4AAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADu AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAJAAADJAE3JAA4JABIJABhJAEGAAA3JAA4JABIJAAAAQAAABvyfgAA+34AAPx+AAAcfwAA HX8AADB/AAAxfwAAO38AADx/AABWfwAAV38AAGV/AABmfwAAan8AAGt/AAB7fwAAfH8AAIh/ AACJfwAApH8AAKV/AACufwAAr38AAL1/AAC+fwAAyX8AAMp/AADWfwAA9gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAAABAAAJAAADJAE3JAA4 JABIJABhJAEAGzF/AAA7fwAAPH8AAFZ/AABXfwAAZX8AAGZ/AABqfwAAa38AAHt/AAB8fwAA iH8AAIl/AACkfwAApX8AAK5/AACvfwAAvX8AAL5/AADJfwAAyn8AANZ/AADXfwAA538AAOh/ AAD0fwAA9X8AABWAAAAWgAAAUoAAAFOAAAB/gAAAgIAAAIWAAACGgAAAsoAAALOAAADlgAAA 5oAAABKBAAATgQAAIoEAACOBAAA6gQAAO4EAAFWBAABWgQAAXoEAAF+BAABvgQAAmoEAAKmB AAA6ggAARoIAAPqCAAD+ggAAf4MAAICDAAD2APYA7QDkAO0A1QDGALgAqwCrAKsAqwCeAJ4A ngCeAJ4AngCeAJ4AngCeAJ4AuACRq5GrkauRqwAAGUIqAUNKMABPSgQAUUoEAGFKMABwaAAA AAAZQioBQ0okAE9KBABRSgQAYUokAHBoAAAAABlCKgFDSigAT0oEAFFKBABhSigAcGgAAAAA GjUIgT4qAUIqAUNKMABcCIFhSjAAcGgAAAAAABw5CIFCKgZDSkgAT0oDAFFKAwBhSkgAcGjM AAAAAB01CIE2CIFCKgFDShwAXAiBXQiBYUocAHBoAAAAABFCKgJDShwAYUocAHBoMzPMABFC KgFDShwAYUocAHBoAAAAABFCKgZDShwAYUocAHBo/wAAAAA51n8AANd/AADnfwAA6H8AAPR/ AAD1fwAAFYAAABaAAABSgAAAU4AAAH+AAACAgAAAhYAAAIaAAACygAAAs4AAAOWAAADmgAAA EoEAABOBAAAigQAAI4EAADqBAAA7gQAAVYEAAFaBAABegQAAX4EAAP0AAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA3JAA4JABIJAAJAAADJAE3JAA4JABIJABh JAEAAQAAABtfgQAAb4EAAI2BAACagQAAqYEAANGBAADugQAAFYIAADqCAABGggAAcIIAAMmC AAD6ggAA/oIAACeDAABNgwAAf4MAAICDAACdgwAAnoMAAKeDAACogwAAHYQAAB6EAADtAAAA AAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA2wAAAAAA AAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAAO0AAAAAAAAA AAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADtAAAAAAAAAAAA AAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAA ANMAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADK AAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkATckADgkAEgkAGEkAQYA ADckADgkAEgkAAABAAAAEQAACiYAC0YFAA+EkgQRhD7+NyQAOCQASCQAXoSSBGCEPv4AEQAA CiYAC0YEAA+EHAIRhOT9NyQAOCQASCQAXoQcAmCE5P0AF4CDAACdgwAAnoMAAKeDAACogwAA HYQAAB6EAACGhAAAh4QAAPuEAAD8hAAABYUAAAaFAAAohQAAKYUAAFWFAABWhQAAboUAAG+F AACNhQAAjoUAALiFAAC5hQAA14UAAN6FAADxAOMA2gDRAMgAvADxAK8ArwCvAK8ArwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGUIqAUNKJABPSgQAUUoEAGFKJABwaAAAAAAXNQiBQioMQ0okAFwIgWFKJABwaKUA IQARQioCQ0okAGFKJABwaBJDzgARQioLQ0okAGFKJABwaAAzAAARQioMQ0okAGFKJABwaKUA IQAaNQiBPioBQioLQ0owAFwIgWFKMABwaAAzAAAAHDkIgUIqBkNKSABPSgMAUUoDAGFKSABw aMwAAAAYHoQAAIaEAACHhAAA+4QAAPyEAAAFhQAABoUAACiFAAAphQAAVYUAAFaFAABuhQAA b4UAAI2FAACOhQAAuIUAALmFAADXhQAA2IUAANmFAADahQAA24UAANyFAADdhQAA3oUAAPYA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA3 JAA4JABIJAAAAQAACQAAAyQBNyQAOCQASCQAYSQBABgcAB+wgi4gsMZBIbAIByKwCAcjkKAF JJCgBSWwAAAjACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAA//////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8A AAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIA AAAAAP8DAAEIAAABgAAAAQDQAgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAA AAEA0AIAAAAAAP8AAQEIAAABgAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEB CAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAA AAD/AAAAAC4ALgAuACkAKAApACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAmUAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAA AHzcEgZUDdkBIAAAAO8DAAACAAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQ ABQGQwAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8S BkS583dYyvN3/////zzbEgYZCbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaL nQswGP8WABAAFAZDAAAAnN0SBkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABtw/Z30HX6d27D9ndYxhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s 2xIGAM32dzjGFgDUAFID0ABSAyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABS AwjcEgaPLaAwWOt8MGALTgPRAAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAA AAAAAAAAABhyAgY4DdkB/NwSBhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKPj2AjzcEgYo+PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ 3BIGAQAAAHxxAgagcQIGBN0SBl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AAAA AAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAA AAD/AwABCAAAAYAAAAEA0AIAAAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAAB ANACAAAAAAD/AAEBCAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgA AAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA /wAAAAAuAC4ALgApACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAJlAJAB0wAh+wxkEgsIIuIbCgBSKwoAUjkAgHJJAIByWwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAPYCAmAAAOxe1jAzN4wwOA3ZAQEAAAB8 3BIGVA3ZASAAAADvAwAAAgAAAA5P1jAAAAAA9NsSBgEAAAAAAAAAAAAAAAAAAAD42hIGEAAU BkMAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAADOAAAAAAAAAAAAAEMAAADk2hIGAAAAANz/EgZE ufN3WMrzd/////882xIGGQm0d2wCAAAQABQGQwAAAJzdEgYAAAAAGEj2AgEAAACQ3RIGi50L MBj/FgAQABQGQwAAAJzdEgZDAAAAAKYbA0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAbcP2d9B1+nduw/Z3WMYWANAAUgMAAAAAAAAAAAAAAADc2xIG1Cz5dwDS+Xf/////7NsS BgDN9nc4xhYA1ABSA9AAUgMgAAAA7wMAAGYFjjA4DdkBBwAAAPIGjjAIQdYwJPj2AtAAUgMI 3BIGjy2gMFjrfDBgC04D0QAAABzcEgYAAAAAAAAAABQM2QF83BIG9hqyMNEAAAAAAAAAAAAA AAAAAAAYcgIGOA3ZAfzcEgYQAAAAAAAAAAAAAAAo+PYCAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACj49gI83BIGKPj2AjzcEgZD6AAAAAAAAM4h8XcBAAAAMAvZAZAQAAD0474wkNwS BgEAAAB8cQIGoHECBgTdEgZevJIwnQEAAPBxAgaMC9kBjAvZAQEAAAD///////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wAAAAAA AAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAAABAAEIAAABgAAAAQDQAgAAAAAA /wMAAQgAAAGAAAABANACAAAAAAD/AAABCAAAAYAAAAEA0AIAAAAAAP8EAAEIAAABgAAAAQDQ AgAAAAAA/wABAQgAAAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAAB gAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8A AAAALgAuAC4AKQAoACkAKAApACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAD2AgJgAADsXtYwMzeMMDgN2QEBAAAAfNwS BlQN2QEgAAAA7wMAAAIAAAAOT9YwAAAAAPTbEgYBAAAAAAAAAAAAAAAAAAAA+NoSBhAAFAZD AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAzgAAAAAAAAAAAABDAAAA5NoSBgAAAADc/xIGRLnz d1jK83f/////PNsSBhkJtHdsAgAAEAAUBkMAAACc3RIGAAAAABhI9gIBAAAAkN0SBoudCzAY /xYAEAAUBkMAAACc3RIGQwAAAACmGwNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AG3D9nfQdfp3bsP2d1jGFgDQAFIDAAAAAAAAAAAAAAAA3NsSBtQs+XcA0vl3/////+zbEgYA zfZ3OMYWANQAUgPQAFIDIAAAAO8DAABmBY4wOA3ZAQcAAADyBo4wCEHWMCT49gLQAFIDCNwS Bo8toDBY63wwYAtOA9EAAAAc3BIGAAAAAAAAAAAUDNkBfNwSBvYasjDRAAAAAAAAAAAAAAAA AAAAGHICBjgN2QH83BIGEAAAAAAAAAAAAAAAKPj2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAo+PYCPNwSBij49gI83BIGQ+gAAAAAAADOIfF3AQAAADAL2QGQEAAA9OO+MJDcEgYB AAAAfHECBqBxAgYE3RIGXrySMJ0BAADwcQIGjAvZAYwL2QEBAAAA//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8AAAAAAAAA /wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIAAAAAAP8D AAEIAAABgAAAAQDQAgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAAAAEA0AIA AAAAAP8AAQEIAAABgAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAA AAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/AAAA AC4ALgAuACkAKAApACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAmUAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAAAHzcEgZU DdkBIAAAAO8DAAACAAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQABQGQwAA AAAAAAAAAAAAAQAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8SBkS583dY yvN3/////zzbEgYZCbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaLnQswGP8W ABAAFAZDAAAAnN0SBkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABt w/Z30HX6d27D9ndYxhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s2xIGAM32 dzjGFgDUAFID0ABSAyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABSAwjcEgaP LaAwWOt8MGALTgPRAAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAAAAAAAAAA ABhyAgY4DdkB/NwSBhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKPj2AjzcEgYo+PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ3BIGAQAA AHxxAgagcQIGBN0SBl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAAAAD/AwAB CAAAAYAAAAEA0AIAAAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAABANACAAAA AAD/AAEBCAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAAB ANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA/wAAAAAu AC4ALgApACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAJlAJAB0wAh+wxkEgsIIuIbCgBSKwoAUjkAgHJJAIByWwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAPYCAmAAAOxe1jAzN4wwOA3ZAQEAAAB83BIGVA3Z ASAAAADvAwAAAgAAAA5P1jAAAAAA9NsSBgEAAAAAAAAAAAAAAAAAAAD42hIGEAAUBkMAAAAA AAAAAAAAAAEAAAAAAAAAAAAAAADOAAAAAAAAAAAAAEMAAADk2hIGAAAAANz/EgZEufN3WMrz d/////882xIGGQm0d2wCAAAQABQGQwAAAJzdEgYAAAAAGEj2AgEAAACQ3RIGi50LMBj/FgAQ ABQGQwAAAJzdEgZDAAAAAKYbA0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbcP2 d9B1+nduw/Z3WMYWANAAUgMAAAAAAAAAAAAAAADc2xIG1Cz5dwDS+Xf/////7NsSBgDN9nc4 xhYA1ABSA9AAUgMgAAAA7wMAAGYFjjA4DdkBBwAAAPIGjjAIQdYwJPj2AtAAUgMI3BIGjy2g MFjrfDBgC04D0QAAABzcEgYAAAAAAAAAABQM2QF83BIG9hqyMNEAAAAAAAAAAAAAAAAAAAAY cgIGOA3ZAfzcEgYQAAAAAAAAAAAAAAAo+PYCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACj49gI83BIGKPj2AjzcEgZD6AAAAAAAAM4h8XcBAAAAMAvZAZAQAAD0474wkNwSBgEAAAB8 cQIGoHECBgTdEgZevJIwnQEAAPBxAgaMC9kBjAvZAQEAAAD///////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////wAAAAAAAAD/AAAA AAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAAABAAEIAAABgAAAAQDQAgAAAAAA/wMAAQgA AAGAAAABANACAAAAAAD/AAABCAAAAYAAAAEA0AIAAAAAAP8EAAEIAAABgAAAAQDQAgAAAAAA /wABAQgAAAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQ AgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8AAAAALgAu AC4AKQAoACkAKAApACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAgAAAAAAD2AgJgAADsXtYwMzeMMDgN2QEBAAAAfNwSBlQN2QEg AAAA7wMAAAIAAAAOT9YwAAAAAPTbEgYBAAAAAAAAAAAAAAAAAAAA+NoSBhAAFAZDAAAAAAAA AAAAAAABAAAAAAAAAAAAAAAAzgAAAAAAAAAAAABDAAAA5NoSBgAAAADc/xIGRLnzd1jK83f/ ////PNsSBhkJtHdsAgAAEAAUBkMAAACc3RIGAAAAABhI9gIBAAAAkN0SBoudCzAY/xYAEAAU BkMAAACc3RIGQwAAAACmGwNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG3D9nfQ dfp3bsP2d1jGFgDQAFIDAAAAAAAAAAAAAAAA3NsSBtQs+XcA0vl3/////+zbEgYAzfZ3OMYW ANQAUgPQAFIDIAAAAO8DAABmBY4wOA3ZAQcAAADyBo4wCEHWMCT49gLQAFIDCNwSBo8toDBY 63wwYAtOA9EAAAAc3BIGAAAAAAAAAAAUDNkBfNwSBvYasjDRAAAAAAAAAAAAAAAAAAAAGHIC BjgN2QH83BIGEAAAAAAAAAAAAAAAKPj2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo +PYCPNwSBij49gI83BIGQ+gAAAAAAADOIfF3AQAAADAL2QGQEAAA9OO+MJDcEgYBAAAAfHEC BqBxAgYE3RIGXrySMJ0BAADwcQIGjAvZAYwL2QEBAAAA//////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIAAAAAAP8DAAEIAAAB gAAAAQDQAgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAAAAEA0AIAAAAAAP8A AQEIAAABgAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIA AAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/AAAAAC4ALgAu ACkAKAApACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAmUAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAAAHzcEgZUDdkBIAAA AO8DAAACAAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQABQGQwAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8SBkS583dYyvN3//// /zzbEgYZCbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaLnQswGP8WABAAFAZD AAAAnN0SBkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtw/Z30HX6 d27D9ndYxhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s2xIGAM32dzjGFgDU AFID0ABSAyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABSAwjcEgaPLaAwWOt8 MGALTgPRAAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAAAAAAAAAAABhyAgY4 DdkB/NwSBhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKPj2 AjzcEgYo+PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ3BIGAQAAAHxxAgag cQIGBN0SBl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAAAAAAAP8AAAAAAAAA /wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAAAAD/AwABCAAAAYAA AAEA0AIAAAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAABANACAAAAAAD/AAEB CAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAA AAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA/wAAAAAuAC4ALgAp ACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAJlAJAB0wAh+wxkEgsIIuIbCgBSKwoAUjkAgHJJAIByWwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACAAAAAAAPYCAmAAAOxe1jAzN4wwOA3ZAQEAAAB83BIGVA3ZASAAAADv AwAAAgAAAA5P1jAAAAAA9NsSBgEAAAAAAAAAAAAAAAAAAAD42hIGEAAUBkMAAAAAAAAAAAAA AAEAAAAAAAAAAAAAAADOAAAAAAAAAAAAAEMAAADk2hIGAAAAANz/EgZEufN3WMrzd/////88 2xIGGQm0d2wCAAAQABQGQwAAAJzdEgYAAAAAGEj2AgEAAACQ3RIGi50LMBj/FgAQABQGQwAA AJzdEgZDAAAAAKYbA0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbcP2d9B1+ndu w/Z3WMYWANAAUgMAAAAAAAAAAAAAAADc2xIG1Cz5dwDS+Xf/////7NsSBgDN9nc4xhYA1ABS A9AAUgMgAAAA7wMAAGYFjjA4DdkBBwAAAPIGjjAIQdYwJPj2AtAAUgMI3BIGjy2gMFjrfDBg C04D0QAAABzcEgYAAAAAAAAAABQM2QF83BIG9hqyMNEAAAAAAAAAAAAAAAAAAAAYcgIGOA3Z AfzcEgYQAAAAAAAAAAAAAAAo+PYCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACj49gI8 3BIGKPj2AjzcEgZD6AAAAAAAAM4h8XcBAAAAMAvZAZAQAAD0474wkNwSBgEAAAB8cQIGoHEC BgTdEgZevJIwnQEAAPBxAgaMC9kBjAvZAQEAAAD///////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wAAAAAAAAD/AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAAAAAAAABAAEIAAABgAAAAQDQAgAAAAAA/wMAAQgAAAGAAAAB ANACAAAAAAD/AAABCAAAAYAAAAEA0AIAAAAAAP8EAAEIAAABgAAAAQDQAgAAAAAA/wABAQgA AAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA /wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8AAAAALgAuAC4AKQAo ACkAKAApACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAgAAAAAAD2AgJgAADsXtYwMzeMMDgN2QEBAAAAfNwSBlQN2QEgAAAA7wMA AAIAAAAOT9YwAAAAAPTbEgYBAAAAAAAAAAAAAAAAAAAA+NoSBhAAFAZDAAAAAAAAAAAAAAAB AAAAAAAAAAAAAAAAzgAAAAAAAAAAAABDAAAA5NoSBgAAAADc/xIGRLnzd1jK83f/////PNsS BhkJtHdsAgAAEAAUBkMAAACc3RIGAAAAABhI9gIBAAAAkN0SBoudCzAY/xYAEAAUBkMAAACc 3RIGQwAAAACmGwNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG3D9nfQdfp3bsP2 d1jGFgDQAFIDAAAAAAAAAAAAAAAA3NsSBtQs+XcA0vl3/////+zbEgYAzfZ3OMYWANQAUgPQ AFIDIAAAAO8DAABmBY4wOA3ZAQcAAADyBo4wCEHWMCT49gLQAFIDCNwSBo8toDBY63wwYAtO A9EAAAAc3BIGAAAAAAAAAAAUDNkBfNwSBvYasjDRAAAAAAAAAAAAAAAAAAAAGHICBjgN2QH8 3BIGEAAAAAAAAAAAAAAAKPj2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo+PYCPNwS Bij49gI83BIGQ+gAAAAAAADOIfF3AQAAADAL2QGQEAAA9OO+MJDcEgYBAAAAfHECBqBxAgYE 3RIGXrySMJ0BAADwcQIGjAvZAYwL2QEBAAAA//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AAAAAAAAA/wAAAAAAAAD/AAAA AAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIAAAAAAP8DAAEIAAABgAAAAQDQ AgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAAAAEA0AIAAAAAAP8AAQEIAAAB gAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8E AQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/AAAAAC4ALgAuACkAKAAp ACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAm UAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAAAHzcEgZUDdkBIAAAAO8DAAAC AAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQABQGQwAAAAAAAAAAAAAAAQAA AAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8SBkS583dYyvN3/////zzbEgYZ CbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaLnQswGP8WABAAFAZDAAAAnN0S BkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtw/Z30HX6d27D9ndY xhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s2xIGAM32dzjGFgDUAFID0ABS AyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABSAwjcEgaPLaAwWOt8MGALTgPR AAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAAAAAAAAAAABhyAgY4DdkB/NwS BhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKPj2AjzcEgYo +PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ3BIGAQAAAHxxAgagcQIGBN0S Bl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////AAAAAAAAAP8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAAAAD/AwABCAAAAYAAAAEA0AIA AAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAABANACAAAAAAD/AAEBCAAAAYAA AAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/BAEB CAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA/wAAAAAuAC4ALgApACgAKQAo ACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJlAJ AB0wAh+wxkEgsIIuIbCgBSKwoAUjAAAAAAAAAAAAAAAAAAAAAAAUABgACgABAGkADwADAAAA AAAAAAAAMAAAQPH/AgAwAAwABgBOAG8AcgBtAGEAbAAAAAIAAAAQAF9IAQRtSAkMc0gJDHRI CQRIAAFAAQACAEgADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYA EwA1CIFDShwAS0gcAE9KAgBRSgIAAEoAAkABAAIASgAMAAkASABlAGEAZABpAG4AZwAgADIA AAAQAAIABiQBE6TwABSkPABAJgEVADUIgTYIgT4qAUNKGABPSgIAUUoCAABGAANAAQACAEYA DAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAAEAADAAYkAROk8AAUpDwAQCYCEgA1CIFDShgAT0oC AFFKAgBcCIEyAAQAAQACADIADAAJAEgAZQBhAGQAaQBuAGcAIAA0AAAACAAEAAYkAUAmAwYA NgiBXQiBMAAFQAEAAgAwAAwACQBIAGUAYQBkAGkAbgBnACAANQAAAAgABQAGJAFAJgQDAD4q AQAAAAAAAAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEA cABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAwAFoAAQDyADAADAAKAFAAbABhAGkAbgAgAFQA ZQB4AHQAAAACAA8ACABPSgUAUUoFACwAHwABAAIBLAAMAAYASABlAGEAZABlAHIAAAANABAA DcYIAALgEMAhAQIAAAAsACBAAQASASwADAAGAEYAbwBvAHQAZQByAAAADQARAA3GCAAC4BDA IQECAAAALgAdQAEAIgEuAAwADQBGAG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0AAAAAgASAAAA OAAmQKIAMQE4AAwAEgBGAG8AbwB0AG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAMA SCoBACYA/k8BAEIBJgAMAAUATABpAHMAdAAxAAAACQAUAAomAAtGCgAAAAAAACIA/g9BAWIB IgANAAUATABpAHMAdAAyAAAAAgAWAAMAPioBADIA/k8BAHIBMgAMAAoASQB0AGUAbQBIAGUA YQBkAGUAcgAAAAIAFwAJADUIgTYIgVwIgQDZEQAA3oEAAAEAAAAAAJQAAACXAAAAAAAAAAoA AABzAAAAyAAAAOUAAAD2AAAABgEAABMBAAApAQAAMwEAAFQBAABoAQAAcwEAAI4BAACdAQAA ogEAALMBAADAAQAA0AEAADcCAADNAgAA3AIAAOgCAAD2AgAABwMAAA0DAAAvAwAAaQMAAHsD AACAAwAAkgMAAM4DAADxAwAAAgQAAAwEAAAWBAAAaAQAAGkEAABqBAAAawQAAGwEAABtBAAA bgQAAG8EAABwBAAAcQQAAHIEAABzBAAAdAQAAHUEAAB2BAAAdwQAAHgEAAB5BAAAegQAAHsE AAB8BAAAjAQAAJYEAAATBQAAIgUAAC4FAAA7BQAATAUAAGYFAACLBQAAtwUAAMoFAAD/BQAA NQYAAH8GAACaBgAAzwYAAPIGAAA+BwAAXAcAAGkHAABzBwAA2AcAAOcHAADzBwAAAAgAABEI AAA1CAAARwgAAHcIAAC6CAAA4QgAAAYJAABhCQAAqQkAALMJAADICQAAFAoAAFcKAABrCgAA dQoAAOsKAAD6CgAABgsAABMLAAAkCwAAMQsAAHoLAAC/CwAAzgsAAPALAAAwDAAAVgwAAGoM AAB6DAAAhAwAAKEMAAA2DQAAoA0AAPsNAABRDgAAYg4AAHIOAAB/DgAAlQ4AAJ8OAADADgAA 1A4AAN8OAAD6DgAACQ8AAA4PAAAfDwAALA8AAEgPAABSDwAAYQ8AAG0PAAB6DwAAiw8AAJgP AAC5DwAA9g8AACMQAAApEAAAVhAAAIkQAAC2EAAAxhAAAN4QAAD5EAAAAhEAACMTAABBEwAA SxMAAMETAAAqFAAAnxQAAKkUAADMFAAA+RQAABIVAAAxFQAAXBUAAHsVAAB8FQAAfRUAAH4V AAB/FQAA3oEAAAEAAAAAAAAAAAD/////PwQAAAAAAAABAAAAAAAAAAAA/////z4EAAAAAAAA AQAAAAAAAAAAAP////89BAAAAAAAAAEAAAAAAAAAAAD/////OwQAAAAAAAABAAAAAAAAAAAA /////zkEAAAAAAAAAQAAAAAAAAAAAP////83BAAAAAAAAAEAAAAAAAAAAAD/////NQQAAAAA AAABAAAAAAAAAAAA/////y8EAAAAAAAAAQAAAAAAAAAAAP////8uBAAAAAAAAAEAAAAAAAAA AAD/////LAQAAAAAAAABAAAAAAAAAAAA/////ysEAAAAAAAAAQAAAAAAAAAAAP////8qBAAA AAAAAAEAAAAAAAAAAAD/////KAQAAAAAAAABAAAAAAAAAAAA/////ycEAAAAAAAAAQAAAAAA AAAAAP////8lBAAAAAAAAAEAAAAAAAAAAAD/////JAQAAAAAAAABAAAAAAAAAAAA/////yIE AAAAAAAAAQAAAAAAAAAAAP////8hBAAAAAAAAAEAAAAAAAAAAAD/////WAQAAAAAAAABAAAA AAAAAAAA/////1cEAAAAAAAAAQAAAAAAAAAAAP////9wBQAAAAAAAAEAAAAAAAAAAAD///// bwUAAAAAAAABAAAAAAAAAAAA/////24FAAAAAAAAAQAAAAAAAAAAAP////9tBQAAAAAAAAEA AAAAAAAAAAD/////bAUAAAAAAAABAAAAAAAAAAAA/////2sFAAAAAAAAAQAAAAAAAAAAAP// //9qBQAAAAAAAAEAAAAAAAAAAAD/////aQUAAAAAAAABAAAAAAAAAAAA/////2gFAAAAAAAA AQAAAAAAAAAAAP////9nBQAAAAAAAAEAAAAAAAAAAAD/////ZgUAAAAAAAABAAAAAAAAAAAA /////2UFAAAAAAAAAQAAAAAAAAAAAP////9ABAAAAAAAAAEAAAAAAAAAAAD/////WQQAAAAA AAABAAAAAAAAAAAA/////3wEAAAAAAAAAQAAAAAAAAAAAP////97BAAAAAAAAP////8AAAAA AQD/////AAAAAAAAAAAkAAAAAQAAAAEA/////wAAAAAAAAAAJQAAAAIAAAABAP////8AAAAA AAAAACYAAAADAAAAAQD/////AAAAAAAAAAAnAAAABAAAAAEA/////wAAAAAAAAAAKAAAAAUA AAABAP////8AAAAAAAAAACkAAAAGAAAAAQD/////AAAAAAAAAAAqAAAABwAAAAEA/////wAA AAAAAAAAKwAAAAgAAAABAP////8AAAAAAAAAACwAAAAJAAAAAQD/////AAAAAAAAAAAtAAAA CgAAAAEA/////wAAAAAAAAAALgAAAAsAAAABAP////8AAAAAAAAAAC8AAAAMAAAAAQD///// AAAAAAAAAAAwAAAADQAAAAEA/////wAAAAAAAAAAMQAAAA4AAAABAP////8AAAAAAAAAADIA AAAPAAAAAQD/////AAAAAAAAAAAzAAAAEAAAAAEA/////wAAAAAAAAAANAAAABEAAAABAP// //8AAAAAAAAAADUAAAASAAAAAQD/////AAAAAAAAAAA2AAAAEwAAAAEA/////wAAAAAAAAAA AQAAAAAAAAAAAP////9aBAAAAAAAAAEAAAAAAAAAAAD/////mgQAAAAAAAABAAAAAAAAAAAA /////5kEAAAAAAAAAQAAAAAAAAAAAP////+OBAAAAAAAAAEAAAAAAAAAAAD/////jQQAAAAA AAABAAAAAAAAAAAA/////4wEAAAAAAAAAQAAAAAAAAAAAP////+LBAAAAAAAAAEAAAAAAAAA AAD/////igQAAAAAAAABAAAAAAAAAAAA/////4kEAAAAAAAAAQAAAAAAAAAAAP////+IBAAA AAAAAAEAAAAAAAAAAAD/////hwQAAAAAAAABAAAAAAAAAAAA/////4YEAAAAAAAAAQAAAAAA AAAAAP////+FBAAAAAAAAAEAAAAAAAAAAAD/////hAQAAAAAAAABAAAAAAAAAAAA/////4ME AAAAAAAAAQAAAAAAAAAAAP////+CBAAAAAAAAAEAAAAAAAAAAAD/////gQQAAAAAAAABAAAA AAAAAAAA/////4AEAAAAAAAAAQAAAAAAAAAAAP////9/BAAAAAAAAAEAAAAAAAAAAAD///// fQQAAAAAAAABAAAAAAAAAAAA/////7gEAAAAAAAAAQAAAAAAAAAAAP////+3BAAAAAAAAAEA AAAAAAAAAAD/////ygUAAAAAAAABAAAAAAAAAAAA/////8kFAAAAAAAAAQAAAAAAAAAAAP// ///IBQAAAAAAAAEAAAAAAAAAAAD/////xwUAAAAAAAABAAAAAAAAAAAA/////8YFAAAAAAAA AQAAAAAAAAAAAP/////FBQAAAAAAAAEAAAAAAAAAAAD/////xAUAAAAAAAABAAAAAAAAAAAA /////8MFAAAAAAAAAQAAAAAAAAAAAP/////CBQAAAAAAAAEAAAAAAAAAAAD/////wQUAAAAA AAABAAAAAAAAAAAA/////8AFAAAAAAAAAQAAAAAAAAAAAP////+/BQAAAAAAAAEAAAAAAAAA AAD/////vgUAAAAAAAABAAAAAAAAAAAA/////70FAAAAAAAAAQAAAAAAAAAAAP////+8BQAA AAAAAAEAAAAAAAAAAAD/////uwUAAAAAAAABAAAAAAAAAAAA/////5sEAAAAAAAAAQAAAAAA AAAAAP/////RBAAAAAAAAAEAAAAAAAAAAAD/////0AQAAAAAAAABAAAAAAAAAAAA/////8YE AAAAAAAAAQAAAAAAAAAAAP/////FBAAAAAAAAAEAAAAAAAAAAAD/////xAQAAAAAAAABAAAA AAAAAAAA/////8MEAAAAAAAAAQAAAAAAAAAAAP/////CBAAAAAAAAAEAAAAAAAAAAAD///// wQQAAAAAAAABAAAAAAAAAAAA/////8AEAAAAAAAAAQAAAAAAAAAAAP////+/BAAAAAAAAAEA AAAAAAAAAAD/////vgQAAAAAAAABAAAAAAAAAAAA/////70EAAAAAAAAAQAAAAAAAAAAAP// //+8BAAAAAAAAAEAAAAAAAAAAAD/////uwQAAAAAAAABAAAAAAAAAAAA/////7kEAAAAAAAA AQAAAAAAAAAAAP/////2BAAAAAAAAAEAAAAAAAAAAAD/////9QQAAAAAAAABAAAAAAAAAAAA //////MEAAAAAAAAAQAAAAAAAAAAAP/////xBAAAAAAAAAEAAAAAAAAAAAD/////8AQAAAAA AAABAAAAAAAAAAAA/////+0EAAAAAAAAAQAAAAAAAAAAAP/////qBAAAAAAAAAEAAAAAAAAA AAD/////6AQAAAAAAAABAAAAAAAAAAAA/////+YEAAAAAAAAAQAAAAAAAAAAAP/////gBAAA AAAAAAEAAAAAAAAAAAD/////3wQAAAAAAAABAAAAAAAAAAAA/////90EAAAAAAAAAQAAAAAA AAAAAP/////cBAAAAAAAAAEAAAAAAAAAAAD/////2wQAAAAAAAABAAAAAAAAAAAA/////9kE AAAAAAAAAQAAAAAAAAAAAP/////YBAAAAAAAAAEAAAAAAAAAAAD/////1gQAAAAAAAABAAAA AAAAAAAA/////9UEAAAAAAAAAQAAAAAAAAAAAP/////TBAAAAAAAAAEAAAAAAAAAAAD///// 0gQAAAAAAAABAAAAAAAAAAAA/////yQFAAAAAAAAAQAAAAAAAAAAAP////+OBQAAAAAAAAEA AAAAAAAAAAD/////jQUAAAAAAAABAAAAAAAAAAAA/////4wFAAAAAAAAAQAAAAAAAAAAAP// //+LBQAAAAAAAAEAAAAAAAAAAAD/////igUAAAAAAAABAAAAAAAAAAAA/////4kFAAAAAAAA AQAAAAAAAAAAAP////+IBQAAAAAAAAEAAAAAAAAAAAD/////hwUAAAAAAAABAAAAAAAAAAAA /////4YFAAAAAAAAAQAAAAAAAAAAAP////+FBQAAAAAAAAEAAAAAAAAAAAD/////hAUAAAAA AAABAAAAAAAAAAAA/////4MFAAAAAAAAAQAAAAAAAAAAAP////+CBQAAAAAAAAEAAAAAAAAA AAD/////gQUAAAAAAAABAAAAAAAAAAAA/////4AFAAAAAAAAAQAAAAAAAAAAAP////9jBQAA AAAAAAEAAAAAAAAAAAD/////YgUAAAAAAAABAAAAAAAAAAAA/////2EFAAAAAAAAAQAAAAAA AAAAAP////9gBQAAAAAAAAEAAAAAAAAAAAD/////XQUAAAAAAAABAAAAAAAAAAAA/////1wF AAAAAAAAAQAAAAAAAAAAAP////9ZBQAAAAAAAAEAAAAAAAAAAAD/////WAUAAAAAAAABAAAA AAAAAAAA/////1MFAAAAAAAAAQAAAAAAAAAAAP////9/BQAAAAAAAAEAAAAAAAAAAAD///// fgUAAAAAAAABAAAAAAAAAAAA/////30FAAAAAAAAAQAAAAAAAAAAAP////98BQAAAAAAAAEA AAAAAAAAAAD/////ewUAAAAAAAA3AAAAFAAAAAEA/////wAAAAAAAAAAoAAAABUAAAABAP// //8AAAAAAAAAAKEAAAAWAAAAAQD/////AAAAAAAAAACiAAAAFwAAAAEA/////wAAAAAAAAAA owAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAcwAAAMgAAADlAAAA9gAAAAYBAAATAQAA KQEAADMBAABUAQAAaAEAAHMBAACOAQAAnQEAAKIBAACzAQAAwAEAANABAAA3AgAAzQIAANwC AADoAgAA9gIAAAcDAAANAwAALwMAAGkDAAB7AwAAgAMAAJIDAADOAwAA8QMAAAIEAAAMBAAA FgQAAGgEAABpBAAAagQAAGsEAABsBAAAbQQAAG4EAABvBAAAcAQAAHEEAAByBAAAcwQAAHQE AAB1BAAAdgQAAHcEAAB4BAAAeQQAAHoEAAB7BAAAfAQAAIwEAACWBAAAEwUAACIFAAAuBQAA OwUAAEwFAABmBQAAiwUAALcFAADKBQAA/wUAADUGAAB/BgAAmgYAAM8GAADyBgAAPgcAAFwH AABpBwAAcwcAANgHAADnBwAA8wcAAAAIAAARCAAANQgAAEcIAAB3CAAAuggAAOEIAAAGCQAA YQkAAKkJAACzCQAAyAkAABQKAABXCgAAawoAAHUKAADrCgAA+goAAAYLAAATCwAAJAsAADEL AAB6CwAAvwsAAM4LAADwCwAAMAwAAFYMAABqDAAAegwAAIQMAAChDAAANg0AAKANAAD7DQAA UQ4AAGIOAAByDgAAfw4AAJUOAACfDgAAwA4AANQOAADfDgAA+g4AAAkPAAAODwAAHw8AACwP AABIDwAAUg8AAGEPAABtDwAAeg8AAIsPAACYDwAAuQ8AAPYPAAAjEAAAKRAAAFYQAACJEAAA thAAAMYQAADeEAAA+RAAAAIRAAAjEwAAQRMAAEsTAADBEwAAKhQAAJ8UAACpFAAAzBQAAPkU AAASFQAAMRUAAFwVAAB7FQAAfBUAAH0VAAB+FQAAfxUAAIIVAAAAAAAAAAgBAAAAAAgCAAAA AAgDAAAAAAgEAAAAAAgFAAAAAAgGAAAAAAgHAAAAAAgIAAAAAAgJAAAAAAgKAAAAAAgLAAAA AAgMAAAAAAgNAAAAAAgOAAAAAAgPAAAAAAgQAAAAAAgRAAAAAAgSAAAAAAgTAAAAAAgUAAAA AAgVAAAAAAgWAAAAAAgXAAAAAAgYAAAAAAgZAAAAAAgaAAAAAAgbAAAAAAgcAAAAAAgdAAAA AAgeAAAAAAgfAAAAAAggAAAAAAghAAAAAAgiAAAAAAgjAAAAAAgkAAAAAAglAAAAAAgmAAAA AAgnAAAAAAgoAAAAAAgpAAAAAAgqAAAAAAgrAAAAAAgsAAAAAAgtAAAAAAguAAAAAAgvAAAA AAgwAAAAAAgxAAAAAAgyAAAAAAgzAAAAAAg0AAAAAAg1AAAAAAg2AAAAAAg3AAAAAAg4AAAA AAg5AAAAAAg6AAAAAAg7AAAAAAg8AAAAAAg9AAAAAAg+AAAAAAg/AAAAAAhAAAAAAAhBAAAA AAhCAAAAAAhDAAAAAAhEAAAAAAhFAAAAAAhGAAAAAAhHAAAAAAhIAAAAAAhJAAAAAAhKAAAA AAhLAAAAAAhMAAAAAAhNAAAAAAhOAAAAAAhPAAAAAAhQAAAAAAhRAAAAAAhSAAAAAAhTAAAA AAhUAAAAAAhVAAAAAAhWAAAAAAhXAAAAAAhYAAAAAAhZAAAAAAhaAAAAAAhbAAAAAAhcAAAA AAhdAAAAAAheAAAAAAhfAAAAAAhgAAAAAAhhAAAAAAhiAAAAAAhjAAAAAAhkAAAAAAhlAAAA AAhmAAAAAAhnAAAAAAhoAAAAAAhpAAAAAAhqAAAAAAhrAAAAAAhsAAAAAAhtAAAAAAhuAAAA AAhvAAAAAAhwAAAAAAhxAAAAAAhyAAAAAAhzAAAAAAh0AAAAAAh1AAAAAAh2AAAAAAh3AAAA AAh4AAAAAAh5AAAAAAh6AAAAAAh7AAAAAAh8AAAAAAh9AAAAAAh+AAAAAAh/AAAAAAiAAAAA AAiBAAAAAAiCAAAAAAiDAAAAAAiEAAAAAAiFAAAAAAiGAAAAAAiHAAAAAAiIAAAAAAiJAAAA AAiKAAAAAAiLAAAAAAiMAAAAAAiNAAAAAAiOAAAAAAiPAAAAAAiQAAAAAAiRAAAAAAiSAAAA AAiTAAAAAAiUAAAAAAiVAAAAAAiWAAAAAAiXAAAAAAiYAAAAAAiZAAAAAAiaAAAAAAibAAAA AAicAAAAAAidAAAAAAieAAAAAAifAAAAAAigAAAAAAihAAAAAAiiAAAAAAijAAAAAAj//wAA AAAAAAAAEGsAAN6BAAAGAADMAAAAAP////8GAB7MAAAAAP////8AAAAAJwAAAHwAAADoAAAA 8QAAAKcBAACoAQAAtwIAALgCAADkAwAA5QMAAOsEAADsBAAA6gUAAOsFAAC8BwAAxAcAANkH AAAoCgAAKQoAAEwMAABNDAAAZQ0AAGYNAACkEAAApRAAAJoTAACbEwAAThQAAE8UAACmFgAA zRYAADcZAAA4GQAAPhwAAD8cAABrHQAAbB0AAMcdAAD6HQAATSEAAE4hAABGIwAARyMAAFQk AAB9JAAAQSUAAEIlAABfJQAAYCUAAIUmAACGJgAAoyYAAKQmAADzJgAA9CYAAOwnAADtJwAA GCgAABkoAAAgKgAAISoAAJksAACaLAAAoywAAKQsAADFLwAAxi8AANUvAADWLwAAxTIAAMYy AADYMgAA2TIAAHY0AAB3NAAAgTQAAII0AACYNQAAmTUAALo1AAC7NQAAqTcAAKo3AADANwAA wTcAAGs5AABsOQAAgTkAAH86AACAOgAAXD0AAF09AAACQAAAA0AAAC1AAAAuQAAArEEAAK1B AADIRQAAyUUAAINGAACERgAADUcAAHlHAAAISAAACUgAAFpIAABbSAAAXEgAAGxIAADUSAAA 7EgAABRJAACXSQAAL0oAAIVKAACGSgAAlUoAAHpLAAAPTAAA/UwAAGxNAAD0TgAA9U4AAAFP AACPTwAAGFAAAPNQAABsUQAA91EAAApTAAD5UwAA+lMAAA1UAABYVAAAS1UAADZWAAA3VgAA TlYAAL1WAACGVwAAWVgAAFpYAACuWAAAr1gAALBYAACxWAAAslgAALNYAAC0WAAA5FgAABlZ AAAaWQAA71sAAPBbAADJXAAAylwAANRcAADwXAAABV0AABtdAAAvXQAAPV0AAFRdAABdXQAA f10AAIBdAADAXQAAwV0AAOhdAADpXQAAJV4AACZeAACYXgAA/V4AAP5eAABEXwAAVl8AAHVf AAB2XwAAtF8AAPpfAAD7XwAAdWAAAHZgAACRYAAAyGAAAMdhAADIYQAADmIAAJllAACaZQAA 1mUAABZoAABcaAAAUGkAAFFpAAB3aQAA1GkAABNqAABDagAARGoAAA9rAAAQawAAfWsAABFs AAASbAAAW2wAAFxsAABdbAAAZmwAAGdsAADPbAAA0GwAANtsAADwbAAABG0AACRtAAAlbQAA QW0AAEJtAABSbQAAU20AAGJtAABjbQAAb20AAHBtAACFbQAAhm0AAI9tAACQbQAAsG0AALFt AADEbQAAxW0AAM9tAADQbQAA6m0AAOttAAD5bQAA+m0AAP5tAAD/bQAAD24AABBuAAAcbgAA HW4AACxuAAAtbgAAk24AAJRuAACgbgAAyG4AAPFuAAApbwAAKm8AADhvAAA5bwAARG8AAEVv AABSbwAAU28AAGNvAABkbwAAaW8AAGpvAACLbwAAjG8AAMVvAADGbwAA128AANhvAADcbwAA 3W8AAO5vAADvbwAAKnAAACtwAABNcAAATnAAAF5wAABfcAAAaHAAAGlwAABycAAAc3AAAH5w AADEcAAAxXAAAMZwAADHcAAAyHAAAMlwAADKcAAAy3AAAMxwAADNcAAAznAAAM9wAADQcAAA 0XAAANJwAADTcAAA1HAAANVwAADWcAAA13AAANhwAADZcAAA6HAAAOlwAADycAAA83AAAP9w AAAvcQAAb3EAAHBxAAB+cQAAf3EAAIpxAACLcQAAl3EAAJhxAACocQAAqXEAAMJxAADDcQAA 53EAAOhxAAATcgAAFHIAACZyAAAncgAAW3IAAFxyAACRcgAAknIAANtyAADccgAA9nIAAPdy AAArcwAALHMAAE5zAABPcwAAmnMAAJtzAAC4cwAAuXMAAMVzAADGcwAAz3MAANBzAADbcwAA NHQAADV0AABDdAAARHQAAE90AABQdAAAXHQAAF10AABtdAAAbnQAAJF0AACSdAAAo3QAAKR0 AADTdAAA1HQAABZ1AAAXdQAAPXUAAD51AABidQAAY3UAAL11AAC+dQAABXYAAAZ2AAAPdgAA EHYAACR2AAAldgAAcHYAAHF2AACzdgAAtHYAAMd2AADIdgAA0XYAANJ2AADedgAAFXcAAEd3 AABIdwAAVncAAFd3AABidwAAY3cAAG93AABwdwAAgHcAAIF3AACNdwAAjncAANZ3AADXdwAA G3gAABx4AAAqeAAAK3gAAEx4AABNeAAAjHgAAI14AACyeAAAs3gAAMZ4AADHeAAA1ngAANd4 AADgeAAA4XgAAP14AAD+eAAAknkAAJN5AAD8eQAA/XkAAFd6AABYegAArXoAAK56AAC+egAA v3oAAM56AADPegAA23oAANx6AADxegAA8noAAPt6AAD8egAAHHsAAB17AAAwewAAMXsAADt7 AAA8ewAAVnsAAFd7AABlewAAZnsAAGp7AABrewAAe3sAAHx7AACIewAAiXsAAKR7AAClewAA rnsAAK97AAC9ewAAvnsAAMl7AADKewAA1nsAANd7AADnewAA6HsAAPR7AAD1ewAAFXwAABZ8 AABSfAAAU3wAAH98AACAfAAAhXwAAIZ8AACyfAAAs3wAAOV8AADmfAAAEn0AABN9AAAifQAA I30AADp9AAA7fQAAVX0AAFZ9AABefQAAX30AAG99AACNfQAAmn0AAKl9AADRfQAA7n0AABV+ AAA6fgAARn4AAHB+AADJfgAA+n4AAP5+AAAnfwAATX8AAH9/AACAfwAAnX8AAJ5/AACnfwAA qH8AAB2AAAAegAAAhoAAAIeAAAD7gAAA/IAAAAWBAAAGgQAAKIEAACmBAABVgQAAVoEAAG6B AABvgQAAjYEAAI6BAAC4gQAAuYEAANeBAADfgQAACAAAAAEwAAAAAAAAAIAAAACACAAAAAEw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAnAAAAGAAAAAIwAAAAAAAAAIAnAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAGAAAAAIwAAAAAAAAAIAnAAAAKAAAAAMw AAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAw AAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAw AAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAw AAAAAAAAAICmFgAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIDHHQAAmAAAAAAw AAAAAAAAAIDHHQAAmAAAAAAwAAAAAAAAAIDHHQAAmAAAAAAwAAAAAAAAAIDHHQAAmAAAAAAw AAAAAAAAAIDHHQAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAw AAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAmAAAAAAw AAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAKAAAAAMw AAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAw AAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAw AAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAHIBQwAAAAAAAAAIADQAAAmAAHIAAw AQAAAAAAAIADQAAAmAAHIAAwAgAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIAqQAAAmAAAAAAw AAAAAAAAAIAqQAAAmAAAAAAwAAAAAAAAAIAqQAAAmAAAAAAwAAAAAAAAAIAqQAAAmAAAABcw AAAAAAAAAIAqQAAAmAAKIBQwAAAAAAAAAIAqQAAAmAAKIBQwAQAAAAAAAIAqQAAAmAAKIBQw AgAAAAAAAIAqQAAAmAAKIBQwAwAAAAAAAIAqQAAAmAAKIBQwBAAAAAAAAIAqQAAAmAAKIBQw BQAAAAAAAIAqQAAAmAAAABQwAAAAAAAAAIAqQAAAmAAAABcwAAAAAAAAAIAqQAAAmAAKIBQw BgAAAAAAAIAqQAAAmAAKIBQwBwAAAAAAAIAqQAAAmAAKIBQwCAAAAAAAAIAqQAAAmAAKIBQw CQAAAAAAAIAqQAAAmAAKIBQwCgAAAAAAAIAqQAAAmAAAABcwAAAAAAAAAIAAAACAmAAAABcw AAAAAAAAAIAAAACAmAAKIBQwCwAAAAAAAIAqQAAAmAAKIBQwDAAAAAAAAIAqQAAAmAAKIBQw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAAABcw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAGAAAAAIwAAAAAAAAAIAAAACAKAAAAAMw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABIw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACASAAAAAUw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACASAAAAAUw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABcw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAGAAAAAIwAAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAYAAwAAAAAAAAAIBeSQAAmAAAAAAwAAAAAAAAAIAAAACAmkAAABIw AAAAAAAAAIAAAACACgAAAAAwAAAAAAAAAAAAAAAAmkAAABEwAAAAAAAAAIAAAACAmkAAAAAw AAAAAAAAAIAAAACACgAAAAAwAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAABIAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAACIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAADIAAw AAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAACIAAw AAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAACIAAw AAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAACIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAACIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAADIAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAEIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAEIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAEIAAwAAAAAAAAAIAAAACAmAAFIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAEIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmkAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmkAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmkAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAQAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEoAAABKAAAASgAAAEoAAABKAAAASgAAAEoAAABKAAAASgAAAE0A AAAABAAAJXEAAFBzAAD2dgAA1nsAADF/AACAgwAA3oUAAEkAAABTAAAAVgAAAFoAAABeAAAA YQAAAGQAAAAABAAAThgAAO0rAADBOwAA7EwAAL1aAADAYQAAUG0AAEJxAAAscgAA13MAAMp0 AABwdQAATncAAKN4AADSegAAjHwAAPJ+AADWfwAAX4EAAB6EAADehQAASgAAAEwAAABNAAAA TgAAAE8AAABQAAAAUQAAAFIAAABUAAAAVQAAAFcAAABYAAAAWQAAAFsAAABcAAAAXQAAAF8A AABgAAAAYgAAAGMAAABlAAAAAAQAAN2FAABLAAAADwAA8PAAAAAAAAbwGAAAAAIIAAACAAAA XwIAAAEAAAABAAAAYAIAAE8AAfCwAAAAMgAH8CQAAAADBDMoq1PW1VeuUPa6P6QBBe7/ABEh AAAAAAAA/////wAA2QEiAAfwJAAAAAIEECZOG/62P+cvPsLqfs6HoP8AtzsAAAAAAAD///// AADZASIAB/AkAAAAAgQ9rp+f9zQwyvI+N7qhOV4A/wBcOwAAAAAAAP////8AANkBIgAH8CQA AAACBCprq3vTPBrQfEOD1PcaHCn/AKwpAAABAAAAQ8wAAAAA2QFAAB7xEAAAAP//AAAAAP8A gICAAPcAABAADwAC8NxtAAAQAAjwCAAAAOoAAABfBgAADwAD8HptAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwZgAAABIACvAIAAAAIQQA AAAKAABzAAvwKgAAAH8AAQAFAIAAAAASAIcAAQAAAIEBAMyZAL8BAAARAP8BAAAJAAECAAAA AAAAEPAEAAAAIwAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAASAA8ABPBmAAAAogwK8AgAAAAi BAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAABEAvwACAAIAgQEAzJkAvwEAABAA/wEIAAgAAQIA AAAAAAAQ8AQAAAAiAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAABEADwAE8GYAAABCAQrwCAAA ACMEAAAACgAAkwAL8DYAAAB/AAAABABEAQQAAAB/AQAAAQC/AQAAEADLAT7fAADQAQEAAADR AQEAAAD/ARgAGAABAgAAAAAAABDwBAAAACEAAAAAABHwBAAAAAMAAAAPAATwZgAAAKIMCvAI AAAAJAQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAAQAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAI AAECAAAAAAAAEPAEAAAAIAAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAQAA8ABPBsAAAAogwK 8AgAAAAlBAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAA8AvwACAAIAgQEAzJkAvwEAABAAwAEz M8wA/wEIAAgAAQIAAAAAAAAQ8AQAAAAfAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAA8ADwAE 8GYAAABCAQrwCAAAACYEAAAACgAAkwAL8DYAAAB/AAAABABEAQQAAAB/AQAAAQC/AQAAEADL AT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgAAAAAAABDwBAAAAB4AAAAAABHwBAAAAAMAAAAP AATwZgAAAKIMCvAIAAAAJwQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAAOAL8AAgACAIEBAMyZ AL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAAHQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAO AA8ABPBsAAAAogwK8AgAAAAoBAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAA0AvwACAAIAgQEA zJkAvwEAABAAwAH/AAAA/wEIAAgAAQIAAAAAAAAQ8AQAAAAcAAAAAAAR8AQAAAADAAAAAAAN 8AQAAAAAAA0ADwAE8GwAAABCAQrwCAAAACkEAAAACgAAowAL8DwAAAB/AAAABABEAQQAAAB/ AQAAAQC/AQAAEADAAf8AAADLAT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgAAAAAAABDwBAAA ABsAAAAAABHwBAAAAAMAAAAPAATwZgAAAKIMCvAIAAAAKgQAAAAKAABzAAvwKgAAAH8AAAAE AIAAAAAMAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAAGgAAAAAAEfAE AAAAAwAAAAAADfAEAAAAAAAMAA8ABPBsAAAAogwK8AgAAAArBAAAAAoAAIMAC/AwAAAAfwAA AAQAgAAAAAsAvwACAAIAgQEAzJkAvwEAABAAwAEzM8wA/wEIAAgAAQIAAAAAAAAQ8AQAAAAZ AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAAsADwAE8GwAAACiDArwCAAAACwEAAAACgAAgwAL 8DAAAAB/AAAABACAAAAACgC/AAIAAgCBAQDMmQC/AQAAEADAATMzzAD/AQgACAABAgAAAAAA ABDwBAAAABgAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAACgAPAATwZgAAADIACvAIAAAALQQA AAAKAACTAAvwNgAAAH8AAAAEAIUAAgAAAIcAAQAAAIEBAMyZAL8BAAAQAMAB/wAAAMsBakoA AP8BCAAIAAECAAAAAAAAEPAEAAAAFwAAAAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAAAu BAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAAkAvwACAAIAgQEAzJkAvwEAABAAwAEzM8wA/wEA AAgAAQIAAAAAAAAQ8AQAAAAWAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAAkADwAE8GwAAACi DArwCAAAAC8EAAAACgAAgwAL8DAAAAB/AAAABACAAAAACAC/AAIAAgCBAQDMmQC/AQAAEADA ATMzzAD/AQgACAABAgAAAAAAABDwBAAAABUAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAACAAP AATwbAAAAEIBCvAIAAAAMAQAAAAKAACjAAvwPAAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQ AMABMzPMAMsBPt8AANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAFAAAAAAAEfAE AAAAAwAAAA8ABPByAAAAQgEK8AgAAAAxBAAAAAoAALMAC/BCAAAABAAnGjEAfwAAAAQARAEE AAAAfwEAAAEAvwEAABAAwAH/AAAAywE+3wAA0AEBAAAA0QEBAAAA/wEYABgAAQIAAAAAAAAQ 8AQAAAATAAAAAAAR8AQAAAADAAAADwAE8HIAAABCAQrwCAAAADIEAAAACgAAswAL8EIAAAAE AKNRxP9/AAAABABEAQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAT7fAADQAQEAAADRAQEAAAD/ ARgAGAABAgAAAAAAABDwBAAAABIAAAAAABHwBAAAAAMAAAAPAATwcgAAAEIBCvAIAAAAMwQA AEAKAACzAAvwQgAAAAQA2eXO/38AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsBPt8A ANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAEQAAAAAAEfAEAAAAAwAAAA8ABPBs AAAAEgAK8AgAAAA0BAAAAAoAAKMAC/A8AAAAfwAAAAQAhQACAAAAhwABAAAAgQEAzJkAvwEA ABAAwAEzmTMAywHUlAAAzgEIAAAA/wEIAAgAAQIAAAAAAAAQ8AQAAAAQAAAAAAAR8AQAAAAD AAAADwAE8GwAAACiDArwCAAAADUEAAAACgAAgwAL8DAAAAB/AAAABACAAAAABwC/AAIAAgCB AQDMmQC/AQAAEADAATOZMwD/AQAACAABAgAAAAAAABDwBAAAAA8AAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAABwAPAATwbAAAABIACvAIAAAANgQAAAAKAACjAAvwPAAAAH8AAAAEAIUAAgAA AIcAAQAAAIEBAMyZAL8BAAAQAMABM5kzAMsB1JQAAM4BCAAAAP8BCAAIAAECAAAAAAAAEPAE AAAADgAAAAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAAA3BAAAAAoAAIMAC/AwAAAAfwAA AAQAgAAAAAYAvwACAAIAgQEAzJkAvwEAABAAwAEzmTMA/wEAAAgAAQIAAAAAAAAQ8AQAAAAN AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAAYADwAE8GwAAAASAArwCAAAADgEAAAACgAAowAL 8DwAAAB/AAAABACFAAIAAACHAAEAAACBAQDMmQC/AQAAEADAATOZMwDLAdSUAADOAQgAAAD/ AQgACAABAgAAAAAAABDwBAAAAAwAAAAAABHwBAAAAAMAAAAPAATwbAAAAKIMCvAIAAAAOQQA AAAKAACDAAvwMAAAAH8AAAAEAIAAAAAFAL8AAgACAIEBAMyZAL8BAAAQAMABM5kzAP8BAAAI AAECAAAAAAAAEPAEAAAACwAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAFAA8ABPBsAAAAEgAK 8AgAAAA6BAAAAAoAAKMAC/A8AAAAfwAAAAQAhQACAAAAhwABAAAAgQEAzJkAvwEAABAAwAEz mTMAywHUlAAAzgEIAAAA/wEIAAgAAQIAAAAAAAAQ8AQAAAAKAAAAAAAR8AQAAAADAAAADwAE 8GwAAACiDArwCAAAADsEAAAACgAAgwAL8DAAAAB/AAAABACAAAAABAC/AAIAAgCBAQDMmQC/ AQAAEADAATOZMwD/AQAACAABAgAAAAAAABDwBAAAAAkAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAABAAPAATwBAEAAAIACvAIAAAAPAQAAAAKAABzAQvwwAAAAH8AAAAEAEIBBgUAAEMB7gYA AEQBBAAAAEXBHAAAAEbBFAAAAH8BAQABAIEBAMyZAIMB////AL8BAAAQAMABMzPMAMQBAAAA AMsB1JQAAM0BAAAAANABAQAAANEBAQAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAAP8BGAAY AAECAAAAAIgDAAAAAAcABwDw/6QAAABSAHACAADgBLsA5wV2Ae4GPgOMBgYFKgYHAAgAAgAA QACtASAArQEgAKwAgCMAIvEMAAAAjwMAAAAAkQMAAAAAAAAQ8AQAAAAIAAAAAAAR8AQAAAAD AAAADwAE8GYAAACiDArwCAAAAD0EAAAACgAAcwAL8CoAAAB/AAAABACAAAAAAwC/AAIAAgCB AQDMmQC/AQAAEAD/AQgACAABAgAAAAAAABDwBAAAAAcAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAAwAPAATwZgAAAKIMCvAIAAAAPgQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAACAL8AAgAC AIEBAMyZAL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAABQAAAAAAEfAEAAAABAAAAAAADfAE AAAAAAACAA8ABPBmAAAAogwK8AgAAAA/BAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAAAEAvwAC AAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAAAGAAAAAAAR8AQAAAAEAAAAAAAN 8AQAAAAAAAEADwAE8GYAAAASAArwCAAAAEAEAAAACgAAcwAL8CoAAAB/AAEABQCAAAAAIQCH AAEAAACBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAAABDwBAAAACoAAAAAABHwBAAAAAIAAAAA AA3wBAAAAAAAIQAPAATwYAAAABIACvAIAAAAVwQAAAAKAABjAAvwJAAAAH8AAAAFAIAAAAAU AIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAAKQAAAAAAEfAEAAAAAgAAAAAADfAE AAAAAAAUAA8ABPBmAAAAogwK8AgAAABYBAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAABMAvwAC AAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAAArAAAAAAAR8AQAAAACAAAAAAAN 8AQAAAAAABMADwAE8GYAAACiDArwCAAAAFkEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAIgC/ AAIAAgCBAQDMmQC/AQAAEAD/AQAACAABAgAAAAAAABDwBAAAACgAAAAAABHwBAAAAAIAAAAA AA3wBAAAAAAAIgAPAATwZgAAABIACvAIAAAAWgQAAAAKAABzAAvwKgAAAH8AAQAFAIAAAAA5 AIcAAQAAAIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAALwAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAAA5AA8ABPBgAAAAEgAK8AgAAAB7BAAAAAoAAGMAC/AkAAAAfwAAAAUAgAAA ACQAgQEAzJkAvwEAABEA/wEAAAkAAQIAAAAAAAAQ8AQAAAAuAAAAAAAR8AQAAAADAAAAAAAN 8AQAAAAAACQADwAE8GYAAACiDArwCAAAAHwEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAIwC/ AAIAAgCBAQDMmQC/AQAAEAD/AQAACAABAgAAAAAAABDwBAAAAC0AAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAIwAPAATwZgAAABIACvAIAAAAfQQAAAAKAABzAAvwKgAAAH8AAQAFAIAAAABM AIcAAQAAAIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAAMwAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAABMAA8AA/C6DAAADwAE8IoAAAABAAnwEAAAAJEDAADAAgAAqBUAAHALAAAC AArwCAAAAH4EAAABAgAAIwAL8AwAAAB/AAAABACIAwAAAABDACLxLgAAAI8DAAAAAJEDAAAA AJ8DAwAAAKDDFgAAAAQACAAEAKsAAAALAgAA0wIAAKMCAAAAABDwBAAAADEAAAAAABHwBAAA AAEAAAAPAATweAAAABIACvAIAAAAfwQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABLAL8AAAAC AIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAqBAAAKcIAACoFQAAcAsA AAAAEfAEAAAABQAAAAAADfAEAAAAAABLAA8ABPB4AAAAEgAK8AgAAACABAAAAgoAAIMAC/Aw AAAAfwAAAAQAgAAAAEoAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP 8BAAAACyCwAApwgAAKgQAABwCwAAAAAR8AQAAAAFAAAAAAAN8AQAAAAAAEoADwAE8HgAAAAS AArwCAAAAIEEAAACCgAAgwAL8DAAAAB/AAAABACAAAAASQC/AAAAAgCBAQDMmQC/AQEAFQD/ AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAHQHAACnCAAAsgsAAHALAAAAABHwBAAAAAUAAAAA AA3wBAAAAAAASQAPAATweAAAABIACvAIAAAAggQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABI AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAkQMAAKcIAAB0 BwAAcAsAAAAAEfAEAAAABQAAAAAADfAEAAAAAABIAA8ABPB4AAAAEgAK8AgAAACDBAAAAgoA AIMAC/AwAAAAfwAAAAQAgAAAAEcAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIA AAIAAAAP8BAAAACoEAAA1AUAAKgVAACnCAAAAAAR8AQAAAAFAAAAAAAN8AQAAAAAAEcADwAE 8HgAAAASAArwCAAAAIQEAAACCgAAgwAL8DAAAAB/AAAABACAAAAARgC/AAAAAgCBAQDMmQC/ AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAALILAADUBQAAqBAAAKcIAAAAABHwBAAA AAUAAAAAAA3wBAAAAAAARgAPAATweAAAABIACvAIAAAAhQQAAAIKAACDAAvwMAAAAH8AAAAE AIAAAABFAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAdAcA ANQFAACyCwAApwgAAAAAEfAEAAAABQAAAAAADfAEAAAAAABFAA8ABPB4AAAAEgAK8AgAAACG BAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAEQAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIA AAAAPwIAAAIAAAAP8BAAAACRAwAA1AUAAHQHAACnCAAAAAAR8AQAAAAFAAAAAAAN8AQAAAAA AEQADwAE8HgAAAASAArwCAAAAIcEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAQwC/AAAAAgCB AQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAKgQAACvAwAAqBUAANQFAAAA ABHwBAAAAAUAAAAAAA3wBAAAAAAAQwAPAATweAAAABIACvAIAAAAiAQAAAIKAACDAAvwMAAA AH8AAAAEAIAAAABCAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQ AAAAsgsAAK8DAACoEAAA1AUAAAAAEfAEAAAABQAAAAAADfAEAAAAAABCAA8ABPB4AAAAEgAK 8AgAAACJBAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAEEAvwAAAAIAgQEAzJkAvwEBABUA/wEA AAgAAQIAAAAAPwIAAAIAAAAP8BAAAAB0BwAArwMAALILAADUBQAAAAAR8AQAAAAFAAAAAAAN 8AQAAAAAAEEADwAE8HgAAAASAArwCAAAAIoEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAQAC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAJEDAACvAwAAdAcA ANQFAAAAABHwBAAAAAUAAAAAAA3wBAAAAAAAQAAPAATweAAAABIACvAIAAAAiwQAAAIKAACD AAvwMAAAAH8AAAAEAIAAAAA/AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAAqBAAAMACAACoFQAArwMAAAAAEfAEAAAABQAAAAAADfAEAAAAAAA/AA8ABPB4 AAAAEgAK8AgAAACMBAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAD4AvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACyCwAAwAIAAKgQAACvAwAAAAAR8AQAAAAF AAAAAAAN8AQAAAAAAD4ADwAE8HgAAAASAArwCAAAAI0EAAACCgAAgwAL8DAAAAB/AAAABACA AAAAPQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAHQHAADA AgAAsgsAAK8DAAAAABHwBAAAAAUAAAAAAA3wBAAAAAAAPQAPAATweAAAABIACvAIAAAAjgQA AAIKAACDAAvwMAAAAH8AAAAEAIAAAAA8AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAAkQMAAMACAAB0BwAArwMAAAAAEfAEAAAABQAAAAAADfAEAAAAAAA8 AA8ABPBmAAAAQgEK8AgAAACPBAAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEI AAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAACRAwAAwAIAAKgVAADAAgAAAAAR8AQAAAAF AAAADwAE8GAAAABCAQrwCAAAAJAEAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAJEDAACvAwAAqBUAAK8DAAAAABHwBAAAAAUAAAAP AATwZgAAAEIBCvAIAAAAkQQAAAIKAABzAAvwKgAAAL8BAAAQAMsBn28AANcBAQAAAP8BCAAK AAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAAkQMAAHALAACoFQAAcAsAAAAAEfAEAAAABQAA AA8ABPBmAAAAQgEK8AgAAACSBAAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEI AAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAACRAwAAwAIAAJEDAABwCwAAAAAR8AQAAAAF AAAADwAE8GAAAABCAQrwCAAAAJMEAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAHQHAADAAgAAdAcAAHALAAAAABHwBAAAAAUAAAAP AATwYAAAAEIBCvAIAAAAlAQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAsgsAAMACAACyCwAAcAsAAAAAEfAEAAAABQAAAA8ABPBg AAAAQgEK8AgAAACVBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIA AAIAvwIAAAgAAAAP8BAAAACoEAAAwAIAAKgQAABwCwAAAAAR8AQAAAAFAAAADwAE8GYAAABC AQrwCAAAAJYEAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/ AgAAAgC/AgAACAAAAA/wEAAAAKgVAADAAgAAqBUAAHALAAAAABHwBAAAAAUAAAAPAATwYAAA AEIBCvAIAAAAlwQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAAC AL8CAAAIAAAAD/AQAAAAkQMAANQFAACoFQAA1AUAAAAAEfAEAAAABQAAAA8ABPBgAAAAQgEK 8AgAAACYBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIA AAgAAAAP8BAAAACRAwAApwgAAKgVAACnCAAAAAAR8AQAAAAFAAAADwAE8GAAAAASAArwCAAA AJkEAAAACgAAYwAL8CQAAAB/AAAABQCAAAAAOwCBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAA ABDwBAAAADAAAAAAABHwBAAAAAUAAAAAAA3wBAAAAAAAOwAPAATwZgAAAKIMCvAIAAAAmgQA AAAKAABzAAvwKgAAAH8AAAAEAIAAAAA6AL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAA AAAAEPAEAAAAMgAAAAAAEfAEAAAABQAAAAAADfAEAAAAAAA6AA8ABPBmAAAAEgAK8AgAAACb BAAAAAoAAHMAC/AqAAAAfwABAAUAgAAAAF8AhwABAAAAgQEAzJkAvwEAABEA/wEAAAkAAQIA AAAAAAAQ8AQAAAA3AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAF8ADwAE8GAAAAASAArwCAAA ALcEAAAACgAAYwAL8CQAAAB/AAAABQCAAAAATgCBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAA ABDwBAAAADYAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAATgAPAATwZgAAAKIMCvAIAAAAuAQA AAAKAABzAAvwKgAAAH8AAAAEAIAAAABNAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAA AAAAEPAEAAAANQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABNAA8ABPBmAAAAEgAK8AgAAAC5 BAAAAAoAAHMAC/AqAAAAfwABAAUAgAAAAG4AhwABAAAAgQEAzJkAvwEAABEA/wEAAAkAAQIA AAAAAAAQ8AQAAAA7AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAG4ADwAD8E4KAAAPAATwhgAA AAEACfAQAAAAygIAAPkCAADKFQAAOgoAAAIACvAIAAAAugQAAAECAAAjAAvwDAAAAH8AAAAE AIgDAAAAAEMAIvEqAAAAjwMAAAAAkQMAAAAAnwMDAAAAoMMSAAAAAwAEAAQAUQEAAAsCAADT AgAAAAAQ8AQAAAA6AAAAAAAR8AQAAAABAAAADwAE8HgAAAASAArwCAAAALsEAAACCgAAgwAL 8DAAAAB/AAAABACAAAAAbQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAA AA/wEAAAAPoSAABnBwAAyhUAADoKAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAbQAPAATweAAA ABIACvAIAAAAvAQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABsAL8AAAACAIEBAMyZAL8BAQAV AP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAUQ4AAGcHAAD6EgAAOgoAAAAAEfAEAAAAAwAA AAAADfAEAAAAAABsAA8ABPB4AAAAEgAK8AgAAAC9BAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAA AGsAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACxBgAAZwcA AFEOAAA6CgAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGsADwAE8HgAAAASAArwCAAAAL4EAAAC CgAAgwAL8DAAAAB/AAAABACAAAAAagC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/ AgAAAgAAAA/wEAAAAMoCAABnBwAAsQYAADoKAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAagAP AATweAAAABIACvAIAAAAvwQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABpAL8AAAACAIEBAMyZ AL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAA+hIAAJ4EAADKFQAAZwcAAAAAEfAE AAAAAwAAAAAADfAEAAAAAABpAA8ABPB4AAAAEgAK8AgAAADABAAAAgoAAIMAC/AwAAAAfwAA AAQAgAAAAGgAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABR DgAAngQAAPoSAABnBwAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGgADwAE8HgAAAASAArwCAAA AMEEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAZwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAAB AgAAAAA/AgAAAgAAAA/wEAAAALEGAACeBAAAUQ4AAGcHAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAZwAPAATweAAAABIACvAIAAAAwgQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABmAL8AAAAC AIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAygIAAJ4EAACxBgAAZwcA AAAAEfAEAAAAAwAAAAAADfAEAAAAAABmAA8ABPB4AAAAEgAK8AgAAADDBAAAAgoAAIMAC/Aw AAAAfwAAAAQAgAAAAGUAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP 8BAAAAD6EgAA+QIAAMoVAACeBAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGUADwAE8HgAAAAS AArwCAAAAMQEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAZAC/AAAAAgCBAQDMmQC/AQEAFQD/ AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAFEOAAD5AgAA+hIAAJ4EAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAZAAPAATweAAAABIACvAIAAAAxQQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABj AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAsQYAAPkCAABR DgAAngQAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABjAA8ABPB4AAAAEgAK8AgAAADGBAAAAgoA AIMAC/AwAAAAfwAAAAQAgAAAAGIAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIA AAIAAAAP8BAAAADKAgAA+QIAALEGAACeBAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGIADwAE 8GYAAABCAQrwCAAAAMcEAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAMoCAAD5AgAAyhUAAPkCAAAAABHwBAAAAAMAAAAP AATwYAAAAEIBCvAIAAAAyAQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAygIAAJ4EAADKFQAAngQAAAAAEfAEAAAAAwAAAA8ABPBm AAAAQgEK8AgAAADJBAAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEIAAoAAQIA AAAAPwIAAAIAvwIAAAgAAAAP8BAAAADKAgAAOgoAAMoVAAA6CgAAAAAR8AQAAAADAAAADwAE 8GYAAABCAQrwCAAAAMoEAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAMoCAAD5AgAAygIAADoKAAAAABHwBAAAAAMAAAAP AATwYAAAAEIBCvAIAAAAywQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAsQYAAPkCAACxBgAAOgoAAAAAEfAEAAAAAwAAAA8ABPBg AAAAQgEK8AgAAADMBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIA AAIAvwIAAAgAAAAP8BAAAABRDgAA+QIAAFEOAAA6CgAAAAAR8AQAAAADAAAADwAE8GAAAABC AQrwCAAAAM0EAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/ AgAACAAAAA/wEAAAAPoSAAD5AgAA+hIAADoKAAAAABHwBAAAAAMAAAAPAATwZgAAAEIBCvAI AAAAzgQAAAIKAABzAAvwKgAAAL8BAAAQAMsBn28AANcBAQAAAP8BCAAKAAECAAAAAD8CAAAC AL8CAAAIAAAAD/AQAAAAyhUAAPkCAADKFQAAOgoAAAAAEfAEAAAAAwAAAA8ABPBgAAAAQgEK 8AgAAADPBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIA AAgAAAAP8BAAAADKAgAAZwcAAMoVAABnBwAAAAAR8AQAAAADAAAADwAE8GAAAAASAArwCAAA ANAEAAAACgAAYwAL8CQAAAB/AAAABQCAAAAAYQCBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAA ABDwBAAAADkAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAYQAPAATwZgAAAKIMCvAIAAAA0QQA AAAKAABzAAvwKgAAAH8AAAAEAIAAAABgAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAA AAAAEPAEAAAAOAAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABgAA8ABPBmAAAAEgAK8AgAAADS BAAAAAoAAHMAC/AqAAAAfwABAAUAgAAAAIIAhwABAAAAgQEAzJkAvwEAABEA/wEAAAkAAQIA AAAAAAAQ8AQAAABgAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAIIADwAE8GYAAACiDArwCAAA ANMEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAgQC/AAIAAgCBAQDMmQC/AQAAEAD/AQgACAAB AgAAAAAAABDwBAAAAF8AAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAgQAPAATwZgAAAEIBCvAI AAAA1AQAAAAKAACTAAvwNgAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMsBPt8AANABAQAA ANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAXgAAAAAAEfAEAAAAAwAAAA8ABPBmAAAAogwK 8AgAAADVBAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAAIAAvwACAAIAgQEAzJkAvwEAABAA/wEA AAgAAQIAAAAAAAAQ8AQAAABdAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAIAADwAE8GwAAACi DArwCAAAANYEAAAACgAAgwAL8DAAAAB/AAAABACAAAAAfwC/AAIAAgCBAQDMmQC/AQAAEADA ATMzzAD/AQgACAABAgAAAAAAABDwBAAAAFwAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAfwAP AATwZgAAAEIBCvAIAAAA1wQAAAAKAACTAAvwNgAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQ AMsBPt8AANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAWwAAAAAAEfAEAAAAAwAA AA8ABPBmAAAAogwK8AgAAADYBAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAAH4AvwACAAIAgQEA zJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAABaAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAA AH4ADwAE8GwAAACiDArwCAAAANkEAAAACgAAgwAL8DAAAAB/AAAABACAAAAAfQC/AAIAAgCB AQDMmQC/AQAAEADAAf8AAAD/AQgACAABAgAAAAAAABDwBAAAAFkAAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAfQAPAATwbAAAAEIBCvAIAAAA2gQAAAAKAACjAAvwPAAAAH8AAAAEAEQBBAAA AH8BAAABAL8BAAAQAMAB/wAAAMsBPt8AANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAE AAAAWAAAAAAAEfAEAAAAAwAAAA8ABPBmAAAAogwK8AgAAADbBAAAAAoAAHMAC/AqAAAAfwAA AAQAgAAAAHwAvwACAAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAABXAAAAAAAR 8AQAAAADAAAAAAAN8AQAAAAAAHwADwAE8GwAAACiDArwCAAAANwEAAAACgAAgwAL8DAAAAB/ AAAABACAAAAAewC/AAIAAgCBAQDMmQC/AQAAEADAATMzzAD/AQgACAABAgAAAAAAABDwBAAA AFYAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAewAPAATwbAAAAKIMCvAIAAAA3QQAAAAKAACD AAvwMAAAAH8AAAAEAIAAAAB6AL8AAgACAIEBAMyZAL8BAAAQAMABMzPMAP8BCAAIAAECAAAA AAAAEPAEAAAAVQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAB6AA8ABPBmAAAAMgAK8AgAAADe BAAAAAoAAJMAC/A2AAAAfwAAAAQAhQACAAAAhwABAAAAgQEAzJkAvwEAABAAwAH/AAAAywFq SgAA/wEIAAgAAQIAAAAAAAAQ8AQAAABUAAAAAAAR8AQAAAADAAAADwAE8GwAAACiDArwCAAA AN8EAAAACgAAgwAL8DAAAAB/AAAABACAAAAAeQC/AAIAAgCBAQDMmQC/AQAAEADAATMzzAD/ AQAACAABAgAAAAAAABDwBAAAAFMAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAeQAPAATwbAAA AKIMCvAIAAAA4AQAAAAKAACDAAvwMAAAAH8AAAAEAIAAAAB4AL8AAgACAIEBAMyZAL8BAAAQ AMABMzPMAP8BCAAIAAECAAAAAAAAEPAEAAAAUgAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAB4 AA8ABPBsAAAAQgEK8AgAAADhBAAAAAoAAKMAC/A8AAAAfwAAAAQARAEEAAAAfwEAAAEAvwEA ABAAwAEzM8wAywE+3wAA0AEBAAAA0QEBAAAA/wEYABgAAQIAAAAAAAAQ8AQAAABRAAAAAAAR 8AQAAAADAAAADwAE8HIAAABCAQrwCAAAAOIEAAAACgAAswAL8EIAAAAEACcaMQB/AAAABABE AQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgAAAAAA ABDwBAAAAFAAAAAAABHwBAAAAAMAAAAPAATwcgAAAEIBCvAIAAAA4wQAAAAKAACzAAvwQgAA AAQAo1HE/38AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsBPt8AANABAQAAANEBAQAA AP8BGAAYAAECAAAAAAAAEPAEAAAATwAAAAAAEfAEAAAAAwAAAA8ABPByAAAAQgEK8AgAAADk BAAAQAoAALMAC/BCAAAABADZ5c7/fwAAAAQARAEEAAAAfwEAAAEAvwEAABAAwAH/AAAAywE+ 3wAA0AEBAAAA0QEBAAAA/wEYABgAAQIAAAAAAAAQ8AQAAABOAAAAAAAR8AQAAAADAAAADwAE 8GwAAAASAArwCAAAAOUEAAAACgAAowAL8DwAAAB/AAAABACFAAIAAACHAAEAAACBAQDMmQC/ AQAAEADAATOZMwDLAdSUAADOAQgAAAD/AQgACAABAgAAAAAAABDwBAAAAE0AAAAAABHwBAAA AAMAAAAPAATwbAAAAKIMCvAIAAAA5gQAAAAKAACDAAvwMAAAAH8AAAAEAIAAAAB3AL8AAgAC AIEBAMyZAL8BAAAQAMABM5kzAP8BAAAIAAECAAAAAAAAEPAEAAAATAAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAAB3AA8ABPBsAAAAEgAK8AgAAADnBAAAAAoAAKMAC/A8AAAAfwAAAAQAhQAC AAAAhwABAAAAgQEAzJkAvwEAABAAwAEzmTMAywHUlAAAzgEIAAAA/wEIAAgAAQIAAAAAAAAQ 8AQAAABLAAAAAAAR8AQAAAADAAAADwAE8GwAAACiDArwCAAAAOgEAAAACgAAgwAL8DAAAAB/ AAAABACAAAAAdgC/AAIAAgCBAQDMmQC/AQAAEADAATOZMwD/AQAACAABAgAAAAAAABDwBAAA AEoAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAdgAPAATwbAAAABIACvAIAAAA6QQAAAAKAACj AAvwPAAAAH8AAAAEAIUAAgAAAIcAAQAAAIEBAMyZAL8BAAAQAMABM5kzAMsB1JQAAM4BCAAA AP8BCAAIAAECAAAAAAAAEPAEAAAASQAAAAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAADq BAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAHUAvwACAAIAgQEAzJkAvwEAABAAwAEzmTMA/wEA AAgAAQIAAAAAAAAQ8AQAAABIAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAHUADwAE8GwAAAAS AArwCAAAAOsEAAAACgAAowAL8DwAAAB/AAAABACFAAIAAACHAAEAAACBAQDMmQC/AQAAEADA ATOZMwDLAdSUAADOAQgAAAD/AQgACAABAgAAAAAAABDwBAAAAEcAAAAAABHwBAAAAAMAAAAP AATwBAEAAAIACvAIAAAA7AQAAAAKAABzAQvwwAAAAH8AAAAEAEIBBgUAAEMB7gYAAEQBBAAA AEXBHAAAAEbBFAAAAH8BAQABAIEBAMyZAIMB////AL8BAAAQAMABMzPMAMQBAAAAAMsB1JQA AM0BAAAAANABAQAAANEBAQAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAAP8BGAAYAAECAAAA AIgDAAAAAAcABwDw/6QAAABSAHACAADgBLsA5wV2Ae4GPgOMBgYFKgYHAAgAAgAAQACtASAA rQEgAKwAgCMAIvEMAAAAjwMAAAAAkQMAAAAAAAAQ8AQAAABGAAAAAAAR8AQAAAADAAAADwAE 8GwAAACiDArwCAAAAO0EAAAACgAAgwAL8DAAAAB/AAAABACAAAAAdAC/AAIAAgCBATOZMwC/ AQAAEADAAcwAAAD/AQgACAABAgAAAAAAABDwBAAAAEUAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAdAAPAATwYAAAAEIBCvAIAAAA7gQAAEAKAACDAAvwMAAAAH8AAAAEAEQBBAAAAH8BAAAB AL8BAAAQAMABzAAAAMsBakoAAP8BGAAYAAECAAAAAAAAEPAEAAAARAAAAAAAEfAEAAAAAwAA AA8ABPBgAAAAQgEK8AgAAADvBAAAQAoAAIMAC/AwAAAAfwAAAAQARAEEAAAAfwEAAAEAvwEA ABAAwAHMAAAAywFqSgAA/wEYABgAAQIAAAAAAAAQ8AQAAABDAAAAAAAR8AQAAAADAAAADwAE 8GYAAACiDArwCAAAAPAEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAcwC/AAIAAgC/ARAAEADA AcwAAAD/AQgACAABAgAAAAAAABDwBAAAAEIAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAcwAP AATwZgAAAKIMCvAIAAAA8QQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAByAL8AAgACAL8BEAAQ AMABzAAAAP8BCAAIAAECAAAAAAAAEPAEAAAAQQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABy AA8ABPBgAAAAQgEK8AgAAADyBAAAQAoAAIMAC/AwAAAAfwAAAAQARAEEAAAAfwEAAAEAvwEA ABAAwAHMAAAAywFqSgAA/wEYABgAAQIAAAAAAAAQ8AQAAABAAAAAAAAR8AQAAAADAAAADwAE 8GYAAACiDArwCAAAAPMEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAcQC/AAIAAgC/ARAAEADA AcwAAAD/AQgACAABAgAAAAAAABDwBAAAAD8AAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAcQAP AATwYAAAAEIBCvAIAAAA9AQAAEAKAACDAAvwMAAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQ AMABzAAAAMsBakoAAP8BGAAYAAECAAAAAAAAEPAEAAAAPgAAAAAAEfAEAAAAAwAAAA8ABPBs AAAAogwK8AgAAAD1BAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAHAAvwACAAIAgQEAzJkAvwEA ABAAwAEzmTMA/wEAAAgAAQIAAAAAAAAQ8AQAAAA9AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAA AHAADwAE8GYAAACiDArwCAAAAPYEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAbwC/AAIAAgCB AQDMmQC/AQAAEAD/AQAACAABAgAAAAAAABDwBAAAADwAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAbwAPAATwZgAAAKIMCvAIAAAAJAUAAAAKAABzAAvwKgAAAH8AAAAEAIAAAACDAL8AAgAC AIEBAMyZAL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAAYgAAAAAAEfAEAAAAAwAAAAAADfAE AAAAAACDAA8ABPBsAAAAEgAK8AgAAABTBQAAAAoAAIMAC/AwAAAAfwABAAUAgAAAAJsAhwAB AAAAgQEAzJkAvwEAABEAwAEAAP8A/wEAAAkAAQIAAAAAAAAQ8AQAAAACAAAAAAAR8AQAAAAD AAAAAAAN8AQAAAAAAJsADwAD8JIFAAAPAATwaAAAAAEACfAQAAAAEAMAANADAAD4EwAAmQ4A AAIACvAIAAAAVAUAAAECAAAjAAvwDAAAAH8AAAAEAIgDAAAAACMAIvEMAAAAjwMAAAAAkQMA AAAAAAAQ8AQAAAABAAAAAAAR8AQAAAABAAAADwAE8IQAAABCAQrwCAAAAFUFAAACCgAAwwAL 8EgAAABEAQQAAAB/AQAAAQC/AQAAEADAARJDzgDLAdSUAADSAQAAAADTAQAAAADUAQAAAADV AQAAAAD/ARgAGAABAgAAAAA/AgAAAgAAAA/wEAAAAJgDAAC4BAAASAgAALAIAAAAABHwBAAA AAMAAAAPAATwhAAAAEIBCvAIAAAAVgUAAIIKAADDAAvwSAAAAEQBBAAAAH8BAAABAL8BAAAQ AMABEkPOAMsBn28AANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BGAAYAAECAAAAAD8CAAAC AAAAD/AQAAAAGAoAAIgEAAAoDwAAkAgAAAAAEfAEAAAAAwAAAA8ABPCKAAAAMgAK8AgAAABX BQAAAgoAANMAC/BOAAAAhQACAAAAhwABAAAAgQEAzJkAvwEAABAAwAGlACEAywGfbwAA0gEA AAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEIAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAC4BwAAaAgA AJAKAAAACgAAAAAR8AQAAAADAAAADwAE8JAAAACiDArwCAAAAFgFAAACCgAAwwAL8EgAAACA AAAAmgC/AAIAAgCBAQDMmQC/AQAAEADAAQAA/wDSAQAAAADTAQAAAADUAQAAAADVAQAAAAD/ AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAACgIAACoCAAAoAoAAI8JAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAmgAPAATwkAAAAKIMCvAIAAAAWQUAAAIKAADDAAvwSAAAAIAAAACZAL8AAgAC AIEBAMyZAL8BAAAQAMABAAD/ANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAAgAQAANADAAAwDgAAEQYAAAAAEfAEAAAAAwAAAAAADfAEAAAAAACZ AA8ABPCEAAAAQgEK8AgAAABaBQAAQgoAAMMAC/BIAAAARAEEAAAAfwEAAAEAvwEAABAAwAEA MwAAywGfbwAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEYABgAAQIAAAAAPwIAAAIAAAAP 8BAAAAAQAwAA0AkAACAIAAAYDQAAAAAR8AQAAAADAAAADwAE8IQAAABCAQrwCAAAAFsFAAAC CgAAwwAL8EgAAABEAQQAAAB/AQAAAQC/AQAAEADAAQAzAADLAZ9vAADSAQAAAADTAQAAAADU AQAAAADVAQAAAAD/ARgAGAABAgAAAAA/AgAAAgAAAA/wEAAAADAKAADACQAAiA8AAGANAAAA ABHwBAAAAAMAAAAPAATwkAAAAKIMCvAIAAAAXAUAAAIKAADDAAvwSAAAAIAAAACYAL8AAgAC AIEBAMyZAL8BAAAQAMABAAD/ANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAASAQAAFgMAAD4DQAAmQ4AAAAAEfAEAAAAAwAAAAAADfAEAAAAAACY AA8ABPCQAAAAogwK8AgAAABdBQAAAgoAAMMAC/BIAAAAgAAAAJcAvwACAAIAgQEAzJkAvwEA ABAAwAEAAP8A0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEAAAgAAQIAAAAAPwIAAAIAAAAP 8BAAAABICgAA+AcAAPgTAAA5CgAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAJcADwAE8IoAAABC AQrwCAAAAF4FAAAACgAA8wAL8FoAAAB/AAAABABEAQQAAAB/AQAAAQC/AQAAEADAARJDzgDL AZ9vAADOAQYAAADRAQEAAADSAQAAAADTAQAAAADUAQAAAADVAQAAAAD/ARgAGAABAgAAAAA/ AgAAAgAAABDwBAAAAAAAAAAAABHwBAAAAAMAAAAPAATwigAAAEIBCvAIAAAAXwUAAAAKAADz AAvwWgAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMABADMAAMsBn28AAM4BBgAAANEBAQAA ANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BGAAYAAECAAAAAD8CAAACAAAAEPAEAAAABAAA AAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAABgBQAAAAoAAIMAC/AwAAAAfwAAAAQAgAAA AJYAvwACAAIAgQEAzJkAvwEAABAAwAEAAP8A/wEAAAgAAQIAAAAAAAAQ8AQAAAADAAAAAAAR 8AQAAAADAAAAAAAN8AQAAAAAAJYADwAE8GYAAAASAArwCAAAAGEFAAAACgAAcwAL8CoAAAB/ AAEABQCAAAAAlQCHAAEAAACBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAAABDwBAAAACYAAAAA ABHwBAAAAAUAAAAAAA3wBAAAAAAAlQAPAATwYAAAABIACvAIAAAAYgUAAAAKAABjAAvwJAAA AH8AAQAFAIAAAACUAIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAAJQAAAAAAEfAE AAAACwAAAAAADfAEAAAAAACUAA8ABPBmAAAAogwK8AgAAABjBQAAAAoAAHMAC/AqAAAAfwAA AAQAgAAAAJMAvwACAAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAAAkAAAAAAAR 8AQAAAACAAAAAAAN8AQAAAAAAJMADwAD8E4KAAAPAATwhgAAAAEACfAQAAAAvAIAAJMDAAC3 EwAAzAgAAAIACvAIAAAAZAUAAAECAAAjAAvwDAAAAH8AAAAEAIgDAAAAAEMAIvEqAAAAjwMA AAAAkQMAAAAAnwMDAAAAoMMSAAAAAwAEAAQAsQAAANEBAADpAQAAAAAQ8AQAAAAnAAAAAAAR 8AQAAAABAAAADwAE8HgAAAASAArwCAAAAGUFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAIAC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAE4PAACnBgAAtxMA AMwIAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAIAAPAATweAAAABIACvAIAAAAZgUAAAIKAACD AAvwMAAAAH8AAAAEAIAAAAAfAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAATgoAAKcGAABODwAAzAgAAAAAEfAEAAAABAAAAAAADfAEAAAAAAAfAA8ABPB4 AAAAEgAK8AgAAABnBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAB4AvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAB6BgAApwYAAE4KAADMCAAAAAAR8AQAAAAE AAAAAAAN8AQAAAAAAB4ADwAE8HgAAAASAArwCAAAAGgFAAACCgAAgwAL8DAAAAB/AAAABACA AAAAHQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAALwCAACn BgAAegYAAMwIAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAHQAPAATweAAAABIACvAIAAAAaQUA AAIKAACDAAvwMAAAAH8AAAAEAIAAAAAcAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAATg8AAIIEAAC3EwAApwYAAAAAEfAEAAAABAAAAAAADfAEAAAAAAAc AA8ABPB4AAAAEgAK8AgAAABqBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAABsAvwAAAAIAgQEA zJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABOCgAAggQAAE4PAACnBgAAAAAR 8AQAAAAEAAAAAAAN8AQAAAAAABsADwAE8HgAAAASAArwCAAAAGsFAAACCgAAgwAL8DAAAAB/ AAAABACAAAAAGgC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAA AHoGAACCBAAATgoAAKcGAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAGgAPAATweAAAABIACvAI AAAAbAUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAAAZAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAI AAECAAAAAD8CAAACAAAAD/AQAAAAvAIAAIIEAAB6BgAApwYAAAAAEfAEAAAABAAAAAAADfAE AAAAAAAZAA8ABPB4AAAAEgAK8AgAAABtBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAABgAvwAA AAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABODwAAkwMAALcTAACC BAAAAAAR8AQAAAAEAAAAAAAN8AQAAAAAABgADwAE8HgAAAASAArwCAAAAG4FAAACCgAAgwAL 8DAAAAB/AAAABACAAAAAFwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAA AA/wEAAAAE4KAACTAwAATg8AAIIEAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAFwAPAATweAAA ABIACvAIAAAAbwUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAAAWAL8AAAACAIEBAMyZAL8BAQAV AP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAegYAAJMDAABOCgAAggQAAAAAEfAEAAAABAAA AAAADfAEAAAAAAAWAA8ABPB4AAAAEgAK8AgAAABwBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAA ABUAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAC8AgAAkwMA AHoGAACCBAAAAAAR8AQAAAAEAAAAAAAN8AQAAAAAABUADwAE8GYAAABCAQrwCAAAAHEFAAAC CgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAA AA/wEAAAALwCAACTAwAAtxMAAJMDAAAAABHwBAAAAAQAAAAPAATwYAAAAEIBCvAIAAAAcgUA AAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQ AAAAvAIAAIIEAAC3EwAAggQAAAAAEfAEAAAABAAAAA8ABPBmAAAAQgEK8AgAAABzBQAAAgoA AHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP 8BAAAAC8AgAAzAgAALcTAADMCAAAAAAR8AQAAAAEAAAADwAE8GYAAABCAQrwCAAAAHQFAAAC CgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAA AA/wEAAAALwCAACTAwAAvAIAAMwIAAAAABHwBAAAAAQAAAAPAATwYAAAAEIBCvAIAAAAdQUA AAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQ AAAAegYAAJMDAAB6BgAAzAgAAAAAEfAEAAAABAAAAA8ABPBgAAAAQgEK8AgAAAB2BQAAAgoA AGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAABO CgAAkwMAAE4KAADMCAAAAAAR8AQAAAAEAAAADwAE8GAAAABCAQrwCAAAAHcFAAACCgAAYwAL 8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAE4PAACT AwAATg8AAMwIAAAAABHwBAAAAAQAAAAPAATwZgAAAEIBCvAIAAAAeAUAAAIKAABzAAvwKgAA AL8BAAAQAMsBn28AANcBAQAAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAAtxMA AJMDAAC3EwAAzAgAAAAAEfAEAAAABAAAAA8ABPBgAAAAQgEK8AgAAAB5BQAAAgoAAGMAC/Ak AAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAC8AgAApwYA ALcTAACnBgAAAAAR8AQAAAAEAAAADwAD8CYPAAAPAATwjgAAAAEACfAQAAAALQIAALgCAABE FAAAoQwAAAIACvAIAAAAegUAAAECAAAjAAvwDAAAAH8AAAAEAIgDAAAAAEMAIvEyAAAAjwMA AAAAkQMAAAAAnwMDAAAAoMMaAAAABQAIAAQAqwAAAAsCAAA9AgAAHQIAAM8BAAAAABDwBAAA ACwAAAAAABHwBAAAAAEAAAAPAATweAAAABIACvAIAAAAewUAAAIKAACDAAvwMAAAAH8AAAAE AIAAAACgAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAARA8A ANIKAABEFAAAoQwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACgAA8ABPB4AAAAEgAK8AgAAAB8 BQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAJ8AvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIA AAAAPwIAAAIAAAAP8BAAAABOCgAA0goAAEQPAAChDAAAAAAR8AQAAAACAAAAAAAN8AQAAAAA AJ8ADwAE8HgAAAASAArwCAAAAH0FAAACCgAAgwAL8DAAAAB/AAAABACAAAAAngC/AAAAAgCB AQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAK8FAADSCgAATgoAAKEMAAAA ABHwBAAAAAIAAAAAAA3wBAAAAAAAngAPAATweAAAABIACvAIAAAAfgUAAAIKAACDAAvwMAAA AH8AAAAEAIAAAACdAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQ AAAALQIAANIKAACvBQAAoQwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACdAA8ABPB4AAAAEgAK 8AgAAAB/BQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAJwAvwAAAAIAgQEAzJkAvwEBABUA/wEA AAgAAQIAAAAAPwIAAAIAAAAP8BAAAABEDwAArQgAAEQUAADSCgAAAAAR8AQAAAACAAAAAAAN 8AQAAAAAAJwADwAE8HgAAAASAArwCAAAAIAFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAkgC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAE4KAACtCAAARA8A ANIKAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAkgAPAATweAAAABIACvAIAAAAgQUAAAIKAACD AAvwMAAAAH8AAAAEAIAAAACRAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAArwUAAK0IAABOCgAA0goAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACRAA8ABPB4 AAAAEgAK8AgAAACCBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAJAAvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAAtAgAArQgAAK8FAADSCgAAAAAR8AQAAAAC AAAAAAAN8AQAAAAAAJAADwAE8HgAAAASAArwCAAAAIMFAAACCgAAgwAL8DAAAAB/AAAABACA AAAAjwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAEQPAABw BgAARBQAAK0IAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAjwAPAATweAAAABIACvAIAAAAhAUA AAIKAACDAAvwMAAAAH8AAAAEAIAAAACOAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAATgoAAHAGAABEDwAArQgAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACO AA8ABPB4AAAAEgAK8AgAAACFBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAI0AvwAAAAIAgQEA zJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACvBQAAcAYAAE4KAACtCAAAAAAR 8AQAAAACAAAAAAAN8AQAAAAAAI0ADwAE8HgAAAASAArwCAAAAIYFAAACCgAAgwAL8DAAAAB/ AAAABACAAAAAjAC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAA AC0CAABwBgAArwUAAK0IAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAjAAPAATweAAAABIACvAI AAAAhwUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAACLAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAI AAECAAAAAD8CAAACAAAAD/AQAAAARA8AAKcDAABEFAAAcAYAAAAAEfAEAAAAAgAAAAAADfAE AAAAAACLAA8ABPB4AAAAEgAK8AgAAACIBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAIoAvwAA AAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABOCgAApwMAAEQPAABw BgAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAIoADwAE8HgAAAASAArwCAAAAIkFAAACCgAAgwAL 8DAAAAB/AAAABACAAAAAiQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAA AA/wEAAAAK8FAACnAwAATgoAAHAGAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAiQAPAATweAAA ABIACvAIAAAAigUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAACIAL8AAAACAIEBAMyZAL8BAQAV AP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAALQIAAKcDAACvBQAAcAYAAAAAEfAEAAAAAgAA AAAADfAEAAAAAACIAA8ABPB4AAAAEgAK8AgAAACLBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAA AIcAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABEDwAAuAIA AEQUAACnAwAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAIcADwAE8HgAAAASAArwCAAAAIwFAAAC CgAAgwAL8DAAAAB/AAAABACAAAAAhgC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/ AgAAAgAAAA/wEAAAAE4KAAC4AgAARA8AAKcDAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAhgAP AATweAAAABIACvAIAAAAjQUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAACFAL8AAAACAIEBAMyZ AL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAArwUAALgCAABOCgAApwMAAAAAEfAE AAAAAgAAAAAADfAEAAAAAACFAA8ABPB4AAAAEgAK8AgAAACOBQAAAgoAAIMAC/AwAAAAfwAA AAQAgAAAAIQAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAAt AgAAuAIAAK8FAACnAwAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAIQADwAE8GYAAABCAQrwCAAA AI8FAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/ AgAACAAAAA/wEAAAAC0CAAC4AgAARBQAALgCAAAAABHwBAAAAAIAAAAPAATwYAAAAEIBCvAI AAAAkAUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAI AAAAD/AQAAAALQIAAKcDAABEFAAApwMAAAAAEfAEAAAAAgAAAA8ABPBmAAAAQgEK8AgAAACR BQAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIA AAgAAAAP8BAAAAAtAgAAoQwAAEQUAAChDAAAAAAR8AQAAAACAAAADwAE8GYAAABCAQrwCAAA AJIFAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/ AgAACAAAAA/wEAAAAC0CAAC4AgAALQIAAKEMAAAAABHwBAAAAAIAAAAPAATwYAAAAEIBCvAI AAAAkwUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAI AAAAD/AQAAAArwUAALgCAACvBQAAoQwAAAAAEfAEAAAAAgAAAA8ABPBgAAAAQgEK8AgAAACU BQAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP 8BAAAABOCgAAuAIAAE4KAAChDAAAAAAR8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAJUFAAAC CgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAA AEQPAAC4AgAARA8AAKEMAAAAABHwBAAAAAIAAAAPAATwZgAAAEIBCvAIAAAAlgUAAAIKAABz AAvwKgAAAL8BAAAQAMsBn28AANcBAQAAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQ AAAARBQAALgCAABEFAAAoQwAAAAAEfAEAAAAAgAAAA8ABPBgAAAAQgEK8AgAAACXBQAAAgoA AGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAAt AgAAcAYAAEQUAABwBgAAAAAR8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAJgFAAACCgAAYwAL 8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAC0CAACt CAAARBQAAK0IAAAAABHwBAAAAAIAAAAPAATwYAAAAEIBCvAIAAAAmQUAAAIKAABjAAvwJAAA AL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAALQIAANIKAABE FAAA0goAAAAAEfAEAAAAAgAAAA8AA/C6DAAADwAE8IoAAAABAAnwEAAAAL8CAADkAQAAFxYA ADQMAAACAArwCAAAALoFAAABAgAAIwAL8AwAAAB/AAAABACIAwAAAABDACLxLgAAAI8DAAAA AJEDAAAAAJ8DAwAAAKDDFgAAAAQACAAEAFEBAAALAgAA0wIAAKMCAAAAABDwBAAAADQAAAAA ABHwBAAAAAEAAAAPAATweAAAABIACvAIAAAAuwUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABe AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAA4hEAAGsJAAAX FgAANAwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABeAA8ABPB4AAAAEgAK8AgAAAC8BQAAAgoA AIMAC/AwAAAAfwAAAAQAgAAAAF0AvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIA AAIAAAAP8BAAAACvDAAAawkAAOIRAAA0DAAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAF0ADwAE 8HgAAAASAArwCAAAAL0FAAACCgAAgwAL8DAAAAB/AAAABACAAAAAXAC/AAAAAgCBAQDMmQC/ AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAPwGAABrCQAArwwAADQMAAAAABHwBAAA AAIAAAAAAA3wBAAAAAAAXAAPAATweAAAABIACvAIAAAAvgUAAAIKAACDAAvwMAAAAH8AAAAE AIAAAABbAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAvwIA AGsJAAD8BgAANAwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABbAA8ABPB4AAAAEgAK8AgAAAC/ BQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFoAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIA AAAAPwIAAAIAAAAP8BAAAADiEQAA/gUAABcWAABrCQAAAAAR8AQAAAACAAAAAAAN8AQAAAAA AFoADwAE8HgAAAASAArwCAAAAMAFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAWQC/AAAAAgCB AQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAK8MAAD+BQAA4hEAAGsJAAAA ABHwBAAAAAIAAAAAAA3wBAAAAAAAWQAPAATweAAAABIACvAIAAAAwQUAAAIKAACDAAvwMAAA AH8AAAAEAIAAAABYAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQ AAAA/AYAAP4FAACvDAAAawkAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABYAA8ABPB4AAAAEgAK 8AgAAADCBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFcAvwAAAAIAgQEAzJkAvwEBABUA/wEA AAgAAQIAAAAAPwIAAAIAAAAP8BAAAAC/AgAA/gUAAPwGAABrCQAAAAAR8AQAAAACAAAAAAAN 8AQAAAAAAFcADwAE8HgAAAASAArwCAAAAMMFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAVgC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAOIRAAA1AwAAFxYA AP4FAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAVgAPAATweAAAABIACvAIAAAAxAUAAAIKAACD AAvwMAAAAH8AAAAEAIAAAABVAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAArwwAADUDAADiEQAA/gUAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABVAA8ABPB4 AAAAEgAK8AgAAADFBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFQAvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAD8BgAANQMAAK8MAAD+BQAAAAAR8AQAAAAC AAAAAAAN8AQAAAAAAFQADwAE8HgAAAASAArwCAAAAMYFAAACCgAAgwAL8DAAAAB/AAAABACA AAAAUwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAL8CAAA1 AwAA/AYAAP4FAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAUwAPAATweAAAABIACvAIAAAAxwUA AAIKAACDAAvwMAAAAH8AAAAEAIAAAABSAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAA4hEAAOQBAAAXFgAANQMAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABS AA8ABPB4AAAAEgAK8AgAAADIBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFEAvwAAAAIAgQEA zJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACvDAAA5AEAAOIRAAA1AwAAAAAR 8AQAAAACAAAAAAAN8AQAAAAAAFEADwAE8HgAAAASAArwCAAAAMkFAAACCgAAgwAL8DAAAAB/ AAAABACAAAAAUAC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAA APwGAADkAQAArwwAADUDAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAUAAPAATweAAAABIACvAI AAAAygUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABPAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAI AAECAAAAAD8CAAACAAAAD/AQAAAAvwIAAOQBAAD8BgAANQMAAAAAEfAEAAAAAgAAAAAADfAE AAAAAABPAA8ABPBmAAAAQgEK8AgAAADLBQAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEB AAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAC/AgAA5AEAABcWAADkAQAAAAAR 8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAMwFAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/ AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAL8CAAA1AwAAFxYAADUDAAAAABHwBAAA AAIAAAAPAATwZgAAAEIBCvAIAAAAzQUAAAIKAABzAAvwKgAAAL8BAAAQAMsBn28AANcBAQAA AP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAAvwIAADQMAAAXFgAANAwAAAAAEfAE AAAAAgAAAA8ABPBmAAAAQgEK8AgAAADOBQAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEB AAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAC/AgAA5AEAAL8CAAA0DAAAAAAR 8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAM8FAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/ AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAPwGAADkAQAA/AYAADQMAAAAABHwBAAA AAIAAAAPAATwYAAAAEIBCvAIAAAA0AUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAK AAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAArwwAAOQBAACvDAAANAwAAAAAEfAEAAAAAgAA AA8ABPBgAAAAQgEK8AgAAADRBQAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIA AAAAPwIAAAIAvwIAAAgAAAAP8BAAAADiEQAA5AEAAOIRAAA0DAAAAAAR8AQAAAACAAAADwAE 8GYAAABCAQrwCAAAANIFAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAABcWAADkAQAAFxYAADQMAAAAABHwBAAAAAIAAAAP AATwYAAAAEIBCvAIAAAA0wUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAvwIAAP4FAAAXFgAA/gUAAAAAEfAEAAAAAgAAAA8ABPBg AAAAQgEK8AgAAADUBQAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIA AAIAvwIAAAgAAAAP8BAAAAC/AgAAawkAABcWAABrCQAAAAAR8AQAAAACAAAADwAE8GAAAACy BArwCAAAAF8GAAAACgAAgwAL8DAAAAAEQQQAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAg/AgAAAgAAABDwBAAAAGEAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAI AAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAABBrAAARawAAEmsAABNrAAAUawAAFmsAABdrAAAYawAAGWsAABprAAAbawAAHGsA AB1rAAAeawAAH2sAACBrAAAhawAAImsAACNrAAAkawAAJWsAACZrAAAnawAAKGsAAClrAAAq awAAK2sAACxrAAAtawAALmsAAC9rAAAwawAAMWsAADJrAAAzawAANGsAADZrAAA3awAAOGsA ADprAAA7awAAPGsAAD1rAAA+awAAQGsAAEFrAABCawAAQ2sAAEVrAABGawAAR2sAAEhrAABK awAAS2sAAExrAABNawAAT2sAAFBrAABRawAAUmsAAFRrAABVawAAVmsAAFdrAABYawAAWWsA AFprAABbawAAXGsAAF1rAABeawAAX2sAAGBrAABhawAAYmsAAGNrAABkawAAZWsAAGZrAABn awAAaGsAAGlrAABqawAAa2sAAGxrAABtawAAbmsAAG9rAABwawAAcWsAAHJrAABzawAAdGsA AHVrAAB2awAAd2sAAHhrAAB6awAAe2sAAN6BAABeBQAAUxcAAB0NAABTFwAAqRIAAHQAAAAA AFQFAAArCAAAVAcAAG8yAABLIgAAdAAAAAAAUwUAACEDAAC4AAAAwzEAAF0GAAB0AAAAAABg BQAAViMAAMr9///BNwAAmgAAAHQAAAAAAF8FAABTFwAA4RYAAFMXAABsHAAAdAAAAAAAPgQA ABIIAACDGQAAvRsAAFwgAAB0AAAAAAA/BAAA4SQAAMz7//9MOQAAnP7//3QAAAAAAD0EAAC1 AAAAmBAAALcXAAC5GAAAdAAAAAAAPAQAAAgcAABBDgAAlygAAJQfAAB0AAAAAAA7BAAAFhoA AG0gAABOMAAAfyIAAHQAAAAAADoEAAArHAAAwBEAAB8wAADFHwAAdAAAAAAAOQQAALb///8P AwAALw4AAIAFAAB0AAAAAAA4BAAA4f///60FAAA4DAAAeQ8AAHQAAAAAADcEAABeDAAAlgMA ANcaAAAHBgAAdAAAAAAANgQAAHQMAABGBgAA2hoAABEQAAB0AAAAAAA1BAAAHh0AAHMGAACW KwAA5AgAAHQAAAAAADQEAAAnGwAAxggAAH4tAAB5EQAAdAAAAAAAMwQAAJcoAADPEwAAkykA ADAaAAB0AAAAAAAyBAAAZCcAAC0QAADAJwAAvxQAAHQAAAAAADEEAAC7IAAA0w0AALIhAADk EgAAdAAAAAAAMAQAAGkiAACNDAAAsCUAAHUOAAB0AAAAAAAvBAAAwiUAACIMAADFLAAArxAA AHQAAAAAAC4EAAB7HwAArBYAAH0mAAC9GAAAdAAAAAAALQQAAKgeAAC0EgAASCcAAN0cAAB0 AAAAAAAsBAAAnCgAAFEZAAA8LgAALR8AAHQAAAAAACsEAAB6GwAAAAsAAH0iAAA+DgAAdAAA AAAAKgQAAL0WAAAjCAAAehsAAFILAAB0AAAAAAApBAAAihcAAFcMAABoGwAAVwwAAHQAAAAA ACgEAADxDwAANgoAAHgXAADDDgAAdAAAAAAAJwQAAM0LAADMBwAA6RAAAPsKAAB0AAAAAAAm BAAAKgwAACAMAAAIEAAAIAwAAHQAAAAAACUEAABuCAAAKwsAABYMAAAaDQAAdAAAAAAAJAQA AFwEAACRBgAA0AgAAA8LAAB0AAAAAAAjBAAAggQAADYMAABgCAAANgwAAHQAAAAAACIEAADo ////mQoAAFwEAADXDQAAdAAAAAAAIQQAAOn+//+c/v//iy0AAI4CAAB0AAAAAABjBQAASSYA ABj7//+0OgAA6P3//3QAAAAAAGIFAAA9BQAA1AIAAPUxAADgIwAAdAAAAAAAYQUAACEDAADo /f//wjEAAIcCAAB0AAAAAABkBQAAIQMAAIgDAACULQAAmBEAAHQAAAAAAFkEAAB5IwAAGPv/ /+Q3AADo/f//dAAAAAAAVwQAACkDAADhEgAAVDAAAIEeAAB0AAAAAABABAAAuQEAAOj9//9b MAAA8AQAAHQAAAAAAFgEAACOBwAAQB4AAKosAADSIQAAdAAAAAAAegUAAD0DAACgAQAAdzAA AGcaAAB0AAAAAAB8BAAAxSIAAMz7//8wNwAAnP7//3QAAAAAAHsEAAB7BgAACBsAALkwAAAe IgAAdAAAAAAAWgQAAG0CAAA0/f//DzEAAHcBAAB0AAAAAACZBAAApQYAALwaAADlMAAA0yEA AHQAAAAAAH4EAAAhAwAAiAMAAFswAABAGQAAdAAAAAAAmgQAAOEkAAAY+///TDkAAOj9//90 AAAAAAB9BAAAbQIAAJz+//8PMQAApAUAAHQAAAAAALoFAACDAQAAewEAAN8xAABDGwAAdAAA AAAAuAQAAHkjAAAY+///5DcAAOj9//90AAAAAAC3BAAAbAYAAGIcAACqMAAAeSMAAHQAAAAA AJsEAAAFAQAANP3//6cvAADSAQAAdAAAAAAA0QQAAC0kAADM+///mDgAAJz+//90AAAAAADQ BAAAhAUAACYaAADCLwAAPSEAAHQAAAAAALoEAACPAQAAeAYAAA8xAACbGAAAdAAAAAAAuQQA ALkBAAAEAAAAWzAAAKIEAAB0AAAAAAD2BAAA4SQAABj7//9NOQAA6P3//3QAAAAAAPUEAADZ GgAAGyAAABAxAAAtIgAAdAAAAAAA9AQAAEoaAADFGwAATRwAACEfAAB0AAAAAADzBAAAxwYA AJEbAABIGgAAJiEAAHQAAAAAAPIEAAB6KQAAvAYAAJErAAAlCQAAdAAAAAAA8QQAAGAbAABK AgAApjEAAKMGAAB0AAAAAADwBAAAIw0AALwSAABYGQAAkBkAAHQAAAAAAO8EAABcEAAAYhAA AHMSAADLEgAAdAAAAAAA7gQAAMIEAAD0DwAA/wYAAIMSAAB0AAAAAADtBAAAJgAAAJwSAADX CwAAcBkAAHQAAAAAAOwEAABJHAAAcw4AANgoAADGHwAAdAAAAAAA6wQAAGwcAADyEQAAXzAA APgfAAB0AAAAAADqBAAA9////0IDAABvDgAAswUAAHQAAAAAAOkEAAAhAAAA4AUAAHkMAACs DwAAdAAAAAAA6AQAAJ8MAADJAwAAFxsAADoGAAB0AAAAAADnBAAAtQwAAHkGAAAaGwAARBAA AHQAAAAAAOYEAABeHQAApgYAANcrAAAXCQAAdAAAAAAA5QQAAGgbAAD4CAAAvy0AAKwRAAB0 AAAAAADkBAAA2CgAAAIUAADUKQAAYhoAAHQAAAAAAOMEAACkJwAAYBAAAAAoAADyFAAAdAAA AAAA4gQAAPsgAAAFDgAA8iEAABYTAAB0AAAAAADhBAAAqSIAAMAMAADxJQAAqA4AAHQAAAAA AOAEAAADJgAAVQwAAAUtAADhEAAAdAAAAAAA3wQAALsfAADeFgAAviYAAPAYAAB0AAAAAADe BAAA6R4AAOcSAACJJwAADx0AAHQAAAAAAN0EAADcKAAAhBkAAHwuAABfHwAAdAAAAAAA3AQA ALobAAAzCwAAvSIAAHEOAAB0AAAAAADbBAAA/hYAAFYIAAC6GwAAhQsAAHQAAAAAANoEAADL FwAAiQwAAKkbAACJDAAAdAAAAAAA2QQAADEQAABoCgAAuRcAAPUOAAB0AAAAAADYBAAADQwA AP4HAAApEQAALQsAAHQAAAAAANcEAABqDAAAUgwAAEgQAABSDAAAdAAAAAAA1gQAAK8IAABd CwAAVgwAAEwNAAB0AAAAAADVBAAAnQQAAMMGAAAQCQAAQQsAAHQAAAAAANQEAADCBAAAaAwA AKAIAABoDAAAdAAAAAAA0wQAACkAAADMCgAAnQQAAAoOAAB0AAAAAADSBAAABQEAADT9//+m LwAAVwIAAHQAAAAAAF8GAABGAgAAmvz//0E0AADSIwAAdAAAAAAAJAUAAJUlAABk+v//AToA ADT9//90AAAAAAAAAAAAfWsAABJsAABcbAAAXWwAANBsAADVbAAAK3cAADR3AAC/fQAAxH0A AN+BAAAHAAcABwACAAcAHAAHABwABwAcAAcAAAAAAJ8lAACxJQAAslgAALNYAAB9awAAEmwA AFxsAABdbAAA3GwAAORsAADxbAAA+GwAAAVtAAAObQAAoG4AAKduAADIbgAAz24AAPFuAAD4 bgAAPnUAAFB1AAAyegAAPHoAAN+BAAAHADMABwAEAAcABwAHAAIABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHAAAAAAAOEwAADxMAABATAAAcEwAAQhMAAEMTAAC4GQAAvBkA AA4cAAAgHAAA8SEAAPIhAACnJQAApyUAALslAAC8JQAAeUsAAHpLAAAiTAAAXUwAAHRMAAB0 TAAAjEwAANFMAAD7TAAA/EwAAP1MAAAETQAA2U0AADdOAACVTgAA804AAPROAAD1TgAAAU8A AJ5PAAAuUAAARFAAAPJQAAD4UwAA+VMAAPpTAACtWAAAslgAAJhiAACcYgAAbWQAAG1kAACB ZAAAwGQAANtkAAA9ZQAAfGsAAH1rAAB/awAAEGwAABJsAABabAAAXWwAAGRsAABlbAAAKm8A ADhvAAA5bwAARG8AAEVvAABSbwAAU28AAGNvAABkbwAAaW8AAGpvAACLbwAAjG8AAMVvAADG bwAA128AANhvAADcbwAA3W8AAO5vAADvbwAAKnAAACtwAABNcAAAZnAAAGdwAABwcAAAcXAA AMVwAADFcAAAxnAAAMZwAADHcAAAx3AAAMhwAADIcAAAyXAAAMlwAADKcAAAynAAAMtwAADL cAAAzHAAAMxwAADNcAAAzXAAAM5wAADOcAAAz3AAAM9wAADQcAAA0HAAANFwAADRcAAA0nAA ANJwAADTcAAA03AAANRwAADUcAAA1XAAANVwAADWcAAA1nAAANdwAADXcAAA2HAAANhwAADw cAAA8XAAAM1zAADOcwAA+nMAAAh0AAA1dAAAQ3QAAER0AABPdAAAUHQAAFx0AABddAAAbXQA AG50AACRdAAAknQAAKN0AACkdAAA03QAANR0AAAWdQAAF3UAAD11AAA+dQAAYnUAAGN1AAC9 dQAAvnUAAAV2AAAGdgAAD3YAABB2AAAkdgAAJXYAAHB2AABxdgAAs3YAAM92AADQdgAA3ngA AN94AAAVeQAAJHkAACd6AAA2egAArHsAAK17AACvewAAvXsAAL57AADJewAAynsAANZ7AADX ewAA53sAAOh7AAD0ewAA9XsAABV8AAAWfAAAUnwAAFN8AAB/fAAAgHwAAIV8AACGfAAAsnwA ALN8AADlfAAA5nwAABJ9AAATfQAAIn0AACN9AAA6fQAAO30AAFV9AABWfQAAXX0AAF59AABe fQAAX30AAH9/AACAfwAAnX8AAJ5/AACnfwAAqH8AAB2AAAAegAAAhoAAAIeAAAD7gAAA/IAA AAWBAAAGgQAAKIEAACmBAADcgQAA34EAAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAHAAMABAAHAAQAAgADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQABwD/ /xQAAAAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABN AHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBj AHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgB0AHgAdAAK AFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABE AG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBv AG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgB0AHgAdAAKAFcAaQBs ACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJ AHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBh AGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBu AHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBt AHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBv AGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBc AEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABF AG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBD ADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBE AEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABU AG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQ AGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABD AHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBu AGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBz AG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgBy AGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBv AHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBh AGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0 ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBk AG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABN AHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBj AHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAJ AH////++zEgC/w//D/8P/w//D/8P/w//D/8PAQD+////8NNoE/8PAAAAAAAAAAAAAAAAAAAA AAEABDxmCTbyzMP/DwAAAAAAAAAAAAAAAAAAAAABAG8d8R+GAZ7A/w//D/8P/w//D/8P/w// D/8PEAC4aHUj3PaoTv8P/w//D/8P/w//D/8P/w//DxAABHBGLg6Sfi0UAP8P/w//D/8P/w// D/8P/w8QAMUY3Vq6HAhc/w//D/8P/w//D/8P/w//D/8PEACuJBZqRg+QqP8P/w//D/8P/w// D/8P/w//DxAAxTKkc0TzDv7/D/8P/w//D/8P/w//D/8P/w8QAAEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP4CAAAALgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAqAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY /hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEALfABAAAAABABAAAAAAAAAAAAaAEAAAAA AAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQ AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEA AAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUA LgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkG XoRQGWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAUGAAAD4Q4BBGEmP4VxgUA ATgEBl6EOARghJj+QioAT0oBAFFKAQBvKABwaAAAAP8BAKjwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9KBQBRSgUAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgYAUUoG AG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUAAagMBl6E qAxghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EeA8R hJj+FcYFAAF4DwZehHgPYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZehOgX YISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhLgaEYSY /hXGBQABuBoGXoS4GmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAA AAAUGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+QioAT0oBAFFKAQBvKABwaAAAAP8BAKjw AQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9K BQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB 2AkGXoTYCWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KBQBRSgUAbygAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgYA UUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgV Bl6EGBVghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E 6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhLgaEYSY/hXGBQABuBoGXoS4GmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oGAFFK BgBvKAABANjwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhHAI EYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUA bygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTg EGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SwExGE mP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8o AAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARg hJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAAB ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY /k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQEYSY/hXG BQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBv AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5P SgYAUUoGAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAA0AIAAAAAAAALGAAAD4Q4BBGEmP4VxgUA ATgEBl6EOARghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAANACAAAAAAAACxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAA AADQAgAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAA0AIAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oB AFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAANACAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAADQAgAAAAAAAAsYAAAP hOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAA 0AIAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAA ABeQAAAAAAAAAAAAANACAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBR SgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAADQAgAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkG XoRQGWCEmP5PSgYAUUoGAG8oAAEAp/AOAAAA/v///wAAAAA8r/YCAQAAAP7///8AAAAAkK/2 AgEAAAD+////AAAAAOSv9gIBAAAA/v///wAAAAA4sPYCAQAAAP7///8AAAAAjLD2AgEAAACu JBZqAAAAAAAAAAAAAAAAbx3xHwAAAAAAAAAAAAAAAH////8AAAAAAAAAAAAAAADFMqRzAAAA AAAAAAAAAAAABHBGLgAAAAAAAAAAAAAAAAQ8ZgkAAAAAAAAAAAAAAADFGN1aAAAAAAAAAAAA AAAAuGh1IwAAAAAAAAAAAAAAAARwRi4AAAAAAAAAAAAAAAD/////SK/2AiAAAAAAAAAAF0AA AAAAAAAAAAAAAAAAAAAAAAAPAAAAQ0ooAE9KAABRSgAAbygAAQAiIP////+cr/YCIABAQAAA AAAXQAAAAAAAAAAAAAAAAAAAAAAAAA8AAABDSioAT0oGAFFKBgBvKAABAG7w//////Cv9gIg AAAAAAAAABdAAAAAAAAAAAAAAAAAAAAAAAAADwAAAENKGABPSgYAUUoGAG8oAAEAbPD///// RLD2AiAAAAAAAAAAF0AAAAAAAAAAAAAAAAAAAAAAAAAPAAAAQ0okAE9KBgBRSgYAbygAAQBu 8P////+YsPYCIAAAAAAAAAAXQAAAAAAAAAAAAAAAAAAAAAAAAA8AAABDShQAT0oGAFFKBgBv KAABAGzw//////////////////////////////////////////////////8JAAAAAAAAAAAA AAAAAAAAAAAAAAAA//8JAAAAAAAAAAAAEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkE GQAJBBsACQQSAGaDLNIDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIAvsQKJgMA CQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgAYyKz+AwAJBAUACQQBAAkEAwAJBAUA CQQBAAkEAwAJBAUACQQSAAYYoDwDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIA BhigPAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAAAAEACQwFAAIAQAAAAAAA WVgAAPpfAADfgQAAAAAAAAHdAAAB3QAA/0ADgAEAslgAALJYAABMCZcBAQABALJYAAAAAAAA rVgAAAAAAAACEAAAAAAAAADegQAAYAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8B AAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEA AAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABT AHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABB AHIAaQBhAGwAAAA5AJABAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQwBo AGEAcgBjAG8AYQBsAAAAQSaQAQAAAgsFBgICAgMCBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAA AEEAcgBpAGEAbAAgAE4AYQByAHIAbwB3AAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAA AAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABABxCIgYAPDQ AgAAaAEAAAAADTxUxh88VMZAbFJGCQASAAAAjA8AAKFYAAABAC0AAAAEAAMQvQAAABgDAACj EQAAAQAJAAAAJQAAAAAAAADBAgDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAClBsAHtAC0AIAAMjAAABAAGQBkAAAAGQAAANdsAAC7FAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA AAAAAAAAAAwyg1EA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAA AAAALQBQAG8AcwB0AC0ARABlAGwAaQB2AGUAcgB5ACAAQwBvAG4AdABlAG4AdAAgAE0AYQBu AGEAZwBlAG0AZQBuAHQAIABDAG8AbgB0AHIAaQBiAHUAdABpAG8AbgAAAAAAAAAMAFMAaQBt AG8AbgAgAEIAcgB5AGQAZQBuAAoAVwBpAGwAIABXAGEAbABrAG8AZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACgAQAA EQAAAAEAAACQAAAAAgAAAJgAAAADAAAA0AAAAAQAAADcAAAABQAAAPQAAAAHAAAAAAEAAAgA AAAUAQAACQAAACgBAAASAAAANAEAAAoAAABQAQAACwAAAFwBAAAMAAAAaAEAAA0AAAB0AQAA DgAAAIABAAAPAAAAiAEAABAAAACQAQAAEwAAAJgBAAACAAAA5AQAAB4AAAAuAAAAUG9zdC1E ZWxpdmVyeSBDb250ZW50IE1hbmFnZW1lbnQgQ29udHJpYnV0aW9uAC4wHgAAAAEAAAAAb3N0 HgAAAA0AAABTaW1vbiBCcnlkZW4AIENvHgAAAAEAAAAAaW1vHgAAAAsAAABOb3JtYWwuZG90 AG4eAAAACwAAAFdpbCBXYWxrb2UAbh4AAAACAAAAOQBsIB4AAAATAAAATWljcm9zb2Z0IFdv cmQgOS4wAG5AAAAAAOy6gwIAAABAAAAAAPBBTwiWwAFAAAAAANZMhqe/wAFAAAAAAMIHCqq/ wAEDAAAAAQAAAAMAAACMDwAAAwAAAKFYAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQA AgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAIAEAAAwAAAABAAAA aAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEAAACYAAAAFwAAAKAAAAALAAAAqAAAABAA AACwAAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAAAAIBAAACAAAA5AQAAB4AAAAQAAAA Tm9ydGVsIE5ldHdvcmtzAAMAAAC9AAAAAwAAAC0AAAADAAAA12wAAAMAAADtDgkACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAC4AAABQb3N0LURlbGl2ZXJ5IENv bnRlbnQgTWFuYWdlbWVudCBDb250cmlidXRpb24ADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA EgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAA SAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUA AABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAA YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAA AABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAA/v///3wAAAB9AAAA fgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsA AACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAA mQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYA AACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAA tAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEA AADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAA zwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwA AADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA 6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA/v////EAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcA AAD+////+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAP7////9/////f////3///8EAQAA /v////7////+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAANBGyyiqv8ABBgEAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB7AAAA9+gAAAAAAABXAG8A cgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADv9QAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AAAAABAAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAADQRssoqr/AAdBGyyiqv8ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAA wAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAA V29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA --openmail-part-238944ed-00000001-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 9 18:57:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18467 for ; Mon, 9 Apr 2001 18:57:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02837; Mon, 9 Apr 2001 18:38:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02808 for ; Mon, 9 Apr 2001 18:38:15 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18336 for ; Mon, 9 Apr 2001 18:38:12 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA48736; Mon, 9 Apr 2001 15:37:42 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA18782; Mon, 9 Apr 2001 15:37:42 -0700 Message-ID: <3AD2388A.63266CC5@hursley.ibm.com> Date: Mon, 09 Apr 2001 17:32:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Wil.Walkoe@mail.sprint.com CC: diffserv@ietf.org Subject: Re: [Diffserv] EndToEndQos.doc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Wil, This is out of scope for the diffserv WG - please read our charter at http://www.ietf.org/html.charters/diffserv-charter.html It is also bad practice to send large documents in a proprietary format to mailing lists with several hundred people on them. If you are interested in an IETF overview of the QOS landscape, please look at ftp://ftp.isi.edu/in-notes/rfc2990.txt Regards Brian Carpenter diffserv WG co-chair Wil.Walkoe@mail.sprint.com wrote: > > Dear people, > > The attached document is a working draft from the Broadband Content > Delivery Forum's Infrastructure Working Group, addressing quality of > service in end-to-end data delivery. It addresses QoS from a > perspective that takes account of the many different intermediaries > that play a role in data delivery and contribute to end-to-end delay, > throughput, etc. > > I would be interested in your comments on this material, both on the > content itself (errors, omissions, material from your standards work > that should be addressed) and on where this topic could most > effectively be addressed in the IETF. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 9 22:24:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22327 for ; Mon, 9 Apr 2001 22:24:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05392; Mon, 9 Apr 2001 22:08:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05370 for ; Mon, 9 Apr 2001 22:08:41 -0400 (EDT) Received: from msk.tomail.com.tw (msk.tomail.com.tw [210.200.129.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22206 for ; Mon, 9 Apr 2001 22:08:32 -0400 (EDT) Received: (qmail 4742 invoked from network); 10 Apr 2001 02:08:30 -0000 Received: from atmlab02.ee.ncku.edu.tw (HELO atmlab02) (140.116.163.9) by msk.tomail.com.tw with SMTP; 10 Apr 2001 02:08:30 -0000 Message-ID: <007e01c0c162$d1265540$09a3748c@ee.ncku.edu.tw> From: "Ken" To: Date: Tue, 10 Apr 2001 10:06:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Diffserv] queue scheduling Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id WAA05392 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22327 Hi, I have a basic question, but still have no answer. In RFC for Expedited Forwarding PHB, it says there are several types of queue scheduling mechanisms could be employed for diffserv, but does anyone knows what is the definite mechanism in the real implementations, like "traffic control" for linux, or ALTQ, etc.? If there is no definite mechanism, is it possible to define one in RFC in the future, or is it will remain a open issue? Thanks for any comments. Ken Lai ========================================================== PC home 禣筿獺絚ビ叫叫: http://www.pchome.com.tw PC home Online 呼隔產畑 穦材芖程呼 ========================================================== _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 10 10:07:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15757 for ; Tue, 10 Apr 2001 10:07:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21467; Tue, 10 Apr 2001 09:42:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21436 for ; Tue, 10 Apr 2001 09:42:27 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14867 for ; Tue, 10 Apr 2001 09:42:25 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA67018; Tue, 10 Apr 2001 06:41:50 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA24582; Tue, 10 Apr 2001 06:41:53 -0700 Message-ID: <3AD30D62.1A9C90FA@hursley.ibm.com> Date: Tue, 10 Apr 2001 08:40:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ken CC: diffserv@ietf.org Subject: Re: [Diffserv] queue scheduling References: <007e01c0c162$d1265540$09a3748c@ee.ncku.edu.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Ken, This is certainly not something we will ever attempt to standardise. The whole principle of diffserv is to define a behavior, but leave individual (competitive) implementors to design their own implementations of that behavior. If you look at the diffserv MIB you will see that in fact, the various PHBs will be implemented in practice by configuring a basic set of schedulers in one way or another. Since you mention RFC 2598, you may also want to look at http://www.ietf.org/internet-drafts/draft-ietf-diffserv-efresolve-00.txt http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-00.txt http://www.ietf.org/internet-drafts/draft-ietf-diffserv-ef-supplemental-00.txt Regards Brian Carpenter diffserv co-chair Ken wrote: > > Hi, > I have a basic question, but still have no answer. > > In RFC for Expedited Forwarding PHB, it says there are several types of > queue scheduling mechanisms could be employed for diffserv, but does anyone > knows what is the definite mechanism in the real implementations, like > "traffic control" for linux, or ALTQ, etc.? > > If there is no definite mechanism, is it possible to define one in RFC in > the future, > or is it will remain a open issue? > > Thanks for any comments. > > Ken Lai _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 10 10:10:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15853 for ; Tue, 10 Apr 2001 10:10:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21643; Tue, 10 Apr 2001 09:56:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21611 for ; Tue, 10 Apr 2001 09:56:10 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15274 for ; Tue, 10 Apr 2001 09:56:08 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GBK007HIXBQHR@firewall.mcit.com> for diffserv@ietf.org; Tue, 10 Apr 2001 13:55:03 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBK00F01XBM57@dgismtp02.wcomnet.com>; Tue, 10 Apr 2001 13:55:02 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBK00F04XBG3Q@dgismtp02.wcomnet.com>; Tue, 10 Apr 2001 13:54:52 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 13:54:52 +0000 Content-return: allowed Date: Tue, 10 Apr 2001 13:54:50 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] queue scheduling To: "'Ken'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F56FC@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_5tqpOu+wym5C9u7XN+BcLw)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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. --Boundary_(ID_5tqpOu+wym5C9u7XN+BcLw) Content-type: text/plain; charset=ISO-8859-1 Ken, I have seen documentation that states that several Oss support various Scheduling mechanisms. They support DRR, WFQ, Priority Queueing, etc. However, Priority Queueing has been shown (in studies and experiments) as the most appropriate for an EF PHB implementation, thus far. Tina Iliff -----Original Message----- From: Ken [mailto:kenation2@pchome.com.tw] Sent: Monday, April 09, 2001 9:06 PM To: diffserv@ietf.org Subject: [Diffserv] queue scheduling Hi, I have a basic question, but still have no answer. In RFC for Expedited Forwarding PHB, it says there are several types of queue scheduling mechanisms could be employed for diffserv, but does anyone knows what is the definite mechanism in the real implementations, like "traffic control" for linux, or ALTQ, etc.? If there is no definite mechanism, is it possible to define one in RFC in the future, or is it will remain a open issue? Thanks for any comments. Ken Lai ========================================================== PC home ???????????: http://www.pchome.com.tw PC home Online ?????? ?????????????? ========================================================== _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_5tqpOu+wym5C9u7XN+BcLw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] queue scheduling

Ken,

I have seen documentation that states = that several Oss support various Scheduling mechanisms.  They = support DRR, WFQ, Priority Queueing, etc.  However, Priority = Queueing has been shown (in studies and experiments) as the most = appropriate for an EF PHB implementation, thus far.

Tina Iliff


--Boundary_(ID_5tqpOu+wym5C9u7XN+BcLw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 10 18:16:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27226 for ; Tue, 10 Apr 2001 18:16:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00981; Tue, 10 Apr 2001 18:01:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00950 for ; Tue, 10 Apr 2001 18:01:32 -0400 (EDT) Received: from bor.ellacoya.com ([64.223.136.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27014 for ; Tue, 10 Apr 2001 18:01:28 -0400 (EDT) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Apr 2001 17:49:24 -0400 Message-ID: From: "Weiss, Walter" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] CountActTable Date: Tue, 10 Apr 2001 17:49:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C208.1AFA97B2" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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_01C0C208.1AFA97B2 Content-Type: text/plain; charset="iso-8859-1" I agree with Joel. The MIB has a mechanism for identifying where counters should be configured in the datapath. If the framework PIB or the accounting PIB have a means for assigning a counter to count out of profile metered traffic, then what Joel is asking for is unnecessary. However, this is not my understanding for how either of these PIBs work. If someone can explain the framework or accounting PIBs can be used to define counters at various points in the data path, this would be helpful for me. regards, -Walter > -----Original Message----- > From: Joel M. Halpern [mailto:joel@longsys.com] > Sent: Friday, April 06, 2001 2:00 PM > To: diffserv@ietf.org > Subject: RE: [Diffserv] CountActTable > > > No, I just think that there should be a PRC for creating a > Count Action > just as there is one for creating a Drop Action or a Meter Action. > Yours, > Joel > ------_=_NextPart_001_01C0C208.1AFA97B2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

I agree with Joel. The MIB has a mechanism for = identifying where counters should be configured in the datapath. If the = framework PIB or the accounting PIB have a means for assigning a = counter to count out of profile metered traffic, then what Joel is = asking for is unnecessary. However, this is not my understanding for = how either of these PIBs work. If someone can explain the framework or = accounting PIBs can be used to define counters at various points in the = data path, this would be helpful for me.

regards,

-Walter

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@longsys.com]
> Sent: Friday, April 06, 2001 2:00 PM
> To: diffserv@ietf.org
> Subject: RE: [Diffserv] CountActTable
>
>
> No, I just think that there should be a PRC for = creating a
> Count Action
> just as there is one for creating a Drop Action = or a Meter Action.
> Yours,
> Joel
>

------_=_NextPart_001_01C0C208.1AFA97B2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 10 19:43:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28138 for ; Tue, 10 Apr 2001 19:43:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02165; Tue, 10 Apr 2001 19:25:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02134 for ; Tue, 10 Apr 2001 19:25:33 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27894; Tue, 10 Apr 2001 19:25:32 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f3ANPS519052; Tue, 10 Apr 2001 16:25:28 -0700 (PDT) Message-Id: <200104102325.f3ANPS519052@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 10 Apr 2001 16:25:28 -0700 From: RFC Editor Subject: [Diffserv] RFC 3086 on Diffserv per Domain Behaviors Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3086 Title: Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification Author(s): K. Nichols, B. Carpenter Status: Informational Date: April 2001 Mailbox: nichols@packetdesign.com, brian@icair.org Pages: 24 Characters: 63122 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-pdb-def-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3086.txt The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select (classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes. The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, or PDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service Level Specifications at the network edge. This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This document is a product of the Differentiated Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010410162236.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3086 --OtherAccess Content-Type: Message/External-body; name="rfc3086.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010410162236.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 10 19:51:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28242 for ; Tue, 10 Apr 2001 19:51:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02545; Tue, 10 Apr 2001 19:34:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02523 for ; Tue, 10 Apr 2001 19:34:18 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28008 for ; Tue, 10 Apr 2001 19:34:16 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA19771 for ; Tue, 10 Apr 2001 16:33:49 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADV14686; Tue, 10 Apr 2001 16:33:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20010410162546.00b63588@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Apr 2001 16:26:01 -0700 To: diffserv@ietf.org From: Ravikanth Samprathi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] urgent help needed in iproute2+tc Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi all, I am running linux-2.4.0 with 3 interfaces - eth0, eth1, and eth2. eth0 is the outgoing WAN interface. eth1 and eth2 are the internal LAN interfaces. eth1 and eth2 belong to a bridge group br0. eth1 is connected to a voice-over-ip phone. eth2 is connected to a pc. so, the setup is ------------------------------ | | voip-phone --->| eth1 ---> | | br0 eth0 -|---WAN lan-pc ---------->| eth2 ----> | ------------------------------ voip-phone can talk with lan-pc through-the-bridge-group. voip phone can also talk with any other phone in the outside-world-through-the-WAN. I need to setup QoS so that all packets from voip-phone (that is destined to either eth1, eth2 or to eth0) are provided with high-priority-low-delay service. voip-phone can be on any lan-interface (eth1 or eth2). The only thing that can be surely said about the voip-phone is that it will have only a particular set of ip addresses ranging from 171.72.233.100 to 171.72.233.200. To implement this, i downloaded the iproute2+tc tool version iproute2-2.2.4-now-ss991023.tar.gz and went through the README files. Can somebody please help me in writing the commands? That will be of great help. Thanking you in advance, ravi ---------------------------------------------------> Ravi Samprathi work:(408)853-8038 Cisco Systems res :(408)988-2268 Empowering the Internet Generation <--------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 03:20:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18358 for ; Wed, 11 Apr 2001 03:20:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15363; Wed, 11 Apr 2001 03:06:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15332 for ; Wed, 11 Apr 2001 03:05:49 -0400 (EDT) Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18281 for ; Wed, 11 Apr 2001 03:05:48 -0400 (EDT) Received: from nusnet-2-102.dynip.nus.edu.sg (HELO dalmatian) (137.132.2.102) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Apr 2001 07:05:49 -0000 X-Apparently-From: Message-ID: <003101c0c255$ddb1a730$e6d612ac@nus.edu.sg> Reply-To: "Yuan Lihua" From: "Yuan Lihua" To: "Iliff, Tina" , "'Ken'" , References: <492EB4A3F68CD411ABE800508B69362E3F56FC@RIPEXCH002.wcomnet.com> Subject: Re: [Diffserv] queue scheduling Date: Wed, 11 Apr 2001 15:05:58 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C0C298.E9EA5540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C0C298.E9EA5540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] queue scheduling----- Original Message -----=20 From: Iliff, Tina=20 To: 'Ken' ; diffserv@ietf.org=20 Sent: Tuesday, April 10, 2001 9:54 PM Subject: RE: [Diffserv] queue scheduling Ken,=20 I have seen documentation that states that several Oss support various = Scheduling mechanisms. They support DRR, WFQ, Priority Queueing, etc. = However, Priority Queueing has been shown (in studies and experiments) = as the most appropriate for an EF PHB implementation, thus far. >> Can you refer me which "studies and experiments" that states PQ is = the most appropriate for EF? Tina Iliff=20 ------=_NextPart_000_002E_01C0C298.E9EA5540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] queue scheduling
----- Original Message -----
From: Iliff, = Tina=20
Sent: Tuesday, April 10, 2001 = 9:54 PM
Subject: RE: [Diffserv] queue=20 scheduling

Ken,

I have seen documentation that states = that several=20 Oss support various Scheduling mechanisms.  They support DRR, WFQ, = Priority=20 Queueing, etc.  However, Priority Queueing has been shown (in = studies and=20 experiments) as the most appropriate for an EF PHB implementation, thus=20 far.

>> Can you refer me which = "studies and=20 experiments" that states PQ is the most appropriate for EF?

 

Tina Iliff=20

------=_NextPart_000_002E_01C0C298.E9EA5540-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 10:52:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25300 for ; Wed, 11 Apr 2001 10:52:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23740; Wed, 11 Apr 2001 10:15:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23714 for ; Wed, 11 Apr 2001 10:15:04 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24543 for ; Wed, 11 Apr 2001 10:15:02 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAB79764; Wed, 11 Apr 2001 07:14:29 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA18716; Wed, 11 Apr 2001 07:14:32 -0700 Message-ID: <3AD46687.635DFEA3@hursley.ibm.com> Date: Wed, 11 Apr 2001 09:13:27 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ravikanth Samprathi CC: diffserv@ietf.org Subject: Re: [Diffserv] urgent help needed in iproute2+tc References: <4.3.2.7.2.20010410162546.00b63588@mira-sjc5-7.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This isn't a topic for the diffserv WG. Please try the diffserv implementation list at http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv co-chair Ravikanth Samprathi wrote: > > Hi all, > I am running linux-2.4.0 with > 3 interfaces - eth0, eth1, and eth2. > > eth0 is the outgoing WAN interface. > eth1 and eth2 are the internal LAN interfaces. > eth1 and eth2 belong to a bridge group br0. > eth1 is connected to a voice-over-ip phone. > eth2 is connected to a pc. > > so, the setup is > ------------------------------ > | | > voip-phone --->| eth1 ---> | > | br0 eth0 -|---WAN > lan-pc ---------->| eth2 ----> | > ------------------------------ > > voip-phone can talk with lan-pc > through-the-bridge-group. > voip phone can also talk with any other > phone in the outside-world-through-the-WAN. > > I need to setup QoS so that all packets > from voip-phone (that is destined to either > eth1, eth2 or to eth0) are provided with > high-priority-low-delay service. voip-phone > can be on any lan-interface (eth1 or eth2). > The only thing that can be surely said > about the voip-phone is that it will > have only a particular set of ip addresses > ranging from 171.72.233.100 to 171.72.233.200. > > To implement this, i downloaded the > iproute2+tc tool version > iproute2-2.2.4-now-ss991023.tar.gz > and went through the README files. > > Can somebody please help me in > writing the commands? That will > be of great help. > > Thanking you in advance, > ravi > ---------------------------------------------------> > Ravi Samprathi work:(408)853-8038 > Cisco Systems res :(408)988-2268 > Empowering the Internet Generation > <--------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 14:03:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00088 for ; Wed, 11 Apr 2001 14:03:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27703; Wed, 11 Apr 2001 13:44:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27680 for ; Wed, 11 Apr 2001 13:44:43 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29667 for ; Wed, 11 Apr 2001 13:44:40 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA17133 for ; Wed, 11 Apr 2001 10:44:15 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADW11034; Wed, 11 Apr 2001 10:44:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20010411103209.00b63e50@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Apr 2001 10:36:27 -0700 To: diffserv@ietf.org From: Ravikanth Samprathi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] packet marking - prioritzing Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi everybody, i have three interfaces, eth0, eth1, eth2. i need to do the following:- INGRESS: packets coming on any of these three interfaces, with a particular range of source ip addresses, or with a particular range of destination ip addresses, have to be marked by setting the TOS bits to some value. EGRESS: packets leaving on any of these interfaces must be prioritized into 2 queues - high priority and normal priority. all packets whose TOS bits are marked go into high priority and all other packets go into low priority. low priority queue should be serviced only after high priority queue. please tell me which tool to use, to mark, prioritize, and service these packets. what are the commands. i tried reading tc, but i did not understand how to use it for my purpose. thank you in advance for any help. ravi ---------------------------------------------------> Ravi Samprathi work:(408)853-8038 Cisco Systems res :(408)988-2268 Empowering the Internet Generation <--------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 15:02:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01168 for ; Wed, 11 Apr 2001 15:02:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28825; Wed, 11 Apr 2001 14:36:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28793 for ; Wed, 11 Apr 2001 14:36:29 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00677 for ; Wed, 11 Apr 2001 14:36:27 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA68454; Wed, 11 Apr 2001 11:35:49 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA20012; Wed, 11 Apr 2001 11:35:55 -0700 Message-ID: <3AD4A35A.98660398@hursley.ibm.com> Date: Wed, 11 Apr 2001 13:32:58 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ravikanth Samprathi CC: diffserv@ietf.org Subject: Re: [Diffserv] packet marking - prioritzing References: <4.3.2.7.2.20010411103209.00b63e50@mira-sjc5-7.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Implementation issues are not the topic of the diffserv WG. Please use the diffserv implementation list at http://www.atnf.csiro.au/news/exploders/dsimplementation.html Regards Brian Carpenter diffserv co-chair Ravikanth Samprathi wrote: > > Hi everybody, > i have three interfaces, eth0, eth1, eth2. > i need to do the following:- > > INGRESS: > packets coming on any of these three interfaces, > with a particular range of source ip addresses, > or with a particular range of destination ip addresses, > have to be marked by setting the TOS bits to some value. > > EGRESS: > packets leaving on any of these interfaces must > be prioritized into 2 queues - high priority and normal priority. > all packets whose TOS bits are marked go into high > priority and all other packets go into low priority. > low priority queue should be serviced only after high > priority queue. > > please tell me which tool to use, to mark, prioritize, and > service these packets. what are the commands. i tried > reading tc, but i did not understand how to use it for > my purpose. > > thank you in advance for any help. > ravi > ---------------------------------------------------> > Ravi Samprathi work:(408)853-8038 > Cisco Systems res :(408)988-2268 > Empowering the Internet Generation > <--------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 16:54:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03167 for ; Wed, 11 Apr 2001 16:54:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00921; Wed, 11 Apr 2001 16:30:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00889 for ; Wed, 11 Apr 2001 16:30:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02800 for ; Wed, 11 Apr 2001 16:30:44 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23816 for ; Wed, 11 Apr 2001 13:30:39 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADW16013; Wed, 11 Apr 2001 13:30:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20010411131839.00b63e50@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Apr 2001 13:22:29 -0700 To: diffserv@ietf.org From: Ravikanth Samprathi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] problems in diffserv... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi everybody, i have three interfaces, eth0, eth1, eth2. i need to do the following:- INGRESS: packets coming on any of these three interfaces, with a particular range of source ip addresses, or with a particular range of destination ip addresses, have to be marked by setting the TOS bits to some value. EGRESS: packets leaving on any of these interfaces must be prioritized into 2 queues - high priority and normal priority. all packets whose TOS bits are marked go into high priority and all other packets go into low priority. low priority queue should be serviced only after high priority queue. please tell me which tool to use, to mark, prioritize, and service these packets. I tried tc configuration commands. But its giving me these errors:- > Unknown qdisc "dmark", hence option "indices" is unparsable > Error: Qdisc "dsmark" is classless > Unknown filter "tcindex", hence option "mask" is unparsable > RTNETLINK answers: No such file or directory > Unknown filter "tcindex", hence option "classid" is unparsable thank you in advance for any help. ravi ---------------------------------------------------> Ravi Samprathi work:(408)853-8038 Cisco Systems res :(408)988-2268 Empowering the Internet Generation <--------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 18:35:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04394 for ; Wed, 11 Apr 2001 18:35:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00406; Wed, 11 Apr 2001 16:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00377 for ; Wed, 11 Apr 2001 16:09:03 -0400 (EDT) Received: from mailsrv.coronanetworks.com ([38.186.47.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02188 for ; Wed, 11 Apr 2001 16:08:59 -0400 (EDT) Received: by newmail.coronanetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 13:19:47 -0700 Message-ID: From: Sanjeev Chakravarty To: Yuan Lihua , "Iliff, Tina" , "'Ken'" , diffserv@ietf.org Subject: RE: [Diffserv] queue scheduling Date: Wed, 11 Apr 2001 13:19:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C2C4.C0C44280" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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_01C0C2C4.C0C44280 Content-Type: text/plain; charset="ISO-8859-1" Hi Tina, The Simulation Results mentioned in the Appendix of RFC2598 (An Expedited Forwarding PHB) states the following: For Jitter Variation experiment: " It appears that most jitter for WRR is low and can be reduced by a proper choice of the EF queue's WRR share of the output link with respect to its subscribed rate. As noted, WRR is a worst case while PQ is the best case. Other possibilities include WFQ or CBQ with a fixed rate limit for the EF queue but giving it priority over other queues. We expect the latter to have performance nearly identical with PQ though future simulations are needed to verify this. We have not yet systematically explored effects of hop count, EF allocations other than 30% of the link bandwidth, or more complex topologies. The information in this section is not part of the EF PHB definition but provided simply as background to guide implementers" Other references to such experiments would help establish whether PQ is indeed the most appropriate queuing mechanism for EF PHB implementation. - Sanjeev Chakravarty -----Original Message----- From: Yuan Lihua [mailto:yuan_lihua@yahoo.com] Sent: Wednesday, April 11, 2001 12:06 AM To: Iliff, Tina; 'Ken'; diffserv@ietf.org Subject: Re: [Diffserv] queue scheduling ----- Original Message ----- From: Iliff, Tina To: 'Ken' ; diffserv@ietf.org Sent: Tuesday, April 10, 2001 9:54 PM Subject: RE: [Diffserv] queue scheduling Ken, I have seen documentation that states that several Oss support various Scheduling mechanisms. They support DRR, WFQ, Priority Queueing, etc. However, Priority Queueing has been shown (in studies and experiments) as the most appropriate for an EF PHB implementation, thus far. >> Can you refer me which "studies and experiments" that states PQ is the most appropriate for EF? Tina Iliff ------_=_NextPart_001_01C0C2C4.C0C44280 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] queue scheduling
Hi=20 Tina,
 
The=20 Simulation Results mentioned in the Appendix of RFC2598 (An Expedited = Forwarding=20 PHB) states the following:
 
For=20 Jitter Variation experiment:
 
"  =20 It appears that most jitter for WRR is low and can be reduced by=20 a
   proper choice of the EF queue's WRR share of the = output link=20 with
   respect to its subscribed rate.  As noted, = WRR is a=20 worst case while
   PQ is the best case. Other = possibilities=20 include WFQ or CBQ with a
   fixed rate limit for the EF = queue but=20 giving it priority over other
   queues. We expect the = latter to=20 have performance nearly identical
   with PQ though future = simulations are needed to verify this. We have
   not yet=20 systematically explored effects of hop count, EF = allocations
  =20 other than 30% of the link bandwidth, or more complex topologies.=20 The
   information in this section is not part of the EF = PHB=20 definition but
   provided simply as background to guide=20 implementers"
 
Other=20 references to such experiments would help establish whether PQ is = indeed the=20 most appropriate queuing mechanism for EF PHB = implementation.
 
-=20 Sanjeev Chakravarty
 
 
 -----Original=20 Message-----
From: Yuan Lihua=20 [mailto:yuan_lihua@yahoo.com]
Sent: Wednesday, April 11, = 2001 12:06=20 AM
To: Iliff, Tina; 'Ken'; = diffserv@ietf.org
Subject: Re:=20 [Diffserv] queue scheduling

----- Original Message -----
From:=20 Iliff, Tina=20
To: 'Ken'=20 ; diffserv@ietf.org
Sent: Tuesday, April 10, 2001 = 9:54=20 PM
Subject: RE: [Diffserv] queue=20 scheduling

Ken,

I have seen documentation that states = that several=20 Oss support various Scheduling mechanisms.  They support DRR, = WFQ,=20 Priority Queueing, etc.  However, Priority Queueing has been = shown (in=20 studies and experiments) as the most appropriate for an EF PHB = implementation,=20 thus far.

>> Can you refer me which = "studies and=20 experiments" that states PQ is the most appropriate for = EF?

 

Tina Iliff=20

------_=_NextPart_001_01C0C2C4.C0C44280-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 19:00:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04674 for ; Wed, 11 Apr 2001 19:00:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02840; Wed, 11 Apr 2001 18:41:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02809 for ; Wed, 11 Apr 2001 18:41:07 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04443 for ; Wed, 11 Apr 2001 18:41:03 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA25096; Wed, 11 Apr 2001 15:40:33 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA21700; Wed, 11 Apr 2001 15:40:33 -0700 Message-ID: <3AD4DC1D.7BCEFAE6@hursley.ibm.com> Date: Wed, 11 Apr 2001 17:35:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Sanjeev Chakravarty CC: Yuan Lihua , "Iliff, Tina" , "'Ken'" , diffserv@ietf.org Subject: Re: [Diffserv] queue scheduling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yet again we are getting into territory that belongs on the implementation list - please continue the conversation over there folks. http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Your co-chair - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 11 19:00:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04686 for ; Wed, 11 Apr 2001 19:00:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02878; Wed, 11 Apr 2001 18:42:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02852 for ; Wed, 11 Apr 2001 18:42:14 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04458 for ; Wed, 11 Apr 2001 18:42:11 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA34640; Wed, 11 Apr 2001 15:41:42 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA24700; Wed, 11 Apr 2001 15:41:43 -0700 Message-ID: <3AD4DC62.254C1018@hursley.ibm.com> Date: Wed, 11 Apr 2001 17:36:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ravikanth Samprathi CC: diffserv@ietf.org Subject: Re: [Diffserv] problems in diffserv... References: <4.3.2.7.2.20010411131839.00b63e50@mira-sjc5-7.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit For the second time please take this discussion to the correct list: http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv co-chair Ravikanth Samprathi wrote: > > Hi everybody, > i have three interfaces, eth0, eth1, eth2. > i need to do the following:- > > INGRESS: > packets coming on any of these three interfaces, > with a particular range of source ip addresses, > or with a particular range of destination ip addresses, > have to be marked by setting the TOS bits to some value. > > EGRESS: > packets leaving on any of these interfaces must > be prioritized into 2 queues - high priority and normal priority. > all packets whose TOS bits are marked go into high > priority and all other packets go into low priority. > low priority queue should be serviced only after high > priority queue. > > please tell me which tool to use, to mark, prioritize, and > service these packets. > I tried tc configuration commands. > But its giving me these errors:- > > > Unknown qdisc "dmark", hence option "indices" is unparsable > > Error: Qdisc "dsmark" is classless > > Unknown filter "tcindex", hence option "mask" is unparsable > > RTNETLINK answers: No such file or directory > > Unknown filter "tcindex", hence option "classid" is unparsable > > thank you in advance for any help. > ravi > ---------------------------------------------------> > Ravi Samprathi work:(408)853-8038 > Cisco Systems res :(408)988-2268 > Empowering the Internet Generation > <--------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 11:18:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02532 for ; Thu, 12 Apr 2001 11:18:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23203; Thu, 12 Apr 2001 10:59:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23176 for ; Thu, 12 Apr 2001 10:59:06 -0400 (EDT) Received: from gw.tropicnetworks.com ([209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02128 for ; Thu, 12 Apr 2001 10:59:04 -0400 (EDT) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 12 Apr 2001 14:59:06 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA5D1E for ; Thu, 12 Apr 2001 10:58:41 -0400 Message-ID: <3AD5C17A.7D17863D@tropicnetworks.com> Date: Thu, 12 Apr 2001 10:53:46 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv Deployment Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'm trying to compile a list of deployed networks that folks consider to be enabled with diffserv or diffserv-like capabilities. If you have deployed such a network or are aware of such deployments, please drop me a line. I'm interested in any level of detail you can provide. e.g info such as size of network, location, public/private network, brief service description etc. Please reply to me directly and not to everyone on the list. Thanks! --- Best Nabil Seddigh nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 17:30:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11462 for ; Thu, 12 Apr 2001 17:30:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28988; Thu, 12 Apr 2001 17:12:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28957 for ; Thu, 12 Apr 2001 17:12:47 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11147 for ; Thu, 12 Apr 2001 17:12:45 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id QAA27476 for ; Thu, 12 Apr 2001 16:09:31 -0500 (CDT) Message-ID: <3AD61A2F.200C4BD0@windriver.com> Date: Thu, 12 Apr 2001 16:12:15 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Would someone please help me? I compiled the "draft-ietf-diffserv-mib-09.txt" MIB and got the following errors and warnings: Errors (IMPORT errors): - InetAddressPrefixLength not found in INET-ADDRESS-MIB - InetPortNumber not found in INET-ADDRESS-MIB where INET-ADDRESS-MIB is defined in RFC 2851 Warnings: - Textual-convention "Dscp" defined but not referenced. - Textual-convention "DscpOrAny" defined but not referenced. - Warning: "zeroDotZero" imported but not used. Also, are there any significant changes anticipated for this MIB, or is this version close to the final cut? Thank you, Tom Irwin _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 18:17:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12261 for ; Thu, 12 Apr 2001 18:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29610; Thu, 12 Apr 2001 17:55:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29578 for ; Thu, 12 Apr 2001 17:55:09 -0400 (EDT) Received: from smtp1.pandora.be (hercules.telenet-ops.be [195.130.132.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11831 for ; Thu, 12 Apr 2001 17:55:08 -0400 (EDT) Received: (qmail 5241 invoked from network); 12 Apr 2001 21:54:38 -0000 Received: from unknown (HELO rug.ac.be) ([213.224.173.106]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 21:54:38 -0000 Message-ID: <3AD6241E.63BA389F@rug.ac.be> Date: Thu, 12 Apr 2001 23:54:38 +0200 From: Brecht Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom Irwin CC: diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors References: <3AD61A2F.200C4BD0@windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Tom Irwin wrote: > > Would someone please help me? > > I compiled the "draft-ietf-diffserv-mib-09.txt" MIB and got the > following errors and warnings: > > Errors (IMPORT errors): > - InetAddressPrefixLength not found in INET-ADDRESS-MIB > - InetPortNumber not found in INET-ADDRESS-MIB > where INET-ADDRESS-MIB is defined in RFC 2851 You have to include the update of this MIB : draft-ietf-ops-rfc2851-update-00.txt > > Warnings: > - Textual-convention "Dscp" defined but not referenced. > - Textual-convention "DscpOrAny" defined but not referenced. > - Warning: "zeroDotZero" imported but not used. You have to compile also the small MIB included in the draft : dscp-tc-mib best regards, Brecht Vermeulen Ghent University Belgium > > Also, are there any significant changes anticipated for this MIB, or is > this version close to the final cut? > > Thank you, > Tom Irwin > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 18:42:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12695 for ; Thu, 12 Apr 2001 18:42:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00121; Thu, 12 Apr 2001 18:14:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00090 for ; Thu, 12 Apr 2001 18:14:04 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12181 for ; Thu, 12 Apr 2001 18:14:02 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA39832; Thu, 12 Apr 2001 15:13:33 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA25096; Thu, 12 Apr 2001 15:13:33 -0700 Message-ID: <3AD62858.15B667F1@hursley.ibm.com> Date: Thu, 12 Apr 2001 17:12:40 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Tom Irwin CC: diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors References: <3AD61A2F.200C4BD0@windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Tom, There will be a mib-10 version soon - Fred Baker left the editorial meeting with at least 25 things to update, some of which are substantive, so yes there will be changes I'm afraid. And we will have to check that the new one compiles. Brian Tom Irwin wrote: > > Would someone please help me? > > I compiled the "draft-ietf-diffserv-mib-09.txt" MIB and got the > following errors and warnings: > > Errors (IMPORT errors): > - InetAddressPrefixLength not found in INET-ADDRESS-MIB > - InetPortNumber not found in INET-ADDRESS-MIB > where INET-ADDRESS-MIB is defined in RFC 2851 > > Warnings: > - Textual-convention "Dscp" defined but not referenced. > - Textual-convention "DscpOrAny" defined but not referenced. > - Warning: "zeroDotZero" imported but not used. > > Also, are there any significant changes anticipated for this MIB, or is > this version close to the final cut? > > Thank you, > Tom Irwin _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 18:52:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12891 for ; Thu, 12 Apr 2001 18:52:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00256; Thu, 12 Apr 2001 18:19:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00232 for ; Thu, 12 Apr 2001 18:19:32 -0400 (EDT) Received: from smtp1.pandora.be (hercules.telenet-ops.be [195.130.132.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12343 for ; Thu, 12 Apr 2001 18:19:30 -0400 (EDT) Received: (qmail 20252 invoked from network); 12 Apr 2001 22:19:00 -0000 Received: from unknown (HELO rug.ac.be) ([213.224.173.106]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 22:19:00 -0000 Message-ID: <3AD629D5.24B446D4@rug.ac.be> Date: Fri, 13 Apr 2001 00:19:01 +0200 From: Brecht Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom Irwin , diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors References: <3AD61A2F.200C4BD0@windriver.com> <3AD6241E.63BA389F@rug.ac.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > > > > Warnings: > > - Textual-convention "Dscp" defined but not referenced. > > - Textual-convention "DscpOrAny" defined but not referenced. > > - Warning: "zeroDotZero" imported but not used. > > You have to compile also the small MIB included in the draft : > dscp-tc-mib > sorry, I've answered too fast. The problem is that there are two MIBs in the text file and some compilers only compile the first small dscp-tc-mib. The solution is to split them up manually and compile both of them separately. > best regards, > > Brecht Vermeulen > Ghent University > Belgium > > > > > Also, are there any significant changes anticipated for this MIB, or is > > this version close to the final cut? > > > > Thank you, > > Tom Irwin > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 18:54:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12912 for ; Thu, 12 Apr 2001 18:54:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00432; Thu, 12 Apr 2001 18:26:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00406 for ; Thu, 12 Apr 2001 18:26:48 -0400 (EDT) Received: from web12703.mail.yahoo.com ([216.136.173.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12430 for ; Thu, 12 Apr 2001 18:26:46 -0400 (EDT) Message-ID: <20010412222642.75283.qmail@web12703.mail.yahoo.com> Received: from [132.205.45.76] by web12703.mail.yahoo.com; Thu, 12 Apr 2001 15:26:42 PDT Date: Thu, 12 Apr 2001 15:26:42 -0700 (PDT) From: Steven Shi To: issll@mercury.lcs.mit.edu, diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] How does RSVP dynamically provision resources in DS region? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org My question is about e2e QoS reservation which is in a manner of per flow reservation(not aggregate RSVP)in DS region. When the RSVP messages go through DS region to collect the information of the availability of resource in DS region, how does the DS region treat them: 1. Is the Adspec in sender PATH message updated by the RSVP awared nodes in DS region? If it is, how can DS region interpret the meaning of Adspec since Adspec is defined for IntServ? 2. Or the updating of Adspec can be ONLY done at border router of DS region? If there is any statement of my question, what is that? Regrads, Steven __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 12 19:15:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13332 for ; Thu, 12 Apr 2001 19:15:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01087; Thu, 12 Apr 2001 18:49:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01056 for ; Thu, 12 Apr 2001 18:49:26 -0400 (EDT) Received: from smtp1.pandora.be (hercules.telenet-ops.be [195.130.132.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12826 for ; Thu, 12 Apr 2001 18:49:26 -0400 (EDT) Received: (qmail 3139 invoked from network); 12 Apr 2001 22:48:54 -0000 Received: from unknown (HELO rug.ac.be) ([213.224.173.106]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 22:48:54 -0000 Message-ID: <3AD630D7.45574460@rug.ac.be> Date: Fri, 13 Apr 2001 00:48:55 +0200 From: Brecht Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom Irwin , diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors References: <3AD61A2F.200C4BD0@windriver.com> <3AD6241E.63BA389F@rug.ac.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > Warnings: > > - Textual-convention "Dscp" defined but not referenced. > > - Textual-convention "DscpOrAny" defined but not referenced. > > - Warning: "zeroDotZero" imported but not used. > > You have to compile also the small MIB included in the draft : > dscp-tc-mib oops, answered too fast. In the draft text file, there are two MIBs, the dscp-tc-mib and the diffserv-mib. Most compilers only compile the first one. The workaround is too split them up in two files and compile them separately. Therefore you see the warnings that those definitions are not used. So, yes they compile (the mib authors have used smicng to develop them). > > best regards, > > Brecht Vermeulen > Ghent University > Belgium > > > > > Also, are there any significant changes anticipated for this MIB, or is > > this version close to the final cut? > > > > Thank you, > > Tom Irwin > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 13 04:25:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03472 for ; Fri, 13 Apr 2001 04:25:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15380; Fri, 13 Apr 2001 04:08:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15359 for ; Fri, 13 Apr 2001 04:08:46 -0400 (EDT) Received: from hotmail.com ([64.4.9.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03288 for ; Fri, 13 Apr 2001 04:08:45 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Apr 2001 01:04:40 -0700 Received: from 66.24.36.162 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 13 Apr 2001 08:04:40 GMT X-Originating-IP: [66.24.36.162] From: "Mike Badil" To: stevenbj2001@yahoo.com, issll@mercury.lcs.mit.edu, diffserv@ietf.org Subject: Re: [Diffserv] How does RSVP dynamically provision resources in DS region? Date: Fri, 13 Apr 2001 04:04:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Apr 2001 08:04:40.0859 (UTC) FILETIME=[644B2EB0:01C0C3F0] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Steven, As far as I know there is no reservation protocol for diffserv yet and RSVP is not suitable, therefore it is not being used. Thus, diffserv does not provide reliable e2e QoS at this moment. Another important point is per-flow requests does not go beyond edges, when a customer requests a service, the request is handled in edge. For more information look at: rfc2998 >My question is about e2e QoS reservation which is in a >manner of per flow reservation(not aggregate RSVP)in >DS region. When the RSVP messages go through DS region >to collect the information of the availability of >resource in DS region, how does the DS region treat >them: > >1. Is the Adspec in sender PATH message updated by the >RSVP awared nodes in DS region? If it is, how can DS >region interpret the meaning of Adspec since Adspec is >defined for IntServ? > >2. Or the updating of Adspec can be ONLY done at >border router of DS region? > >If there is any statement of my question, what is >that? > >Regrads, > >Steven > > > > > >__________________________________________________ >Do You Yahoo!? >Get email at your own domain with Yahoo! Mail. >http://personal.mail.yahoo.com/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 13 09:45:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08182 for ; Fri, 13 Apr 2001 09:45:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19211; Fri, 13 Apr 2001 09:25:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19180 for ; Fri, 13 Apr 2001 09:25:50 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07653 for ; Fri, 13 Apr 2001 09:25:47 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA58770; Fri, 13 Apr 2001 06:25:14 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA25122; Fri, 13 Apr 2001 06:25:16 -0700 Message-ID: <3AD6FE0F.EFA23EC3@hursley.ibm.com> Date: Fri, 13 Apr 2001 08:24:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mike Badil CC: stevenbj2001@yahoo.com, issll@mercury.lcs.mit.edu, diffserv@ietf.org Subject: Re: [Diffserv] How does RSVP dynamically provision resources in DS region? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit In any case... this is a topic for the ISSLL WG alone, not diffserv. Diffserv's charter specifically excludes signalling. If you want to continue this thread, please drop diffserv from the CC: list Regards Brian Carpenter diffserv co-chair Mike Badil wrote: > > Steven, > > As far as I know there is no reservation protocol for diffserv yet and RSVP > is not suitable, therefore it is not being used. Thus, diffserv does not > provide reliable e2e QoS at this moment. > > Another important point is per-flow requests does not go beyond edges, when > a customer requests a service, the request is handled in edge. > > For more information look at: rfc2998 > > >My question is about e2e QoS reservation which is in a > >manner of per flow reservation(not aggregate RSVP)in > >DS region. When the RSVP messages go through DS region > >to collect the information of the availability of > >resource in DS region, how does the DS region treat > >them: > > > >1. Is the Adspec in sender PATH message updated by the > >RSVP awared nodes in DS region? If it is, how can DS > >region interpret the meaning of Adspec since Adspec is > >defined for IntServ? > > > >2. Or the updating of Adspec can be ONLY done at > >border router of DS region? > > > >If there is any statement of my question, what is > >that? > > > >Regrads, > > > >Steven > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 13 10:54:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09913 for ; Fri, 13 Apr 2001 10:54:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20463; Fri, 13 Apr 2001 10:31:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20432 for ; Fri, 13 Apr 2001 10:31:51 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09561 for ; Fri, 13 Apr 2001 10:31:49 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23523 for ; Fri, 13 Apr 2001 10:31:50 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23511 for ; Fri, 13 Apr 2001 10:31:49 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 13 Apr 2001 16:31:48 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C056B3A@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: diffserv@ietf.org, Tom Irwin Subject: RE: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors Date: Fri, 13 Apr 2001 16:31:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Inline > ---------- > From: Tom Irwin[SMTP:tom.irwin@windriver.com] > Sent: Thursday, April 12, 2001 11:12 PM > To: diffserv@ietf.org > Subject: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors > > Would someone please help me? > > I compiled the "draft-ietf-diffserv-mib-09.txt" MIB and got the > following errors and warnings: > > Errors (IMPORT errors): > - InetAddressPrefixLength not found in INET-ADDRESS-MIB > - InetPortNumber not found in INET-ADDRESS-MIB > where INET-ADDRESS-MIB is defined in RFC 2851 > there is also a new draft draft-ietf-ops-rfc2851-update-00.txt which does inclide these new TCs. And a rev of that doc is also in the pipeline > Warnings: > - Textual-convention "Dscp" defined but not referenced. > - Textual-convention "DscpOrAny" defined but not referenced. That is often (allways) the case for a TC-only module. SMICng has a flag for it to turn off the wng. Other compilers probably too (if they issue a wng at all) > - Warning: "zeroDotZero" imported but not used. > Not sure why that one would be imported into a TC module > Also, are there any significant changes anticipated for this MIB, or is > this version close to the final cut? > Brian answered this one. Bert > Thank you, > Tom Irwin > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist > .html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 13 19:24:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20499 for ; Fri, 13 Apr 2001 19:24:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27782; Fri, 13 Apr 2001 19:06:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27755 for ; Fri, 13 Apr 2001 19:06:50 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20220 for ; Fri, 13 Apr 2001 19:06:49 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id SAA16390 for ; Fri, 13 Apr 2001 18:03:35 -0500 (CDT) Message-ID: <3AD7866A.9B609A82@windriver.com> Date: Fri, 13 Apr 2001 18:06:18 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors References: <2413FED0DFE6D111B3F90008C7FA61FB0C056B3A@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Thank you all for your gracious help. I have compiled the draft DiffServ MIB now using the Emissary MIB compiler that comes with the Wind River (formerly Epilogue) Envoy SNMP package. There are no errors and just the 'Warning: "zeroDotZero" imported but not used.' Thanks, Tom Irwin. "Wijnen, Bert (Bert)" wrote: > > Inline > > > ---------- > > From: Tom Irwin[SMTP:tom.irwin@windriver.com] > > Sent: Thursday, April 12, 2001 11:12 PM > > To: diffserv@ietf.org > > Subject: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors > > > > Would someone please help me? > > > > I compiled the "draft-ietf-diffserv-mib-09.txt" MIB and got the > > following errors and warnings: > > > > Errors (IMPORT errors): > > - InetAddressPrefixLength not found in INET-ADDRESS-MIB > > - InetPortNumber not found in INET-ADDRESS-MIB > > where INET-ADDRESS-MIB is defined in RFC 2851 > > > there is also a new draft draft-ietf-ops-rfc2851-update-00.txt > which does inclide these new TCs. And a rev of that doc > is also in the pipeline > > > Warnings: > > - Textual-convention "Dscp" defined but not referenced. > > - Textual-convention "DscpOrAny" defined but not referenced. > That is often (allways) the case for a TC-only module. > SMICng has a flag for it to turn off the wng. Other compilers > probably too (if they issue a wng at all) > > > - Warning: "zeroDotZero" imported but not used. > > > Not sure why that one would be imported into a TC module > > > Also, are there any significant changes anticipated for this MIB, or is > > this version close to the final cut? > > > Brian answered this one. > > Bert > > > Thank you, > > Tom Irwin > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist > > .html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Apr 14 03:33:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09684 for ; Sat, 14 Apr 2001 03:33:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09579; Sat, 14 Apr 2001 03:17:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09551 for ; Sat, 14 Apr 2001 03:17:53 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09562 for ; Sat, 14 Apr 2001 03:17:53 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA29325 for ; Sat, 14 Apr 2001 00:17:46 -0700 (PDT) Message-Id: <5.0.2.1.2.20010413225233.00b00f40@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 13 Apr 2001 22:52:44 -0700 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Fwd: A few comments for draft-ietf-diffserv-mib-09.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >Subject: A few comments for draft-ietf-diffserv-mib-09.txt >Date: Fri, 13 Apr 2001 15:23:13 -0700 >Thread-Topic: A few comments for draft-ietf-diffserv-mib-09.txt >Thread-Index: AcDEaD9bSUtfVC3PEdWeBQABA7y1rw== >From: "Faye Ly" >To: , , > >Cc: "Faye Ly" > >Hi, > >I apologize but I haven't gotten a chance to subscribe to the diffserv >list yet. (With the IPO mailing list experience, I am not sure I want to >:)-) Please feel free to forward this to the mailing list if appropriete. > >-faye > >========================================================================================= > >Hi, > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > >1. The major problem I see with this MIB is the usage by NMS. The tables >defined are not very 'friendly' for NMS retrieval. For example, in order >to find out the filter being applied to a subscriber Joe. > > 1.1 NMS has to first get the logical interface entry for Joe and > derive the datapath entry. For our discussion, I don't count the SNMP > packets required to get here. > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > the DataPathStart object. > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > another SNMP getnext to retrieve the Classifier element until all > elements associated with this classifier are retrieved. > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > tuple classification entry for Joe. > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a >particular subscriber. This is not scalable for NMS that typically has to >deal with minimum thousands of subscribers. A suggestion is to eliminate >the Classifier table and have the Datapath table simply provide an INTEGER >pointer point to the Classifier ID in the Classifier Element Table OR >meterId in the Meter table OR ... Note that the reverse pointer from >the, say Meter table, back to the Classifier table requires the Classifier >ID only. > >Does this make sense or did I totally miss the point of your table >rowpointer design? > >2. For a full classifier, meter, actions, dropper, queue and scheduler can >be linked all together via the rowPointer. This is although very smart >but again if the NMS is trying to get all the SLA provisioned on a single >system. It has to traverse through 6 tables or more in order to get a >single flow's SLA. Again not very scalable. An alternative is to place >all these table pointers into a single data path table or profile >table. The profile table will have separate object specifying the >relationship between all these tables for a single SLA. The table pointer >will be NULL if a certain SLA doesn't require, for example, any queue to >be specified. The datapath table in turns will be assigned with a single >profile. > >Your thoughts? > >-faye _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Apr 14 03:34:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09716 for ; Sat, 14 Apr 2001 03:34:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09654; Sat, 14 Apr 2001 03:21:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09623 for ; Sat, 14 Apr 2001 03:21:46 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09599 for ; Sat, 14 Apr 2001 03:21:46 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA29328; Sat, 14 Apr 2001 00:17:47 -0700 (PDT) Message-Id: <5.0.2.1.2.20010413225246.039e9020@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 13 Apr 2001 22:58:00 -0700 To: "Faye Ly" From: Fred Baker Cc: diffserv@ietf.org In-Reply-To: <2BC6020788F6D04B82E413E548072A0907A2AE@sonscenter.SALIRA.C OM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: A few comments for draft-ietf-diffserv-mib-09.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: >Hi, > >I apologize but I haven't gotten a chance to subscribe to the diffserv >list yet. (With the IPO mailing list experience, I am not sure I want to >:)-) Please feel free to forward this to the mailing list if appropriete. > >-faye > >========================================================================================= > >Hi, > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > >1. The major problem I see with this MIB is the usage by NMS. The tables >defined are not very 'friendly' for NMS retrieval. For example, in order >to find out the filter being applied to a subscriber Joe. > > 1.1 NMS has to first get the logical interface entry for Joe and > derive the datapath entry. For our discussion, I don't count the SNMP > packets required to get here. > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > the DataPathStart object. > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > another SNMP getnext to retrieve the Classifier element until all > elements associated with this classifier are retrieved. > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > tuple classification entry for Joe. > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a >particular subscriber. This is not scalable for NMS that typically has to >deal with minimum thousands of subscribers. A suggestion is to eliminate >the Classifier table and have the Datapath table simply provide an INTEGER >pointer point to the Classifier ID in the Classifier Element Table OR >meterId in the Meter table OR ... Note that the reverse pointer from >the, say Meter table, back to the Classifier table requires the Classifier >ID only. That is pretty much where we started out. We changed to RowPointer in response to requests from the working group to allow folks to easily add new filter types, such as picking out messages by MAC Address etc. If you have a specific proposal that would allow for the flexibility we were asked to provide and addresses your concern (and I agree that this is a lot of round trips), I'd like to hear it. >2. For a full classifier, meter, actions, dropper, queue and scheduler can >be linked all together via the rowPointer. This is although very smart >but again if the NMS is trying to get all the SLA provisioned on a single >system. It has to traverse through 6 tables or more in order to get a >single flow's SLA. Again not very scalable. An alternative is to place >all these table pointers into a single data path table or profile >table. The profile table will have separate object specifying the >relationship between all these tables for a single SLA. The table pointer >will be NULL if a certain SLA doesn't require, for example, any queue to >be specified. The datapath table in turns will be assigned with a single >profile. Could you be more specific? Can you advise how hierarchical systems such as CBQ would be described using your approach? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Apr 14 10:30:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12767 for ; Sat, 14 Apr 2001 10:30:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14531; Sat, 14 Apr 2001 10:15:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14509 for ; Sat, 14 Apr 2001 10:15:16 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12664 for ; Sat, 14 Apr 2001 10:15:16 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA07095 for ; Sat, 14 Apr 2001 07:14:46 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f3EEEnH06524 for ; Sat, 14 Apr 2001 07:14:49 -0700 (PDT) Received: from rjsnetworks.com ([216.53.186.170]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f3EEEfH16341 for ; Sat, 14 Apr 2001 07:14:41 -0700 (PDT) Received: from rjsnetworks-ws1 [216.53.186.170] by rjsnetworks.com with ESMTP (SMTPD32-6.06) id AB0C8C02E2; Sat, 14 Apr 2001 10:13:32 -0400 From: "=?iso-8859-1?Q?Sales_-_rjsNetworks=2Ecom?=" Date: Sat, 14 Apr 2001 10:13:32 -0400 To: "=?iso-8859-1?Q?diffserv@external=2Ecisco=2Ecom?=" X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: Quoted-Printable MIME-Version: 1.0 X-USER_IP: 65.35.21.33 X-Mailer: JMail 4.1.2 Free Version by Dimac Content-Type: text/html; charset="iso-8859-1" Message-Id: <200104141013187.SM01108@rjsnetworks-ws1> Content-Transfer-Encoding: Quoted-Printable Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: Quoted-Printable ; Sun, 15 Apr 2001 19:56:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11489; Sun, 15 Apr 2001 19:28:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11465 for ; Sun, 15 Apr 2001 19:28:40 -0400 (EDT) Received: from dcn.ssu.ac.kr (dcn.ssu.ac.kr [203.253.2.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12595 for ; Sun, 15 Apr 2001 19:28:38 -0400 (EDT) Received: from peniel5 ([203.253.28.185]) by dcn.ssu.ac.kr (8.10.1/8.10.1) with SMTP id f3FNKhI29323 for ; Mon, 16 Apr 2001 08:20:44 +0900 (KST) From: "peniel5" To: Date: Mon, 16 Apr 2001 08:26:23 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id TAA11466 Subject: [Diffserv] What do you think about .... PE , CE ? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit These days, TC( traffic control ) in Linux have been implemented in Ingress router. but, also CE( customer Edge ) has been considered in Diffserv paper...... I want to know nowadays PE( Provider Edge ) Implementation in Linux Also I want to know which TC position in linux is the right direction Is there anybody who knows this question? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 16 07:24:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02282 for ; Mon, 16 Apr 2001 07:24:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26599; Mon, 16 Apr 2001 07:06:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26568 for ; Mon, 16 Apr 2001 07:06:09 -0400 (EDT) Received: from lisanza.net ([151.29.232.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02130 for ; Mon, 16 Apr 2001 07:06:09 -0400 (EDT) Received: from covalent.net (localhost [127.0.0.1]) by lisanza.net (8.9.3/8.9.3) with ESMTP id NAA47484; Mon, 16 Apr 2001 13:06:00 +0200 (CEST) (envelope-from harrie@covalent.net) Message-ID: <3AD81C2C.A501D971@covalent.net> Date: Sat, 14 Apr 2001 11:45:16 +0200 From: Harrie Hazewinkel Organization: Covalent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tom Irwin CC: diffserv@ietf.org Subject: Re: [Diffserv] draft-ietf-diffserv-mib-09.txt MIB errors References: <2413FED0DFE6D111B3F90008C7FA61FB0C056B3A@nl0006exch002u.nl.lucent.com> <3AD7866A.9B609A82@windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Tom Irwin wrote: > > Thank you all for your gracious help. I have compiled the draft > DiffServ MIB now using the Emissary MIB compiler that comes with the > Wind River (formerly Epilogue) Envoy SNMP package. There are no errors > and just the 'Warning: "zeroDotZero" imported but not used.' interesting. For instance on page 36 (diffServClfrElementSpecific) the value zeroDotZero is used. Depending what you use it for I would not make a problem out of it. The compiler seems not to recognise DEFVAL-clauses. Harrie -- phone: +39-3474932300 http://www.lisanza.net/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 16 10:23:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04466 for ; Mon, 16 Apr 2001 10:23:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28699; Mon, 16 Apr 2001 09:57:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28672 for ; Mon, 16 Apr 2001 09:57:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03698; Mon, 16 Apr 2001 09:57:08 -0400 (EDT) Message-Id: <200104161357.JAA03698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Apr 2001 09:57:08 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-01.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : An Expedited Forwarding PHB Author(s) : B. Davie et al. Filename : draft-ietf-diffserv-rfc2598bis-01.txt Pages : 17 Date : 13-Apr-01 The PHB (per-hop behavior) is a basic building block in the Differentiated Services architecture. This document defines a PHB called Expedited Forwarding (EF). EF is intended to provide a building block for low delay and low loss services by ensuring that the EF aggregate is served at a certain configured rate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-rfc2598bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-rfc2598bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010413122044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-rfc2598bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-rfc2598bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010413122044.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 16 11:45:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06945 for ; Mon, 16 Apr 2001 11:45:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00004; Mon, 16 Apr 2001 11:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29975 for ; Mon, 16 Apr 2001 11:27:16 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06290 for ; Mon, 16 Apr 2001 11:27:16 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA81212; Mon, 16 Apr 2001 08:26:42 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA25152; Mon, 16 Apr 2001 08:26:46 -0700 Message-ID: <3ADB0E7F.777855FC@hursley.ibm.com> Date: Mon, 16 Apr 2001 10:23:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: peniel5 CC: diffserv@ietf.org Subject: Re: [Diffserv] What do you think about .... PE , CE ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Can you please direct this type of question to the Diffserv Implementation list See http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv WG co-chair peniel5 wrote: > > These days, TC( traffic control ) in Linux have been implemented in Ingress router. > but, also CE( customer Edge ) has been considered in Diffserv paper...... > > I want to know nowadays PE( Provider Edge ) Implementation in Linux > Also I want to know which TC position in linux is the right direction > > Is there anybody who knows this question? > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 17 15:30:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14222 for ; Tue, 17 Apr 2001 15:30:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01691; Tue, 17 Apr 2001 14:22:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01658 for ; Tue, 17 Apr 2001 14:22:50 -0400 (EDT) Received: from sonscenter.SALIRA.COM ([64.168.86.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12797 for ; Tue, 17 Apr 2001 14:22:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C76B.61625EDE" Date: Tue, 17 Apr 2001 11:22:37 -0700 Message-ID: <2BC6020788F6D04B82E413E548072A0907A2B3@sonscenter.SALIRA.COM> Thread-Topic: A few comments for draft-ietf-diffserv-mib-09.txt Thread-Index: AcDEs+AHk2UG48P+TlOr6il/oFBx9ACqiUQA From: "Faye Ly" To: "Fred Baker" Cc: Subject: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C0C76B.61625EDE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fred, Certainly. More emails will follow this one as the proposed changes may require more description. Proposed change: Change diffServDataPathStart to point to an entry in the TCS table. =20 TCS Table is defined as: INDEX {TCBIndex} OBJECTS Classifier Filter pointer - points to a set of filters defined in=20 diffServSixTupleClfrTable. Change=20 the indexing of diffServSixTupleClfrTable to double index {ClassifierId, ClfrId} By specifying the classifier ID in this object, NMS can easily retrieve all the filters defined for this classifier. The syntax of this object will be=20 the same as the ClassifierId defined in the diffServSixTupleClfrTable. =20 Meter pointer - points to an entry in the meter table as defined. =20 =20 Action pointer - points to an entry in the Action table as defined. =20 Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. Queue table pointer - points to an entry in the diffServQTable. Scheduler table pointer - points to an entry in the diffServSchedulerTable. Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to point to the next entry in the same table. This matches what is described in [MODEL]: "This model describes the configuration and management of a Diffserv interface in terms of a TCB that contains, by definition, zero or more Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler elements. These elements are arranged arbitrarily according to the policy being expressed, but always in the order here. Traffic may be classified; classified traffic may be metered; each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it, followed by drop algorithms; packets of the traffic stream may ultimately be stored into a queue and then be scheduled out to the next TCB or physical interface. " The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. It also got rid of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being considered or else the classifier element table is not necessary. When other filter is considered, we could always add more objects into the TCS table. I suspect we can further simplify the design of the meter, action, q and scheduler tables as well using the same technique. More emails to come. This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your thoughts? -faye -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, April 13, 2001 10:58 PM To: Faye Ly Cc: diffserv@ietf.org Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: >Hi, > >I apologize but I haven't gotten a chance to subscribe to the diffserv=20 >list yet. (With the IPO mailing list experience, I am not sure I want to=20 >:)-) Please feel free to forward this to the mailing list if appropriete. > >-faye > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > >Hi, > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > >1. The major problem I see with this MIB is the usage by NMS. The tables=20 >defined are not very 'friendly' for NMS retrieval. For example, in order=20 >to find out the filter being applied to a subscriber Joe. > > 1.1 NMS has to first get the logical interface entry for Joe and=20 > derive the datapath entry. For our discussion, I don't count the SNMP > packets required to get here. > > 1.2 It then issue a SNMP get to retrieve the classifier entry using=20 > the DataPathStart object. > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues=20 > another SNMP getnext to retrieve the Classifier element until all=20 > elements associated with this classifier are retrieved. > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > tuple classification entry for Joe. > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a=20 >particular subscriber. This is not scalable for NMS that typically has to=20 >deal with minimum thousands of subscribers. A suggestion is to eliminate=20 >the Classifier table and have the Datapath table simply provide an INTEGER=20 >pointer point to the Classifier ID in the Classifier Element Table OR=20 >meterId in the Meter table OR ... Note that the reverse pointer from=20 >the, say Meter table, back to the Classifier table requires the Classifier=20 >ID only. That is pretty much where we started out. We changed to RowPointer in=20 response to requests from the working group to allow folks to easily add new filter types, such as picking out messages by MAC Address etc. If you=20 have a specific proposal that would allow for the flexibility we were asked=20 to provide and addresses your concern (and I agree that this is a lot of round trips), I'd like to hear it. >2. For a full classifier, meter, actions, dropper, queue and scheduler can=20 >be linked all together via the rowPointer. This is although very smart >but again if the NMS is trying to get all the SLA provisioned on a single=20 >system. It has to traverse through 6 tables or more in order to get a=20 >single flow's SLA. Again not very scalable. An alternative is to place=20 >all these table pointers into a single data path table or profile=20 >table. The profile table will have separate object specifying the=20 >relationship between all these tables for a single SLA. The table pointer=20 >will be NULL if a certain SLA doesn't require, for example, any queue to=20 >be specified. The datapath table in turns will be assigned with a single=20 >profile. Could you be more specific? Can you advise how hierarchical systems such as=20 CBQ would be described using your approach? ------_=_NextPart_001_01C0C76B.61625EDE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A few comments for draft-ietf-diffserv-mib-09.txt

Fred,

Certainly.  More emails will follow this one as = the proposed changes may require more description.

Proposed change:

Change diffServDataPathStart to point to an entry in = the TCS table. 

TCS Table is defined as:

INDEX {TCBIndex}

OBJECTS

   Classifier Filter pointer - points to a = set of filters defined in
                  &nbs= p;            = ;  diffServSixTupleClfrTable.  Change
          &nbs= p;            = ;        the indexing of = diffServSixTupleClfrTable
          &nbs= p;            = ;        to double index = {ClassifierId, ClfrId}
          &nbs= p;            = ;        By specifying the classifier = ID in this
          &nbs= p;            = ;        object, NMS can easily = retrieve all the
          &nbs= p;            = ;        filters defined for this = classifier.
          &nbs= p;            = ;        The syntax of this object = will be
          &nbs= p;            = ;        the same as the ClassifierId = defined
          &nbs= p;            = ;        in the = diffServSixTupleClfrTable.
  
   Meter pointer - points to an entry in = the meter table as defined. 
          &nbs= p;       
   Action pointer - points to an entry in = the Action table as defined.
          &nbs= p;        
   Algorithm Drop pointer - points to an = entry in the Algorithm Drop Table.
   Queue table pointer - points to an entry = in the diffServQTable.
   Scheduler table pointer - points to an = entry in the diffServSchedulerTable.

Note that these pointers can be zeros meaning the = operation should be skipped.  Also the NEXT pointer should only be = used to point to the next entry in the same table.

This matches what is described in [MODEL]:

"This model describes the configuration and = management of a Diffserv
interface in terms of a TCB that contains, by = definition, zero or more
Classifier, Meter, Action, Algorithmic Dropper, Queue = and Scheduler
elements.  These elements are arranged = arbitrarily according to the
policy being expressed, but always in the order here. = Traffic may be
classified; classified traffic may be metered; each = stream of traffic
identified by a combination of classifiers and meters = may have some set
of actions performed on it, followed by drop = algorithms; packets of the
traffic stream may ultimately be stored into a queue = and then be
scheduled out to the next TCB or physical = interface.  "

The advantage of using the TCS table is to retrieve = all the relevant TCB information from one single entry.  It also = got rid of the Classifier and Classifier element table by using the = double indexing scheme.  Unless other classifer is being considered = or else the classifier element table is not necessary.  When other = filter is considered, we could always add more objects into the TCS = table.  I suspect we can further simplify the design of the meter, = action, q and scheduler tables as well using the same technique.  = More emails to come.

This is just a concept proposal.  I will send MIB = table definition out if this concept is acceptable and adoptable.  = Your thoughts?

-faye



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Friday, April 13, 2001 10:58 PM
To: Faye Ly
Cc: diffserv@ietf.org
Subject: Re: A few comments for = draft-ietf-diffserv-mib-09.txt


At 03:23 PM 4/13/2001 -0700, Faye Ly wrote:

>Hi,
>
>I apologize but I haven't gotten a chance to = subscribe to the diffserv
>list yet.  (With the IPO mailing list = experience, I am not sure I want to
>:)-)  Please feel free to forward this to = the mailing list if appropriete.
>
>-faye
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Hi,
>
>Here are some comments for = "draft-ietf-diffserv-mib-09.txt".
>
>1. The major problem I see with this MIB is the = usage by NMS.  The tables
>defined are not very 'friendly' for NMS = retrieval.  For example, in order
>to find out the filter being applied to a = subscriber Joe.
>
>     1.1 NMS has to first get = the logical interface entry for Joe and
> derive the datapath entry.  For our = discussion, I don't count the SNMP
> packets required to get here.
>
>     1.2 It then issue a SNMP = get to retrieve the classifier entry using
> the DataPathStart object.
>
>     1.3 Using the ClfrId = retrieved from the classifier table, NMS issues
> another SNMP getnext to retrieve the Classifier = element until all
> elements associated with this classifier are = retrieved.
>
>     1.4 NMS issue SNMP get = on each Specific object to retrieve the six
> tuple classification entry for Joe.
>
>It takes NMS a minimum 4 SNMP requests to = retrieve a single filter for a
>particular subscriber.  This is not scalable = for NMS that typically has to
>deal with minimum thousands of subscribers.  = A suggestion is to eliminate
>the Classifier table and have the Datapath table = simply provide an INTEGER
>pointer point to the Classifier ID in the = Classifier Element Table OR
>meterId in the Meter table OR ...   = Note that the reverse pointer from
>the, say Meter table, back to the Classifier = table requires the Classifier
>ID only.

That is pretty much where we started out. We changed = to RowPointer in
response to requests from the working group to allow = folks to easily add
new filter types, such as picking out messages by MAC = Address etc. If you
have a specific proposal that would allow for the = flexibility we were asked
to provide and addresses your concern (and I agree = that this is a lot of
round trips), I'd like to hear it.

>2. For a full classifier, meter, actions, dropper, = queue and scheduler can
>be linked all together via the rowPointer.  = This is although very smart
>but again if the NMS is trying to get all the SLA = provisioned on a single
>system.  It has to traverse through 6 tables = or more in order to get a
>single flow's SLA.  Again not very = scalable.  An alternative is to place
>all these table pointers into a single data path = table or profile
>table.  The profile table will have separate = object specifying the
>relationship between all these tables for a = single SLA.  The table pointer
>will be NULL if a certain SLA doesn't require, = for example, any queue to
>be specified.  The datapath table in turns = will be assigned with a single
>profile.

Could you be more specific? Can you advise how = hierarchical systems such as
CBQ would be described using your approach?

------_=_NextPart_001_01C0C76B.61625EDE-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 17 18:50:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17581 for ; Tue, 17 Apr 2001 18:50:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03044; Tue, 17 Apr 2001 15:18:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02992 for ; Tue, 17 Apr 2001 15:18:24 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13948 for ; Tue, 17 Apr 2001 15:18:21 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA70324; Tue, 17 Apr 2001 12:17:41 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA22272; Tue, 17 Apr 2001 12:17:45 -0700 Message-ID: <3ADC969F.1BE89CF6@hursley.ibm.com> Date: Tue, 17 Apr 2001 14:16:47 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Faye Ly CC: Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt References: <2BC6020788F6D04B82E413E548072A0907A2B3@sonscenter.SALIRA.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Faye, We did discuss several times whether TCBs should be explicit in the MIB, and a number of people indicated that this would be an unwanted constraint on implementations. So my guess is that we will get opinions both for and against a TCS table. Given that this MIB is already a year late, it would take a very clear WG consensus to make such a change. I'm not saying we won't get such a consensus, but I think Fred needs to get the next MIB version out without this change. So I request two actions: 1. Fred to get the MIB out on the basis of what he has already agreed to change. 2. Everybody who has an opinion to give us a binary answer within a week: - yes this TCS table is a good idea and the MIB should be changed - no it isn't a good idea. (Faye, the consensus on this will be formed on the diffserv list, and if you don't join the list, you can't be certain of seeing all the relevant mail.) Thanks Brian Carpenter diffserv co-chair > Faye Ly wrote: > > Fred, > > Certainly. More emails will follow this one as the proposed changes may require more description. > > Proposed change: > > Change diffServDataPathStart to point to an entry in the TCS table. > > TCS Table is defined as: > > INDEX {TCBIndex} > > OBJECTS > > Classifier Filter pointer - points to a set of filters defined in > diffServSixTupleClfrTable. Change > the indexing of diffServSixTupleClfrTable > to double index {ClassifierId, ClfrId} > By specifying the classifier ID in this > object, NMS can easily retrieve all the > filters defined for this classifier. > The syntax of this object will be > the same as the ClassifierId defined > in the diffServSixTupleClfrTable. > > Meter pointer - points to an entry in the meter table as defined. > > Action pointer - points to an entry in the Action table as defined. > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > Queue table pointer - points to an entry in the diffServQTable. > Scheduler table pointer - points to an entry in the diffServSchedulerTable. > > Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to > point to the next entry in the same table. > > This matches what is described in [MODEL]: > > "This model describes the configuration and management of a Diffserv > interface in terms of a TCB that contains, by definition, zero or more > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > elements. These elements are arranged arbitrarily according to the > policy being expressed, but always in the order here. Traffic may be > classified; classified traffic may be metered; each stream of traffic > identified by a combination of classifiers and meters may have some set > of actions performed on it, followed by drop algorithms; packets of the > traffic stream may ultimately be stored into a queue and then be > scheduled out to the next TCB or physical interface. " > > The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. It also got rid > of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being > considered or else the classifier element table is not necessary. When other filter is considered, we could always add more > objects into the TCS table. I suspect we can further simplify the design of the meter, action, q and scheduler tables as well > using the same technique. More emails to come. > > This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your > thoughts? > > -faye > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, April 13, 2001 10:58 PM > To: Faye Ly > Cc: diffserv@ietf.org > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > >Hi, > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > >list yet. (With the IPO mailing list experience, I am not sure I want to > >:)-) Please feel free to forward this to the mailing list if appropriete. > > > >-faye > > > >========================================================================================= > > > >Hi, > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > >1. The major problem I see with this MIB is the usage by NMS. The tables > >defined are not very 'friendly' for NMS retrieval. For example, in order > >to find out the filter being applied to a subscriber Joe. > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > derive the datapath entry. For our discussion, I don't count the SNMP > > packets required to get here. > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > > the DataPathStart object. > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > > another SNMP getnext to retrieve the Classifier element until all > > elements associated with this classifier are retrieved. > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > tuple classification entry for Joe. > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a > >particular subscriber. This is not scalable for NMS that typically has to > >deal with minimum thousands of subscribers. A suggestion is to eliminate > >the Classifier table and have the Datapath table simply provide an INTEGER > >pointer point to the Classifier ID in the Classifier Element Table OR > >meterId in the Meter table OR ... Note that the reverse pointer from > >the, say Meter table, back to the Classifier table requires the Classifier > >ID only. > > That is pretty much where we started out. We changed to RowPointer in > response to requests from the working group to allow folks to easily add > new filter types, such as picking out messages by MAC Address etc. If you > have a specific proposal that would allow for the flexibility we were asked > to provide and addresses your concern (and I agree that this is a lot of > round trips), I'd like to hear it. > > >2. For a full classifier, meter, actions, dropper, queue and scheduler can > >be linked all together via the rowPointer. This is although very smart > >but again if the NMS is trying to get all the SLA provisioned on a single > >system. It has to traverse through 6 tables or more in order to get a > >single flow's SLA. Again not very scalable. An alternative is to place > >all these table pointers into a single data path table or profile > >table. The profile table will have separate object specifying the > >relationship between all these tables for a single SLA. The table pointer > >will be NULL if a certain SLA doesn't require, for example, any queue to > >be specified. The datapath table in turns will be assigned with a single > >profile. > > Could you be more specific? Can you advise how hierarchical systems such as > CBQ would be described using your approach? -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 17 19:03:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17728 for ; Tue, 17 Apr 2001 19:03:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06349; Tue, 17 Apr 2001 18:43:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06249 for ; Tue, 17 Apr 2001 18:43:31 -0400 (EDT) Received: from zcars04f.ca.nortel.com ([47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17492 for ; Tue, 17 Apr 2001 18:43:32 -0400 (EDT) Message-Id: <200104172243.SAA17492@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 17 Apr 2001 18:42:51 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JASKQJ4J; Tue, 17 Apr 2001 18:42:50 -0400 Received: from tweedy (dhcp223-134.engeast.baynetworks.com [192.32.223.134]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWSBXY; Tue, 17 Apr 2001 18:42:49 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 17 Apr 2001 18:41:50 -0400 To: Faye Ly X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Cc: Fred Baker , diffserv In-Reply-To: <2BC6020788F6D04B82E413E548072A0907A2B3@sonscenter.SALIRA.C OM> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Orig: Content-Transfer-Encoding: quoted-printable Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: quoted-printable Faye:
We have been down this road before (may be not exactly but=20 similar).
Your proposal resembles what used to be in the "Target Table" of
the original DiffServ PIB.  The original Target Table entries tie together
Classifiers, Meters, Actions, Droppers, Queues, Schedulers.
There was consensus amongst the co-authors to make the PIB to look
like the MIB instead of the other way arround, hence the RowPointer
linkage today in both MIB and PIB.
There was also the concerns with SNMPCONF WG's usage of the
DiffServ MIB.
Just some history.
-- Kwok --


At 11:22 AM 4/17/01 -0700, Faye Ly wrote:

Fred,

Certainly.=A0 More emails will follow this one as the proposed changes may require more description.

Proposed change:

Change diffServDataPathStart to point to an entry in the TCS table.=A0

TCS Table is defined as:

INDEX {TCBIndex}

OBJECTS

=A0=A0 Classifier Filter pointer - points to a set of filters defined in
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 diffServSixTupleClfrTable.=A0 Change
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 the indexing of diffServSixTupleClfrTable
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to double index {ClassifierId, ClfrId}
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 By specifying the classifier ID in this
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 object, NMS can easily retrieve all the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 filters defined for this classifier.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The syntax of this object will be
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 the same as the ClassifierId defined
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in the diffServSixTupleClfrTable.
=A0=A0
=A0=A0 Meter pointer - points to an entry in the meter table as defined.=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0 Action pointer - points to an entry in the Action table as defined.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0
=A0=A0 Algorithm Drop pointer - points to an entry in the Algorithm Drop Table.
=A0=A0 Queue table pointer - points to an entry in the diffServQTable.
=A0=A0 Scheduler table pointer - points to an entry in the diffServSchedulerTable.

Note that these pointers can be zeros meaning the operation should be skipped.=A0 Also the NEXT pointer should only be used to point to the next entry in the same table.

This matches what is described in [MODEL]:

"This model describes the configuration and management of a Diffserv
interface in terms of a TCB that contains, by definition, zero or more
Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler
elements.=A0 These elements are arranged arbitrarily according to the
policy being expressed, but always in the order here. Traffic may be
classified; classified traffic may be metered; each stream of traffic
identified by a combination of classifiers and meters may have some set
of actions performed on it, followed by drop algorithms; packets of the
traffic stream may ultimately be stored into a queue and then be
scheduled out to the next TCB or physical interface.= =A0 "

The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry.=A0 It also got rid of the Classifier and Classifier element table by using the double indexing scheme.=A0 Unless other classifer is being considered or else the classifier element table is not necessary.=A0 When other filter is considered, we could always add more objects into the TCS table.=A0 I suspect we can further simplify the design of the meter, action, q and scheduler tables as well using the same technique.=A0 More emails to come.

This is just a concept proposal.=A0 I will send MIB table definition out if this concept is acceptable and adoptable.=A0 Your thoughts?

-faye


-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Friday, April 13, 2001 10:58 PM
To: Faye Ly
Cc: diffserv@ietf.org
Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt

At 03:23 PM 4/13/2001 -0700, Faye Ly wrote:

>Hi,
>
>I apologize but I haven't gotten a chance to subscribe to the diffserv
>list yet.=A0 (With the IPO mailing list experience, I am not sure I want to
>:)-)=A0 Please feel free to forward this to the mailing list if appropriete.
>
>-faye
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Hi,
>
>Here are some comments for "draft-ietf-diffserv-mib-09.txt".
>
>1. The major problem I see with this MIB is the usage by NMS.=A0 The tables
>defined are not very 'friendly' for NMS retrieval.=A0 For example, in order
>to find out the filter being applied to a subscriber Joe.
>
>=A0=A0=A0=A0 1.1 NMS has to first get the logical interface entry for Joe and
> derive the datapath entry.=A0 For our discussion, I don't count the SNMP
> packets required to get here.
>
>=A0=A0=A0=A0 1.2 It then issue a SNMP get to= retrieve the classifier entry using
> the DataPathStart object.
>
>=A0=A0=A0=A0 1.3 Using the ClfrId retrieved from t= he classifier table, NMS issues
> another SNMP getnext to retrieve the Classifier element until all
> elements associated with this classifier are retrieved.
>
>=A0=A0=A0=A0 1.4 NMS issue SNMP get on each Specif= ic object to retrieve the six
> tuple classification entry for Joe.
>
>It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a
>particular subscriber.=A0 This is not scalable for NMS that typically has to
>deal with minimum thousands of subscribers.=A0 A suggestion is to eliminate
>the Classifier table and have the Datapath table simply provide an INTEGER
>pointer point to the Classifier ID in the Classifier Element Table OR
>meterId in the Meter table OR ...=A0=A0 Note that the reverse pointer from
>the, say Meter table, back to the Classifier table requires the Classifier
>ID only.

That is pretty much where we started out. We changed to RowPointer in
response to requests from the working group to allow folks to easily add
new filter types, such as picking out messages by MAC Address etc. If you
have a specific proposal that would allow for the flexibility we were asked
to provide and addresses your concern (and I agree that this is a lot of
round trips), I'd like to hear it.

>2. For a full classifier, meter, actions, dropper, queue and scheduler can
>be linked all together via the rowPointer.=A0 This is although very smart
>but again if the NMS is trying to get all the SLA provisioned on a single
>system.=A0 It has to traverse through 6 tables or more in order to get a
>single flow's SLA.=A0 Again not very scalable.=A0 An alternative is to place
>all these table pointers into a single data path table or profile
>table.=A0 The profile table will have separate object specifying the
>relationship between all these tables for a single SLA.=A0 The table pointer
>will be NULL if a certain SLA doesn't require, for example, any queue to
>be specified.=A0 The datapath table in turns will be assigned with a single
>profile.

Could you be more specific? Can you advise how hierarchical systems such as
CBQ would be described using your approach?


_______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Apr 17 20:17:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18753 for ; Tue, 17 Apr 2001 20:17:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07328; Tue, 17 Apr 2001 19:46:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07297 for ; Tue, 17 Apr 2001 19:46:08 -0400 (EDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18460 for ; Tue, 17 Apr 2001 19:46:10 -0400 (EDT) Received: from ANDREWHOME (user-vcauohm.dsl.mindspring.com [216.175.98.54]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA09733; Tue, 17 Apr 2001 16:43:22 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Kwok-Ho Chan" Cc: "diffserv" , "Faye Ly" Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Date: Tue, 17 Apr 2001 16:56:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <200104172243.SAA17492@ietf.org> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Faye's concern gets to the heart of whether it is best to try to have a single data structure to access information for configuration operations (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT"). Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted Diffserv Schemas, I think the current state of the IETF efforts on this topic can best be described as "pragmatic" (or, less charitably, as "confused"). As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides some good examples of how) and is, on its own without help from the snmpconf Diffserv Policy MIB, highly suboptimal for configuration. My advice would be to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise before designing any Diffserv configuration application (and you'll probably be needing to write some proprietary MIBs for efficient monitoring of Diffserv on anything other than a small scale). Andrew (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB documents) -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Kwok-Ho Chan Sent: Tuesday, April 17, 2001 3:42 PM To: Faye Ly Cc: Fred Baker; diffserv Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Faye: We have been down this road before (may be not exactly but similar). Your proposal resembles what used to be in the "Target Table" of the original DiffServ PIB. The original Target Table entries tie together Classifiers, Meters, Actions, Droppers, Queues, Schedulers. There was consensus amongst the co-authors to make the PIB to look like the MIB instead of the other way arround, hence the RowPointer linkage today in both MIB and PIB. There was also the concerns with SNMPCONF WG's usage of the DiffServ MIB. Just some history. -- Kwok -- At 11:22 AM 4/17/01 -0700, Faye Ly wrote: Fred, Certainly. More emails will follow this one as the proposed changes may require more description. Proposed change: Change diffServDataPathStart to point to an entry in the TCS table. TCS Table is defined as: INDEX {TCBIndex} OBJECTS Classifier Filter pointer - points to a set of filters defined in diffServSixTupleClfrTable. Change the indexing of diffServSixTupleClfrTable to double index {ClassifierId, ClfrId} By specifying the classifier ID in this object, NMS can easily retrieve all the filters defined for this classifier. The syntax of this object will be the same as the ClassifierId defined in the diffServSixTupleClfrTable. Meter pointer - points to an entry in the meter table as defined. Action pointer - points to an entry in the Action table as defined. Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. Queue table pointer - points to an entry in the diffServQTable. Scheduler table pointer - points to an entry in the diffServSchedulerTable. Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to point to the next entry in the same table. This matches what is described in [MODEL]: "This model describes the configuration and management of a Diffserv interface in terms of a TCB that contains, by definition, zero or more Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler elements. These elements are arranged arbitrarily according to the policy being expressed, but always in the order here. Traffic may be classified; classified traffic may be metered; each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it, followed by drop algorithms; packets of the traffic stream may ultimately be stored into a queue and then be scheduled out to the next TCB or physical interface. " The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. It also got rid of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being considered or else the classifier element table is not necessary. When other filter is considered, we could always add more objects into the TCS table. I suspect we can further simplify the design of the meter, action, q and scheduler tables as well using the same technique. More emails to come. This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your thoughts? -faye -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, April 13, 2001 10:58 PM To: Faye Ly Cc: diffserv@ietf.org Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: >Hi, > >I apologize but I haven't gotten a chance to subscribe to the diffserv >list yet. (With the IPO mailing list experience, I am not sure I want to >:)-) Please feel free to forward this to the mailing list if appropriete. > >-faye > >=========================================================================== ============== > >Hi, > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > >1. The major problem I see with this MIB is the usage by NMS. The tables >defined are not very 'friendly' for NMS retrieval. For example, in order >to find out the filter being applied to a subscriber Joe. > > 1.1 NMS has to first get the logical interface entry for Joe and > derive the datapath entry. For our discussion, I don't count the SNMP > packets required to get here. > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > the DataPathStart object. > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > another SNMP getnext to retrieve the Classifier element until all > elements associated with this classifier are retrieved. > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > tuple classification entry for Joe. > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a >particular subscriber. This is not scalable for NMS that typically has to >deal with minimum thousands of subscribers. A suggestion is to eliminate >the Classifier table and have the Datapath table simply provide an INTEGER >pointer point to the Classifier ID in the Classifier Element Table OR >meterId in the Meter table OR ... Note that the reverse pointer from >the, say Meter table, back to the Classifier table requires the Classifier >ID only. That is pretty much where we started out. We changed to RowPointer in response to requests from the working group to allow folks to easily add new filter types, such as picking out messages by MAC Address etc. If you have a specific proposal that would allow for the flexibility we were asked to provide and addresses your concern (and I agree that this is a lot of round trips), I'd like to hear it. >2. For a full classifier, meter, actions, dropper, queue and scheduler can >be linked all together via the rowPointer. This is although very smart >but again if the NMS is trying to get all the SLA provisioned on a single >system. It has to traverse through 6 tables or more in order to get a >single flow's SLA. Again not very scalable. An alternative is to place >all these table pointers into a single data path table or profile >table. The profile table will have separate object specifying the >relationship between all these tables for a single SLA. The table pointer >will be NULL if a certain SLA doesn't require, for example, any queue to >be specified. The datapath table in turns will be assigned with a single >profile. Could you be more specific? Can you advise how hierarchical systems such as CBQ would be described using your approach? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 05:01:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08308 for ; Wed, 18 Apr 2001 05:01:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20633; Wed, 18 Apr 2001 04:26:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20604 for ; Wed, 18 Apr 2001 04:26:27 -0400 (EDT) Received: from lisanza.net ([151.29.214.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08026 for ; Wed, 18 Apr 2001 04:26:27 -0400 (EDT) Received: from covalent.net (localhost [127.0.0.1]) by lisanza.net (8.9.3/8.9.3) with ESMTP id KAA00779; Wed, 18 Apr 2001 10:25:01 +0200 (CEST) (envelope-from harrie@covalent.net) Message-ID: <3ADD44B9.76905FF@covalent.net> Date: Wed, 18 Apr 2001 09:39:37 +0200 From: Harrie Hazewinkel Organization: Covalent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Faye Ly , Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt References: <2BC6020788F6D04B82E413E548072A0907A2B3@sonscenter.SALIRA.COM> <3ADC969F.1BE89CF6@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: [snip] > 2. Everybody who has an opinion to give us a binary answer within a week: > - yes this TCS table is a good idea and the MIB should be changed > - no it isn't a good idea. Looking just to the proposal as MIB designer/reviewer, NO. This proposal is broken. Why?? see below. > > > > Change diffServDataPathStart to point to an entry in the TCS table. If you make this change a TCS/TCB is required. Which is not the case. You still want the 'diffServDataPathStart' to point to the other 4 datapath elements. You make a requirement for the TCB. > > > > TCS Table is defined as: > > > > INDEX {TCBIndex} > > > > OBJECTS > > > > Classifier Filter pointer - points to a set of filters defined in > > diffServSixTupleClfrTable. Change > > the indexing of diffServSixTupleClfrTable > > to double index {ClassifierId, ClfrId} > > By specifying the classifier ID in this > > object, NMS can easily retrieve all the > > filters defined for this classifier. > > The syntax of this object will be > > the same as the ClassifierId defined > > in the diffServSixTupleClfrTable. > > > > Meter pointer - points to an entry in the meter table as defined. > > > > Action pointer - points to an entry in the Action table as defined. > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > Queue table pointer - points to an entry in the diffServQTable. > > Scheduler table pointer - points to an entry in the diffServSchedulerTable. > > > > Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to > > point to the next entry in the same table. Does this mean that you say a TCB has either 1 of these pointers?? If the Classifier Filter pointer is 'zeroDotZero' you must follow the Meter pointer. If the Meter pointer is zeroDotZero you must follow the Action Pointer. However, you allow all pointers fill with RowPointers to datapath elements. The elements are also ordered in a sequential path traffic can follow. In this proposal there is no such thing. Or should I assume that the order is, classifier, meter, action, algorithmic dropper, Queue table, Scheduler?? Maybe people want to have different orders. This does not work. You only create more confusion for as well MIB implementors as well management application. The DIFFSERV-MIB already has this. You just put the RowPointer to the first datapath element in the diffServDataPathSTart. > > > > This matches what is described in [MODEL]: > > > > "This model describes the configuration and management of a Diffserv > > interface in terms of a TCB that contains, by definition, zero or more > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > elements. These elements are arranged arbitrarily according to the > > policy being expressed, but always in the order here. Traffic may be > > classified; classified traffic may be metered; each stream of traffic > > identified by a combination of classifiers and meters may have some set > > of actions performed on it, followed by drop algorithms; packets of the > > traffic stream may ultimately be stored into a queue and then be > > scheduled out to the next TCB or physical interface. " No this is not the same. Just having a bunch of datapaths with no ordering is not the same. And you just want to have just a bunch of datapaths. It is also a bit unfortenate that TCB is still mentioned here. It is legacy text to be removed. > > > > The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. No, the ordering information is not there. It also assumes there is only 1 of each of the datapath elements in a TCB. > > It also got rid > > of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being > > considered or else the classifier element table is not necessary. You need that to make more classified traffic. If I understand your proposal you just want 1 classified stream. Diffserv allows for more. > > When other filter is considered, we could always add more > > objects into the TCS table. You can add indeed more objects in the TCS table, but once the table is defined it is defined and static. Are you proposing here that you want to add another column to the table if you need to have 2 meters?? That is not possible. You only can add then more entries, but since they will have a different index all objects (and thus the datapath elements) do not belong to the same TCB. > > I suspect we can further simplify the design of the meter, action, q and scheduler tables as well > > using the same technique. More emails to come. > > > > This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your > > thoughts? Do I have to say more?? Harrie -- phone: +39-3474932300 http://www.lisanza.net/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 12:38:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14064 for ; Wed, 18 Apr 2001 12:38:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25083; Wed, 18 Apr 2001 09:30:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25052 for ; Wed, 18 Apr 2001 09:30:31 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10894 for ; Wed, 18 Apr 2001 09:30:30 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA30096; Wed, 18 Apr 2001 14:29:52 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA34702; Wed, 18 Apr 2001 14:29:42 +0100 Message-ID: <3ADD965C.915DA3D6@hursley.ibm.com> Date: Wed, 18 Apr 2001 08:27:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ah_smith@pacbell.net CC: Kwok-Ho Chan , diffserv , Faye Ly Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, It has always been understood that either SNMPCONF or the PIB would be necessary for diffserv configuration - indeed that is a major reason why SNMPCONF was started at all. There is no news there. Yes, it's pragmatic, but I don't see the confusion. Since the WG agreed that the MIB should not represent TCBs, you and Faye need to respond to Harrie's arguments. Multiple SNMP GETs are suboptimal for monitoring? Is that news? Brian Andrew Smith wrote: > > Faye's concern gets to the heart of whether it is best to try to have a > single data structure to access information for configuration operations > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT"). > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > Diffserv Schemas, I think the current state of the IETF efforts on this > topic can best be described as "pragmatic" (or, less charitably, as > "confused"). > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides > some good examples of how) and is, on its own without help from the snmpconf > Diffserv Policy MIB, highly suboptimal for configuration. My advice would be > to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise > before designing any Diffserv configuration application (and you'll probably > be needing to write some proprietary MIBs for efficient monitoring of > Diffserv on anything other than a small scale). > > Andrew > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > documents) > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > Kwok-Ho Chan > Sent: Tuesday, April 17, 2001 3:42 PM > To: Faye Ly > Cc: Fred Baker; diffserv > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Faye: > We have been down this road before (may be not exactly but similar). > Your proposal resembles what used to be in the "Target Table" of > the original DiffServ PIB. The original Target Table entries tie together > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > There was consensus amongst the co-authors to make the PIB to look > like the MIB instead of the other way arround, hence the RowPointer > linkage today in both MIB and PIB. > There was also the concerns with SNMPCONF WG's usage of the > DiffServ MIB. > Just some history. > -- Kwok -- > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > Fred, > > Certainly. More emails will follow this one as the proposed changes may > require more description. > > Proposed change: > > Change diffServDataPathStart to point to an entry in the TCS table. > > TCS Table is defined as: > > INDEX {TCBIndex} > > OBJECTS > > Classifier Filter pointer - points to a set of filters defined in > diffServSixTupleClfrTable. Change > the indexing of diffServSixTupleClfrTable > to double index {ClassifierId, ClfrId} > By specifying the classifier ID in this > object, NMS can easily retrieve all the > filters defined for this classifier. > The syntax of this object will be > the same as the ClassifierId defined > in the diffServSixTupleClfrTable. > > Meter pointer - points to an entry in the meter table as defined. > > Action pointer - points to an entry in the Action table as defined. > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > Queue table pointer - points to an entry in the diffServQTable. > Scheduler table pointer - points to an entry in the > diffServSchedulerTable. > > Note that these pointers can be zeros meaning the operation should be > skipped. Also the NEXT pointer should only be used to point to the next > entry in the same table. > > This matches what is described in [MODEL]: > > "This model describes the configuration and management of a Diffserv > interface in terms of a TCB that contains, by definition, zero or more > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > elements. These elements are arranged arbitrarily according to the > policy being expressed, but always in the order here. Traffic may be > classified; classified traffic may be metered; each stream of traffic > identified by a combination of classifiers and meters may have some set > of actions performed on it, followed by drop algorithms; packets of the > traffic stream may ultimately be stored into a queue and then be > scheduled out to the next TCB or physical interface. " > > The advantage of using the TCS table is to retrieve all the relevant TCB > information from one single entry. It also got rid of the Classifier and > Classifier element table by using the double indexing scheme. Unless other > classifer is being considered or else the classifier element table is not > necessary. When other filter is considered, we could always add more > objects into the TCS table. I suspect we can further simplify the design of > the meter, action, q and scheduler tables as well using the same technique. > More emails to come. > > This is just a concept proposal. I will send MIB table definition out if > this concept is acceptable and adoptable. Your thoughts? > > -faye > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, April 13, 2001 10:58 PM > To: Faye Ly > Cc: diffserv@ietf.org > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > >Hi, > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > >list yet. (With the IPO mailing list experience, I am not sure I want to > >:)-) Please feel free to forward this to the mailing list if appropriete. > > > >-faye > > > >=========================================================================== > ============== > > > >Hi, > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > >1. The major problem I see with this MIB is the usage by NMS. The tables > >defined are not very 'friendly' for NMS retrieval. For example, in order > >to find out the filter being applied to a subscriber Joe. > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > derive the datapath entry. For our discussion, I don't count the SNMP > > packets required to get here. > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > > the DataPathStart object. > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > > another SNMP getnext to retrieve the Classifier element until all > > elements associated with this classifier are retrieved. > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > tuple classification entry for Joe. > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a > >particular subscriber. This is not scalable for NMS that typically has to > >deal with minimum thousands of subscribers. A suggestion is to eliminate > >the Classifier table and have the Datapath table simply provide an INTEGER > >pointer point to the Classifier ID in the Classifier Element Table OR > >meterId in the Meter table OR ... Note that the reverse pointer from > >the, say Meter table, back to the Classifier table requires the Classifier > >ID only. > > That is pretty much where we started out. We changed to RowPointer in > response to requests from the working group to allow folks to easily add > new filter types, such as picking out messages by MAC Address etc. If you > have a specific proposal that would allow for the flexibility we were asked > to provide and addresses your concern (and I agree that this is a lot of > round trips), I'd like to hear it. > > >2. For a full classifier, meter, actions, dropper, queue and scheduler can > >be linked all together via the rowPointer. This is although very smart > >but again if the NMS is trying to get all the SLA provisioned on a single > >system. It has to traverse through 6 tables or more in order to get a > >single flow's SLA. Again not very scalable. An alternative is to place > >all these table pointers into a single data path table or profile > >table. The profile table will have separate object specifying the > >relationship between all these tables for a single SLA. The table pointer > >will be NULL if a certain SLA doesn't require, for example, any queue to > >be specified. The datapath table in turns will be assigned with a single > >profile. > > Could you be more specific? Can you advise how hierarchical systems such as > CBQ would be described using your approach? > > _______________________________________________ diffserv mailing list > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 13:47:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14799 for ; Wed, 18 Apr 2001 13:47:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28772; Wed, 18 Apr 2001 13:07:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28741 for ; Wed, 18 Apr 2001 13:07:54 -0400 (EDT) Received: from ostrich.mail.pas.earthlink.net (ostrich.mail.pas.earthlink.net [207.217.120.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14436 for ; Wed, 18 Apr 2001 13:07:56 -0400 (EDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by ostrich.mail.pas.earthlink.net (8.9.3/8.9.3) with ESMTP id JAA10554 for ; Wed, 18 Apr 2001 09:56:06 -0700 (PDT) Received: from ANDREWHOME (user-2ivfiq0.dialup.mindspring.com [165.247.203.64]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA17156; Wed, 18 Apr 2001 09:14:00 -0700 (PDT) From: "Andrew Smith" To: "Brian E Carpenter" Cc: "diffserv" Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Date: Wed, 18 Apr 2001 09:27:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <3ADD965C.915DA3D6@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, My issue is that compromises were made in the Diffserv MIB in order to accomodate those who wanted to use it for configuration. Those compromises make it quite a lot less efficient for monitoring than it needs to be. You are oversimplifying with your somewhat flippant comment "Multiple SNMP GETs are suboptimal for monitoring? Is that news?". We have been over the specific inefficiencies on this list and the WG consensus was to keep them in there. I am not supporting Faye's specific changes, although I don't agree with all of Harrie's criticisms of it. I'm merely pointing out some characteristics of the Diffserv MIB that are not obvious until you get deep into the details. Standards'-track MIBs are not required to have an "Applicability Statement" attached but perhaps they should be. Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, April 18, 2001 6:28 AM To: ah_smith@pacbell.net Cc: Kwok-Ho Chan; diffserv; Faye Ly Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Andrew, It has always been understood that either SNMPCONF or the PIB would be necessary for diffserv configuration - indeed that is a major reason why SNMPCONF was started at all. There is no news there. Yes, it's pragmatic, but I don't see the confusion. Since the WG agreed that the MIB should not represent TCBs, you and Faye need to respond to Harrie's arguments. Multiple SNMP GETs are suboptimal for monitoring? Is that news? Brian Andrew Smith wrote: > > Faye's concern gets to the heart of whether it is best to try to have a > single data structure to access information for configuration operations > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT"). > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > Diffserv Schemas, I think the current state of the IETF efforts on this > topic can best be described as "pragmatic" (or, less charitably, as > "confused"). > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides > some good examples of how) and is, on its own without help from the snmpconf > Diffserv Policy MIB, highly suboptimal for configuration. My advice would be > to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise > before designing any Diffserv configuration application (and you'll probably > be needing to write some proprietary MIBs for efficient monitoring of > Diffserv on anything other than a small scale). > > Andrew > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > documents) > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > Kwok-Ho Chan > Sent: Tuesday, April 17, 2001 3:42 PM > To: Faye Ly > Cc: Fred Baker; diffserv > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Faye: > We have been down this road before (may be not exactly but similar). > Your proposal resembles what used to be in the "Target Table" of > the original DiffServ PIB. The original Target Table entries tie together > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > There was consensus amongst the co-authors to make the PIB to look > like the MIB instead of the other way arround, hence the RowPointer > linkage today in both MIB and PIB. > There was also the concerns with SNMPCONF WG's usage of the > DiffServ MIB. > Just some history. > -- Kwok -- > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > Fred, > > Certainly. More emails will follow this one as the proposed changes may > require more description. > > Proposed change: > > Change diffServDataPathStart to point to an entry in the TCS table. > > TCS Table is defined as: > > INDEX {TCBIndex} > > OBJECTS > > Classifier Filter pointer - points to a set of filters defined in > diffServSixTupleClfrTable. Change > the indexing of diffServSixTupleClfrTable > to double index {ClassifierId, ClfrId} > By specifying the classifier ID in this > object, NMS can easily retrieve all the > filters defined for this classifier. > The syntax of this object will be > the same as the ClassifierId defined > in the diffServSixTupleClfrTable. > > Meter pointer - points to an entry in the meter table as defined. > > Action pointer - points to an entry in the Action table as defined. > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > Queue table pointer - points to an entry in the diffServQTable. > Scheduler table pointer - points to an entry in the > diffServSchedulerTable. > > Note that these pointers can be zeros meaning the operation should be > skipped. Also the NEXT pointer should only be used to point to the next > entry in the same table. > > This matches what is described in [MODEL]: > > "This model describes the configuration and management of a Diffserv > interface in terms of a TCB that contains, by definition, zero or more > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > elements. These elements are arranged arbitrarily according to the > policy being expressed, but always in the order here. Traffic may be > classified; classified traffic may be metered; each stream of traffic > identified by a combination of classifiers and meters may have some set > of actions performed on it, followed by drop algorithms; packets of the > traffic stream may ultimately be stored into a queue and then be > scheduled out to the next TCB or physical interface. " > > The advantage of using the TCS table is to retrieve all the relevant TCB > information from one single entry. It also got rid of the Classifier and > Classifier element table by using the double indexing scheme. Unless other > classifer is being considered or else the classifier element table is not > necessary. When other filter is considered, we could always add more > objects into the TCS table. I suspect we can further simplify the design of > the meter, action, q and scheduler tables as well using the same technique. > More emails to come. > > This is just a concept proposal. I will send MIB table definition out if > this concept is acceptable and adoptable. Your thoughts? > > -faye > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, April 13, 2001 10:58 PM > To: Faye Ly > Cc: diffserv@ietf.org > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > >Hi, > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > >list yet. (With the IPO mailing list experience, I am not sure I want to > >:)-) Please feel free to forward this to the mailing list if appropriete. > > > >-faye > > > >=========================================================================== > ============== > > > >Hi, > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > >1. The major problem I see with this MIB is the usage by NMS. The tables > >defined are not very 'friendly' for NMS retrieval. For example, in order > >to find out the filter being applied to a subscriber Joe. > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > derive the datapath entry. For our discussion, I don't count the SNMP > > packets required to get here. > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > > the DataPathStart object. > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > > another SNMP getnext to retrieve the Classifier element until all > > elements associated with this classifier are retrieved. > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > tuple classification entry for Joe. > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a > >particular subscriber. This is not scalable for NMS that typically has to > >deal with minimum thousands of subscribers. A suggestion is to eliminate > >the Classifier table and have the Datapath table simply provide an INTEGER > >pointer point to the Classifier ID in the Classifier Element Table OR > >meterId in the Meter table OR ... Note that the reverse pointer from > >the, say Meter table, back to the Classifier table requires the Classifier > >ID only. > > That is pretty much where we started out. We changed to RowPointer in > response to requests from the working group to allow folks to easily add > new filter types, such as picking out messages by MAC Address etc. If you > have a specific proposal that would allow for the flexibility we were asked > to provide and addresses your concern (and I agree that this is a lot of > round trips), I'd like to hear it. > > >2. For a full classifier, meter, actions, dropper, queue and scheduler can > >be linked all together via the rowPointer. This is although very smart > >but again if the NMS is trying to get all the SLA provisioned on a single > >system. It has to traverse through 6 tables or more in order to get a > >single flow's SLA. Again not very scalable. An alternative is to place > >all these table pointers into a single data path table or profile > >table. The profile table will have separate object specifying the > >relationship between all these tables for a single SLA. The table pointer > >will be NULL if a certain SLA doesn't require, for example, any queue to > >be specified. The datapath table in turns will be assigned with a single > >profile. > > Could you be more specific? Can you advise how hierarchical systems such as > CBQ would be described using your approach? > > _______________________________________________ diffserv mailing list > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 14:24:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15218 for ; Wed, 18 Apr 2001 14:24:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29584; Wed, 18 Apr 2001 13:51:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29475 for ; Wed, 18 Apr 2001 13:51:46 -0400 (EDT) Received: from sonscenter.SALIRA.COM ([64.168.86.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14889 for ; Wed, 18 Apr 2001 13:51:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C830.3BFAF7E4" Date: Wed, 18 Apr 2001 10:51:45 -0700 Message-ID: <2BC6020788F6D04B82E413E548072A0907A2B5@sonscenter.SALIRA.COM> Thread-Topic: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Thread-Index: AcDH4TfmsQffZa91RrSP7FXKCXgT7wATcU3w From: "Faye Ly" To: "Harrie Hazewinkel" , "Brian E Carpenter" Cc: "Fred Baker" , Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C0C830.3BFAF7E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harrie, RowPointer is used to represent a 1:1 relationship between table entries. Straight integer pointer (for example, using the index field from another table) can be used to represent 1:N relationship between entries from 2 tables. The proposal actually proposes using the straight integer as the pointer, not RowPointer. In another words, you can easily group a group of classifier elements into one classifier and have the ClassifierStart simply point to the classifier index. NMS can easily traverse the classifier element table to retrieve all the classifier elements associated with one classifier. For example: To traverse the classifier element table that is sorted as: ClassifierId ClassifierElementId 1 1 1 2 1 3 2 1 2 2 NMS retrieves the ClassifierStart that is set to 1, it then issues SNMP getbulk with the following instance value: 1,0 Agent will return {1,1 1,2 and 1,3 ...} however many rows that is required in the getbulk request. This will save a lot of management bandwidth on the wire and NMS has all the classifier elements associated with one classifier in one SNMP round trip. =20 -faye -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@covalent.net] Sent: Wednesday, April 18, 2001 12:40 AM To: Brian E Carpenter Cc: Faye Ly; Fred Baker; diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Brian E Carpenter wrote: [snip] > 2. Everybody who has an opinion to give us a binary answer within a week: > - yes this TCS table is a good idea and the MIB should be changed > - no it isn't a good idea. Looking just to the proposal as MIB designer/reviewer, NO. This proposal is broken. Why?? see below. > > > > Change diffServDataPathStart to point to an entry in the TCS table. If you make this change a TCS/TCB is required. Which is not the case. You still want the 'diffServDataPathStart' to point to the other 4 datapath elements. You make a requirement for the TCB. > > > > TCS Table is defined as: > > > > INDEX {TCBIndex} > > > > OBJECTS > > > > Classifier Filter pointer - points to a set of filters defined in > > diffServSixTupleClfrTable. Change > > the indexing of diffServSixTupleClfrTable > > to double index {ClassifierId, ClfrId} > > By specifying the classifier ID in this > > object, NMS can easily retrieve all the > > filters defined for this classifier. > > The syntax of this object will be > > the same as the ClassifierId defined > > in the diffServSixTupleClfrTable. > > > > Meter pointer - points to an entry in the meter table as defined. > > > > Action pointer - points to an entry in the Action table as defined. > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > Queue table pointer - points to an entry in the diffServQTable. > > Scheduler table pointer - points to an entry in the diffServSchedulerTable. > > > > Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to > > point to the next entry in the same table. Does this mean that you say a TCB has either 1 of these pointers?? If the Classifier Filter pointer is 'zeroDotZero' you must follow the Meter pointer. If the Meter pointer is zeroDotZero you must follow the Action Pointer. However, you allow all pointers fill with RowPointers to datapath=20 elements. The elements are also ordered in a sequential path traffic can follow. In this proposal there is no such thing. Or should I assume that the order is, classifier, meter, action, algorithmic dropper, Queue table, Scheduler?? Maybe people want to have different orders. This does not work. You only create more confusion for as well MIB implementors as well management application. The DIFFSERV-MIB already has this. You just put the RowPointer to the first datapath element in the diffServDataPathSTart. > > > > This matches what is described in [MODEL]: > > > > "This model describes the configuration and management of a Diffserv > > interface in terms of a TCB that contains, by definition, zero or more > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > elements. These elements are arranged arbitrarily according to the > > policy being expressed, but always in the order here. Traffic may be > > classified; classified traffic may be metered; each stream of traffic > > identified by a combination of classifiers and meters may have some set > > of actions performed on it, followed by drop algorithms; packets of the > > traffic stream may ultimately be stored into a queue and then be > > scheduled out to the next TCB or physical interface. " No this is not the same. Just having a bunch of datapaths with no ordering is not the same. And you just want to have just a bunch of datapaths. It is also a bit unfortenate that TCB is still mentioned here. It is legacy text to be removed. > > > > The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. No, the ordering information is not there. It also assumes there is only 1 of each of the datapath elements in a TCB. > > It also got rid > > of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being > > considered or else the classifier element table is not necessary.=20 You need that to make more classified traffic. If I understand your proposal you just want 1 classified stream. Diffserv allows for more. > > When other filter is considered, we could always add more > > objects into the TCS table.=20 You can add indeed more objects in the TCS table, but once the table is defined it is defined and static. Are you proposing here that you want to add another column to the table if you need to have 2 meters?? That is not possible. You only can add then more entries, but since they will have a different index all objects (and thus the datapath elements) do not belong to the same TCB. > > I suspect we can further simplify the design of the meter, action, q and scheduler tables as well > > using the same technique. More emails to come. > > > > This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your > > thoughts? Do I have to say more?? Harrie --=20 phone: +39-3474932300 http://www.lisanza.net/ ------_=_NextPart_001_01C0C830.3BFAF7E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RE: A few comments for = draft-ietf-diffserv-mib-09.txt

Harrie,

RowPointer is used to represent a 1:1 relationship = between table entries.  Straight integer pointer (for example, = using the index field from another table) can be used to represent 1:N = relationship between entries from 2 tables.  The proposal actually = proposes using the straight integer as the pointer, not = RowPointer.  In another words, you can easily group a group of = classifier elements into one classifier and have the ClassifierStart = simply point to the classifier index.  NMS can easily traverse the = classifier element table to retrieve all the classifier elements = associated with one classifier.  For example:

To traverse the classifier element table that is = sorted as:

ClassifierId   ClassifierElementId
1          &nb= sp;   1
1          &nb= sp;   2
1          &nb= sp;   3
2          &nb= sp;   1
2          &nb= sp;   2

NMS retrieves the ClassifierStart that is set to 1, it = then issues SNMP getbulk with the following instance value:

1,0

Agent will return {1,1 1,2 and 1,3 ...}  however = many rows that is required in the getbulk request.  This will save = a lot of management bandwidth on the wire and NMS has all the classifier = elements associated with one classifier in one SNMP round trip.  =

-faye

-----Original Message-----
From: Harrie Hazewinkel [mailto:harrie@covalent.net]
Sent: Wednesday, April 18, 2001 12:40 AM
To: Brian E Carpenter
Cc: Faye Ly; Fred Baker; diffserv@ietf.org
Subject: Re: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt


Brian E Carpenter wrote:
[snip]
> 2. Everybody who has an opinion to give us a = binary answer within a week:
>     - yes this TCS table is = a good idea and the MIB should be changed
>     - no it isn't a good = idea.

Looking just to the proposal as MIB designer/reviewer, = NO.
This proposal is broken. Why?? see below.

> >
> > Change diffServDataPathStart to point to an = entry in the TCS table.

If you make this change a TCS/TCB is required. Which = is not the case.
You still want the 'diffServDataPathStart' to point = to the other 4
datapath elements. You make a requirement for the = TCB.

> >
> > TCS Table is defined as:
> >
> > INDEX {TCBIndex}
> >
> > OBJECTS
> >
> >    Classifier Filter pointer = - points to a set of filters defined in
> = >           &nb= sp;           &nbs= p;          = diffServSixTupleClfrTable.  Change
> = >           &nb= sp;           &nbs= p;        the indexing of = diffServSixTupleClfrTable
> = >           &nb= sp;           &nbs= p;        to double index = {ClassifierId, ClfrId}
> = >           &nb= sp;           &nbs= p;        By specifying the = classifier ID in this
> = >           &nb= sp;           &nbs= p;        object, NMS can easily = retrieve all the
> = >           &nb= sp;           &nbs= p;        filters defined for this = classifier.
> = >           &nb= sp;           &nbs= p;        The syntax of this object = will be
> = >           &nb= sp;           &nbs= p;        the same as the = ClassifierId defined
> = >           &nb= sp;           &nbs= p;        in the = diffServSixTupleClfrTable.
> >
> >    Meter pointer - points to = an entry in the meter table as defined.
> >
> >    Action pointer - points = to an entry in the Action table as defined.
> >
> >    Algorithm Drop pointer - = points to an entry in the Algorithm Drop Table.
> >    Queue table pointer - = points to an entry in the diffServQTable.
> >    Scheduler table pointer - = points to an entry in the diffServSchedulerTable.
> >
> > Note that these pointers can be zeros = meaning the operation should be skipped.  Also the NEXT pointer = should only be used to

> > point to the next entry in the same = table.

Does this mean that you say a TCB has either 1 of = these pointers??
If the Classifier Filter pointer is 'zeroDotZero' you = must
follow the Meter pointer. If the Meter pointer is = zeroDotZero
you must follow the Action Pointer.

However, you allow all pointers fill with RowPointers = to datapath
elements. The elements are also ordered in a = sequential path
traffic can follow. In this proposal there is no such = thing.
Or should I assume that the order is, classifier, = meter, action,
algorithmic dropper, Queue table, Scheduler??
Maybe people want to have different orders.

This does not work. You only create more confusion = for
as well MIB implementors as well management = application.
The DIFFSERV-MIB already has this. You just put the = RowPointer
to the first datapath element in the = diffServDataPathSTart.

> >
> > This matches what is described in = [MODEL]:
> >
> > "This model describes the = configuration and management of a Diffserv
> > interface in terms of a TCB that contains, = by definition, zero or more
> > Classifier, Meter, Action, Algorithmic = Dropper, Queue and Scheduler
> > elements.  These elements are arranged = arbitrarily according to the
> > policy being expressed, but always in the = order here. Traffic may be
> > classified; classified traffic may be = metered; each stream of traffic
> > identified by a combination of classifiers = and meters may have some set
> > of actions performed on it, followed by = drop algorithms; packets of the
> > traffic stream may ultimately be stored = into a queue and then be
> > scheduled out to the next TCB or physical = interface.  "

No this is not the same. Just having a bunch of = datapaths with no
ordering
is not the same. And you just want to have just a = bunch of datapaths.
It is also a bit unfortenate that TCB is still = mentioned here.
It is legacy text to be removed.

> >
> > The advantage of using the TCS table is to = retrieve all the relevant TCB information from one single entry.

No, the ordering information is not there. It also = assumes there is only
1
of each of the datapath elements in a TCB.

> >  It also got rid
> > of the Classifier and Classifier element = table by using the double indexing scheme.  Unless other classifer = is being

> > considered or else the classifier element = table is not necessary.

You need that to make more classified traffic. If I = understand your
proposal
you just want 1 classified stream. Diffserv allows = for more.

> > When other filter is considered, we could = always add more
> > objects into the TCS table.

You can add indeed more objects in the TCS table, but = once the table is
defined
it is defined and static. Are you proposing here that = you want to add
another column
to the table if you need to have 2 meters?? That is = not possible.
You only can add then more entries, but since they = will have a different
index
all objects (and thus the datapath elements) do not = belong to the same
TCB.

> > I suspect we can further simplify the design = of the meter, action, q and scheduler tables as well
> > using the same technique.  More emails = to come.
> >
> > This is just a concept proposal.  I = will send MIB table definition out if this concept is acceptable and = adoptable.  Your

> > thoughts?

Do I have to say more??

Harrie
--
phone: +39-3474932300
http://www.lisanza.net/


------_=_NextPart_001_01C0C830.3BFAF7E4-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 16:16:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17130 for ; Wed, 18 Apr 2001 16:16:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01795; Wed, 18 Apr 2001 15:53:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01764 for ; Wed, 18 Apr 2001 15:53:35 -0400 (EDT) Received: from sonscenter.SALIRA.COM ([64.168.86.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16748 for ; Wed, 18 Apr 2001 15:53:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C841.3F12B456" Date: Wed, 18 Apr 2001 12:53:32 -0700 Message-ID: <2BC6020788F6D04B82E413E548072A0907A2B7@sonscenter.SALIRA.COM> Thread-Topic: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Thread-Index: AcDH4TfmsQffZa91RrSP7FXKCXgT7wAU9eSA From: "Faye Ly" To: "Harrie Hazewinkel" , "Brian E Carpenter" Cc: "Fred Baker" , Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C0C841.3F12B456 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harrie, Another point you mentioned is the ordering. You are very right that I have not addressed it. The fact is I didn't know that some TCB text is subject to be dropped from the [MODEL]. The proposal I proposed does ensure the ordering to be (as you rightly pointed out): classifier -> meter -> action (count or dropper) -> queue -> scheduler One solution came to my mind is to add an ordering object that specify the ordering via a string of OIDs. Or some other numbering scheme like assigning each table with an ENUM value and show the ENUM value order in the ordering object. =20 In conclusion, ordering can be resolved. If by resolving the ordering we can somehow provide NMS a more scalable MIB, I think it is well worth it. Your thoughts? -faye -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@covalent.net] Sent: Wednesday, April 18, 2001 12:40 AM To: Brian E Carpenter Cc: Faye Ly; Fred Baker; diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Brian E Carpenter wrote: [snip] > 2. Everybody who has an opinion to give us a binary answer within a week: > - yes this TCS table is a good idea and the MIB should be changed > - no it isn't a good idea. Looking just to the proposal as MIB designer/reviewer, NO. This proposal is broken. Why?? see below. > > > > Change diffServDataPathStart to point to an entry in the TCS table. If you make this change a TCS/TCB is required. Which is not the case. You still want the 'diffServDataPathStart' to point to the other 4 datapath elements. You make a requirement for the TCB. > > > > TCS Table is defined as: > > > > INDEX {TCBIndex} > > > > OBJECTS > > > > Classifier Filter pointer - points to a set of filters defined in > > diffServSixTupleClfrTable. Change > > the indexing of diffServSixTupleClfrTable > > to double index {ClassifierId, ClfrId} > > By specifying the classifier ID in this > > object, NMS can easily retrieve all the > > filters defined for this classifier. > > The syntax of this object will be > > the same as the ClassifierId defined > > in the diffServSixTupleClfrTable. > > > > Meter pointer - points to an entry in the meter table as defined. > > > > Action pointer - points to an entry in the Action table as defined. > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > Queue table pointer - points to an entry in the diffServQTable. > > Scheduler table pointer - points to an entry in the diffServSchedulerTable. > > > > Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to > > point to the next entry in the same table. Does this mean that you say a TCB has either 1 of these pointers?? If the Classifier Filter pointer is 'zeroDotZero' you must follow the Meter pointer. If the Meter pointer is zeroDotZero you must follow the Action Pointer. However, you allow all pointers fill with RowPointers to datapath=20 elements. The elements are also ordered in a sequential path traffic can follow. In this proposal there is no such thing. Or should I assume that the order is, classifier, meter, action, algorithmic dropper, Queue table, Scheduler?? Maybe people want to have different orders. This does not work. You only create more confusion for as well MIB implementors as well management application. The DIFFSERV-MIB already has this. You just put the RowPointer to the first datapath element in the diffServDataPathSTart. > > > > This matches what is described in [MODEL]: > > > > "This model describes the configuration and management of a Diffserv > > interface in terms of a TCB that contains, by definition, zero or more > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > elements. These elements are arranged arbitrarily according to the > > policy being expressed, but always in the order here. Traffic may be > > classified; classified traffic may be metered; each stream of traffic > > identified by a combination of classifiers and meters may have some set > > of actions performed on it, followed by drop algorithms; packets of the > > traffic stream may ultimately be stored into a queue and then be > > scheduled out to the next TCB or physical interface. " No this is not the same. Just having a bunch of datapaths with no ordering is not the same. And you just want to have just a bunch of datapaths. It is also a bit unfortenate that TCB is still mentioned here. It is legacy text to be removed. > > > > The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. No, the ordering information is not there. It also assumes there is only 1 of each of the datapath elements in a TCB. > > It also got rid > > of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being > > considered or else the classifier element table is not necessary.=20 You need that to make more classified traffic. If I understand your proposal you just want 1 classified stream. Diffserv allows for more. > > When other filter is considered, we could always add more > > objects into the TCS table.=20 You can add indeed more objects in the TCS table, but once the table is defined it is defined and static. Are you proposing here that you want to add another column to the table if you need to have 2 meters?? That is not possible. You only can add then more entries, but since they will have a different index all objects (and thus the datapath elements) do not belong to the same TCB. > > I suspect we can further simplify the design of the meter, action, q and scheduler tables as well > > using the same technique. More emails to come. > > > > This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your > > thoughts? Do I have to say more?? Harrie --=20 phone: +39-3474932300 http://www.lisanza.net/ ------_=_NextPart_001_01C0C841.3F12B456 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RE: A few comments for = draft-ietf-diffserv-mib-09.txt

Harrie,

Another point you mentioned is the ordering.  You = are very right that I have not addressed it.  The fact is I didn't = know that some TCB text is subject to be dropped from the [MODEL].  = The proposal I proposed does ensure the ordering to be (as you rightly = pointed out):

classifier -> meter -> action (count or dropper) = -> queue -> scheduler

One solution came to my mind is to add an ordering = object that specify the ordering via a string of OIDs.  Or some = other numbering scheme like assigning each table with an ENUM value and = show the ENUM value order in the ordering object. 

In conclusion, ordering can be resolved.  If by = resolving the ordering we can somehow provide NMS a more scalable MIB, I = think it is well worth it.

Your thoughts?

-faye


-----Original Message-----
From: Harrie Hazewinkel [mailto:harrie@covalent.net]
Sent: Wednesday, April 18, 2001 12:40 AM
To: Brian E Carpenter
Cc: Faye Ly; Fred Baker; diffserv@ietf.org
Subject: Re: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt


Brian E Carpenter wrote:
[snip]
> 2. Everybody who has an opinion to give us a = binary answer within a week:
>     - yes this TCS table is = a good idea and the MIB should be changed
>     - no it isn't a good = idea.

Looking just to the proposal as MIB designer/reviewer, = NO.
This proposal is broken. Why?? see below.

> >
> > Change diffServDataPathStart to point to an = entry in the TCS table.

If you make this change a TCS/TCB is required. Which = is not the case.
You still want the 'diffServDataPathStart' to point = to the other 4
datapath elements. You make a requirement for the = TCB.

> >
> > TCS Table is defined as:
> >
> > INDEX {TCBIndex}
> >
> > OBJECTS
> >
> >    Classifier Filter pointer = - points to a set of filters defined in
> = >           &nb= sp;           &nbs= p;          = diffServSixTupleClfrTable.  Change
> = >           &nb= sp;           &nbs= p;        the indexing of = diffServSixTupleClfrTable
> = >           &nb= sp;           &nbs= p;        to double index = {ClassifierId, ClfrId}
> = >           &nb= sp;           &nbs= p;        By specifying the = classifier ID in this
> = >           &nb= sp;           &nbs= p;        object, NMS can easily = retrieve all the
> = >           &nb= sp;           &nbs= p;        filters defined for this = classifier.
> = >           &nb= sp;           &nbs= p;        The syntax of this object = will be
> = >           &nb= sp;           &nbs= p;        the same as the = ClassifierId defined
> = >           &nb= sp;           &nbs= p;        in the = diffServSixTupleClfrTable.
> >
> >    Meter pointer - points to = an entry in the meter table as defined.
> >
> >    Action pointer - points = to an entry in the Action table as defined.
> >
> >    Algorithm Drop pointer - = points to an entry in the Algorithm Drop Table.
> >    Queue table pointer - = points to an entry in the diffServQTable.
> >    Scheduler table pointer - = points to an entry in the diffServSchedulerTable.
> >
> > Note that these pointers can be zeros = meaning the operation should be skipped.  Also the NEXT pointer = should only be used to

> > point to the next entry in the same = table.

Does this mean that you say a TCB has either 1 of = these pointers??
If the Classifier Filter pointer is 'zeroDotZero' you = must
follow the Meter pointer. If the Meter pointer is = zeroDotZero
you must follow the Action Pointer.

However, you allow all pointers fill with RowPointers = to datapath
elements. The elements are also ordered in a = sequential path
traffic can follow. In this proposal there is no such = thing.
Or should I assume that the order is, classifier, = meter, action,
algorithmic dropper, Queue table, Scheduler??
Maybe people want to have different orders.

This does not work. You only create more confusion = for
as well MIB implementors as well management = application.
The DIFFSERV-MIB already has this. You just put the = RowPointer
to the first datapath element in the = diffServDataPathSTart.

> >
> > This matches what is described in = [MODEL]:
> >
> > "This model describes the = configuration and management of a Diffserv
> > interface in terms of a TCB that contains, = by definition, zero or more
> > Classifier, Meter, Action, Algorithmic = Dropper, Queue and Scheduler
> > elements.  These elements are arranged = arbitrarily according to the
> > policy being expressed, but always in the = order here. Traffic may be
> > classified; classified traffic may be = metered; each stream of traffic
> > identified by a combination of classifiers = and meters may have some set
> > of actions performed on it, followed by = drop algorithms; packets of the
> > traffic stream may ultimately be stored = into a queue and then be
> > scheduled out to the next TCB or physical = interface.  "

No this is not the same. Just having a bunch of = datapaths with no
ordering
is not the same. And you just want to have just a = bunch of datapaths.
It is also a bit unfortenate that TCB is still = mentioned here.
It is legacy text to be removed.

> >
> > The advantage of using the TCS table is to = retrieve all the relevant TCB information from one single entry.

No, the ordering information is not there. It also = assumes there is only
1
of each of the datapath elements in a TCB.

> >  It also got rid
> > of the Classifier and Classifier element = table by using the double indexing scheme.  Unless other classifer = is being

> > considered or else the classifier element = table is not necessary.

You need that to make more classified traffic. If I = understand your
proposal
you just want 1 classified stream. Diffserv allows = for more.

> > When other filter is considered, we could = always add more
> > objects into the TCS table.

You can add indeed more objects in the TCS table, but = once the table is
defined
it is defined and static. Are you proposing here that = you want to add
another column
to the table if you need to have 2 meters?? That is = not possible.
You only can add then more entries, but since they = will have a different
index
all objects (and thus the datapath elements) do not = belong to the same
TCB.

> > I suspect we can further simplify the design = of the meter, action, q and scheduler tables as well
> > using the same technique.  More emails = to come.
> >
> > This is just a concept proposal.  I = will send MIB table definition out if this concept is acceptable and = adoptable.  Your

> > thoughts?

Do I have to say more??

Harrie
--
phone: +39-3474932300
http://www.lisanza.net/


------_=_NextPart_001_01C0C841.3F12B456-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 16:35:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17506 for ; Wed, 18 Apr 2001 16:35:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02376; Wed, 18 Apr 2001 16:21:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02279 for ; Wed, 18 Apr 2001 16:21:09 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17225 for ; Wed, 18 Apr 2001 16:21:11 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA19124; Wed, 18 Apr 2001 21:20:38 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA59680; Wed, 18 Apr 2001 21:20:37 +0100 Message-ID: <3ADDF6DE.B0F85E31@hursley.ibm.com> Date: Wed, 18 Apr 2001 15:19:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Faye Ly CC: diffserv Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt References: <2BC6020788F6D04B82E413E548072A0907A2B6@sonscenter.SALIRA.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Faye, Can you clarify the point about thousands of subscribers for me? Diffserv deals with a small number of traffic aggregates - by construction, at most 64 including best effort. So diffserv technology, including the management plane, only has to scale to 64 queues per interface, and that is a very theoretical number, with just a few queues more likely. If you are talking about scaling to thousands at the NMS, then my remark about SNMP GETs is not frivolous because we aren't talking about saving a small factor; I can't see any solution at that scale that isn't bulked up much more than a generic per-interface per-queue MIB is ever going to support. That doesn't mean I'm against optimising the MIB somewhat of course, but it won't fundamentally affect scaling as far as I can see. I suspect you are asking for what is fundamentally a diagnostic MIB to behave like a bulk monitoring MIB, and maybe that is simply a different beast. Brian > Faye Ly wrote: > > Brian, > > Actually that is exactly why people started developing their own proprietary MIB. The MIB simply does not scale to hundreds > or thousdands (if you take snmpconf-diffpolicy draft into account) subscribers in the network. Some optimization is needed to > make this MIB 'friendly' to the NMS tools. Note that some NMS tools typically will come and refresh it's database > periodically (daily or weekly). This MIB requires a subtantial amount of time to do so. Note that NMS has a problem that not > all configuration are done via the same tool and hence NMS is forced to refresh it's database from time to time. > > Can we at least be willing to deal with the 'optimization' issue with this MIB? > > -faye > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, April 18, 2001 6:28 AM > To: ah_smith@pacbell.net > Cc: Kwok-Ho Chan; diffserv; Faye Ly > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Andrew, > > It has always been understood that either SNMPCONF or the PIB > would be necessary for diffserv configuration - indeed that is a major > reason why SNMPCONF was started at all. There is no news there. > Yes, it's pragmatic, but I don't see the confusion. > > Since the WG agreed that the MIB should not represent TCBs, you and > Faye need to respond to Harrie's arguments. > > Multiple SNMP GETs are suboptimal for monitoring? Is that news? > > Brian > > Andrew Smith wrote: > > > > Faye's concern gets to the heart of whether it is best to try to have a > > single data structure to access information for configuration operations > > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT"). > > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > > Diffserv Schemas, I think the current state of the IETF efforts on this > > topic can best be described as "pragmatic" (or, less charitably, as > > "confused"). > > > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides > > some good examples of how) and is, on its own without help from the snmpconf > > Diffserv Policy MIB, highly suboptimal for configuration. My advice would be > > to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise > > before designing any Diffserv configuration application (and you'll probably > > be needing to write some proprietary MIBs for efficient monitoring of > > Diffserv on anything other than a small scale). > > > > Andrew > > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > > documents) > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > > Kwok-Ho Chan > > Sent: Tuesday, April 17, 2001 3:42 PM > > To: Faye Ly > > Cc: Fred Baker; diffserv > > Subject: Re: [Diffserv] RE: A few comments for > > draft-ietf-diffserv-mib-09.txt > > > > Faye: > > We have been down this road before (may be not exactly but similar). > > Your proposal resembles what used to be in the "Target Table" of > > the original DiffServ PIB. The original Target Table entries tie together > > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > > There was consensus amongst the co-authors to make the PIB to look > > like the MIB instead of the other way arround, hence the RowPointer > > linkage today in both MIB and PIB. > > There was also the concerns with SNMPCONF WG's usage of the > > DiffServ MIB. > > Just some history. > > -- Kwok -- > > > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > > > Fred, > > > > Certainly. More emails will follow this one as the proposed changes may > > require more description. > > > > Proposed change: > > > > Change diffServDataPathStart to point to an entry in the TCS table. > > > > TCS Table is defined as: > > > > INDEX {TCBIndex} > > > > OBJECTS > > > > Classifier Filter pointer - points to a set of filters defined in > > diffServSixTupleClfrTable. Change > > the indexing of diffServSixTupleClfrTable > > to double index {ClassifierId, ClfrId} > > By specifying the classifier ID in this > > object, NMS can easily retrieve all the > > filters defined for this classifier. > > The syntax of this object will be > > the same as the ClassifierId defined > > in the diffServSixTupleClfrTable. > > > > Meter pointer - points to an entry in the meter table as defined. > > > > Action pointer - points to an entry in the Action table as defined. > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > Queue table pointer - points to an entry in the diffServQTable. > > Scheduler table pointer - points to an entry in the > > diffServSchedulerTable. > > > > Note that these pointers can be zeros meaning the operation should be > > skipped. Also the NEXT pointer should only be used to point to the next > > entry in the same table. > > > > This matches what is described in [MODEL]: > > > > "This model describes the configuration and management of a Diffserv > > interface in terms of a TCB that contains, by definition, zero or more > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > elements. These elements are arranged arbitrarily according to the > > policy being expressed, but always in the order here. Traffic may be > > classified; classified traffic may be metered; each stream of traffic > > identified by a combination of classifiers and meters may have some set > > of actions performed on it, followed by drop algorithms; packets of the > > traffic stream may ultimately be stored into a queue and then be > > scheduled out to the next TCB or physical interface. " > > > > The advantage of using the TCS table is to retrieve all the relevant TCB > > information from one single entry. It also got rid of the Classifier and > > Classifier element table by using the double indexing scheme. Unless other > > classifer is being considered or else the classifier element table is not > > necessary. When other filter is considered, we could always add more > > objects into the TCS table. I suspect we can further simplify the design of > > the meter, action, q and scheduler tables as well using the same technique. > > More emails to come. > > > > This is just a concept proposal. I will send MIB table definition out if > > this concept is acceptable and adoptable. Your thoughts? > > > > -faye > > > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com] > > Sent: Friday, April 13, 2001 10:58 PM > > To: Faye Ly > > Cc: diffserv@ietf.org > > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > > > >Hi, > > > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > > >list yet. (With the IPO mailing list experience, I am not sure I want to > > >:)-) Please feel free to forward this to the mailing list if appropriete. > > > > > >-faye > > > > > >=========================================================================== > > ============== > > > > > >Hi, > > > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > > > >1. The major problem I see with this MIB is the usage by NMS. The tables > > >defined are not very 'friendly' for NMS retrieval. For example, in order > > >to find out the filter being applied to a subscriber Joe. > > > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > > derive the datapath entry. For our discussion, I don't count the SNMP > > > packets required to get here. > > > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > > > the DataPathStart object. > > > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > > > another SNMP getnext to retrieve the Classifier element until all > > > elements associated with this classifier are retrieved. > > > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > > tuple classification entry for Joe. > > > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a > > >particular subscriber. This is not scalable for NMS that typically has to > > >deal with minimum thousands of subscribers. A suggestion is to eliminate > > >the Classifier table and have the Datapath table simply provide an INTEGER > > >pointer point to the Classifier ID in the Classifier Element Table OR > > >meterId in the Meter table OR ... Note that the reverse pointer from > > >the, say Meter table, back to the Classifier table requires the Classifier > > >ID only. > > > > That is pretty much where we started out. We changed to RowPointer in > > response to requests from the working group to allow folks to easily add > > new filter types, such as picking out messages by MAC Address etc. If you > > have a specific proposal that would allow for the flexibility we were asked > > to provide and addresses your concern (and I agree that this is a lot of > > round trips), I'd like to hear it. > > > > >2. For a full classifier, meter, actions, dropper, queue and scheduler can > > >be linked all together via the rowPointer. This is although very smart > > >but again if the NMS is trying to get all the SLA provisioned on a single > > >system. It has to traverse through 6 tables or more in order to get a > > >single flow's SLA. Again not very scalable. An alternative is to place > > >all these table pointers into a single data path table or profile > > >table. The profile table will have separate object specifying the > > >relationship between all these tables for a single SLA. The table pointer > > >will be NULL if a certain SLA doesn't require, for example, any queue to > > >be specified. The datapath table in turns will be assigned with a single > > >profile. > > > > Could you be more specific? Can you advise how hierarchical systems such as > > CBQ would be described using your approach? > > > > _______________________________________________ diffserv mailing list > > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 17:49:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18551 for ; Wed, 18 Apr 2001 17:49:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03987; Wed, 18 Apr 2001 17:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03957 for ; Wed, 18 Apr 2001 17:30:39 -0400 (EDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18285 for ; Wed, 18 Apr 2001 17:30:41 -0400 (EDT) Received: from ANDREWHOME (user-2ivfiq0.dialup.mindspring.com [165.247.203.64]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id OAA02928; Wed, 18 Apr 2001 14:30:22 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Faye Ly" Cc: Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Date: Wed, 18 Apr 2001 14:43:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <2BC6020788F6D04B82E413E548072A0907A2B7@sonscenter.SALIRA.COM> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Just for clarification: as far as I know, there is nothing due for removal from the current [MODEL] draft. I think Harrie was referring to the fact that it was decided to remove almost all references to the TCB concept from the *MIB* draft. Andrew (editor of MODEL draft) -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Faye Ly Sent: Wednesday, April 18, 2001 12:54 PM To: Harrie Hazewinkel; Brian E Carpenter Cc: Fred Baker; diffserv@ietf.org Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Harrie, Another point you mentioned is the ordering. You are very right that I have not addressed it. The fact is I didn't know that some TCB text is subject to be dropped from the [MODEL]. The proposal I proposed does ensure the ordering to be (as you rightly pointed out): classifier -> meter -> action (count or dropper) -> queue -> scheduler One solution came to my mind is to add an ordering object that specify the ordering via a string of OIDs. Or some other numbering scheme like assigning each table with an ENUM value and show the ENUM value order in the ordering object. In conclusion, ordering can be resolved. If by resolving the ordering we can somehow provide NMS a more scalable MIB, I think it is well worth it. Your thoughts? -faye -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@covalent.net] Sent: Wednesday, April 18, 2001 12:40 AM To: Brian E Carpenter Cc: Faye Ly; Fred Baker; diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Brian E Carpenter wrote: [snip] > 2. Everybody who has an opinion to give us a binary answer within a week: > - yes this TCS table is a good idea and the MIB should be changed > - no it isn't a good idea. Looking just to the proposal as MIB designer/reviewer, NO. This proposal is broken. Why?? see below. > > > > Change diffServDataPathStart to point to an entry in the TCS table. If you make this change a TCS/TCB is required. Which is not the case. You still want the 'diffServDataPathStart' to point to the other 4 datapath elements. You make a requirement for the TCB. > > > > TCS Table is defined as: > > > > INDEX {TCBIndex} > > > > OBJECTS > > > > Classifier Filter pointer - points to a set of filters defined in > > diffServSixTupleClfrTable. Change > > the indexing of diffServSixTupleClfrTable > > to double index {ClassifierId, ClfrId} > > By specifying the classifier ID in this > > object, NMS can easily retrieve all the > > filters defined for this classifier. > > The syntax of this object will be > > the same as the ClassifierId defined > > in the diffServSixTupleClfrTable. > > > > Meter pointer - points to an entry in the meter table as defined. > > > > Action pointer - points to an entry in the Action table as defined. > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > Queue table pointer - points to an entry in the diffServQTable. > > Scheduler table pointer - points to an entry in the diffServSchedulerTable. > > > > Note that these pointers can be zeros meaning the operation should be skipped. Also the NEXT pointer should only be used to > > point to the next entry in the same table. Does this mean that you say a TCB has either 1 of these pointers?? If the Classifier Filter pointer is 'zeroDotZero' you must follow the Meter pointer. If the Meter pointer is zeroDotZero you must follow the Action Pointer. However, you allow all pointers fill with RowPointers to datapath elements. The elements are also ordered in a sequential path traffic can follow. In this proposal there is no such thing. Or should I assume that the order is, classifier, meter, action, algorithmic dropper, Queue table, Scheduler?? Maybe people want to have different orders. This does not work. You only create more confusion for as well MIB implementors as well management application. The DIFFSERV-MIB already has this. You just put the RowPointer to the first datapath element in the diffServDataPathSTart. > > > > This matches what is described in [MODEL]: > > > > "This model describes the configuration and management of a Diffserv > > interface in terms of a TCB that contains, by definition, zero or more > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > elements. These elements are arranged arbitrarily according to the > > policy being expressed, but always in the order here. Traffic may be > > classified; classified traffic may be metered; each stream of traffic > > identified by a combination of classifiers and meters may have some set > > of actions performed on it, followed by drop algorithms; packets of the > > traffic stream may ultimately be stored into a queue and then be > > scheduled out to the next TCB or physical interface. " No this is not the same. Just having a bunch of datapaths with no ordering is not the same. And you just want to have just a bunch of datapaths. It is also a bit unfortenate that TCB is still mentioned here. It is legacy text to be removed. > > > > The advantage of using the TCS table is to retrieve all the relevant TCB information from one single entry. No, the ordering information is not there. It also assumes there is only 1 of each of the datapath elements in a TCB. > > It also got rid > > of the Classifier and Classifier element table by using the double indexing scheme. Unless other classifer is being > > considered or else the classifier element table is not necessary. You need that to make more classified traffic. If I understand your proposal you just want 1 classified stream. Diffserv allows for more. > > When other filter is considered, we could always add more > > objects into the TCS table. You can add indeed more objects in the TCS table, but once the table is defined it is defined and static. Are you proposing here that you want to add another column to the table if you need to have 2 meters?? That is not possible. You only can add then more entries, but since they will have a different index all objects (and thus the datapath elements) do not belong to the same TCB. > > I suspect we can further simplify the design of the meter, action, q and scheduler tables as well > > using the same technique. More emails to come. > > > > This is just a concept proposal. I will send MIB table definition out if this concept is acceptable and adoptable. Your > > thoughts? Do I have to say more?? Harrie -- phone: +39-3474932300 http://www.lisanza.net/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 18:10:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18840 for ; Wed, 18 Apr 2001 18:10:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04373; Wed, 18 Apr 2001 17:56:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04270 for ; Wed, 18 Apr 2001 17:56:44 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18645 for ; Wed, 18 Apr 2001 17:56:44 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA19088; Wed, 18 Apr 2001 22:56:11 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA54858; Wed, 18 Apr 2001 22:56:10 +0100 Message-ID: <3ADE0D28.45C66148@hursley.ibm.com> Date: Wed, 18 Apr 2001 16:54:48 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: diffserv Subject: Re: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I detect agreement here - if there is a requirement for 1000s of classifiers in one box, a special purpose monitoring solution will be needed anyway. I never envisaged the current MIB being used for more than a handful of classifiers per interface. Brian Andrew Smith wrote: > > Brian, > > 1. Several thousands of interfaces per SNMP agent is not at all uncommon > these days. > 2. Several thousands of classifier elements on one interface at the edge of > a particular Diffserv domain is not unlikely either: it is only the middle > of a Diffserv domain that benefits from the 64 limit (for some appropriate > definitions of "middle" and "edge"). > > Probably no need for both of these thousands at the same time though. > > One solution, of course, would be to implement an appropriately powerful > supercomputer for the management plane (I'm less concerned about the > network-bandwidth requirements than processing cycles for the SNMP protocol > operations). The traditional alternative to this has been some sort of > proprietary "encoded octet string" representation to pack the data and > indexing into PDUs, passing the processing burden largely to the management > station. The latter approach usually sells better. > > Andrew > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Wednesday, April 18, 2001 1:20 PM > To: Faye Ly > Cc: diffserv > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Faye, > > Can you clarify the point about thousands of subscribers for me? Diffserv > deals with > a small number of traffic aggregates - by construction, at most 64 including > best effort. > So diffserv technology, including the management plane, only has to scale to > 64 queues > per interface, and that is a very theoretical number, with just a few queues > more > likely. > > If you are talking about scaling to thousands at the NMS, then my remark > about > SNMP GETs is not frivolous because we aren't talking about saving a small > factor; > I can't see any solution at that scale that isn't bulked up much more than a > generic > per-interface per-queue MIB is ever going to support. > > That doesn't mean I'm against optimising the MIB somewhat of course, but it > won't fundamentally affect scaling as far as I can see. > > I suspect you are asking for what is fundamentally a diagnostic MIB to > behave like a bulk monitoring MIB, and maybe that is simply a different > beast. > > Brian > > > Faye Ly wrote: > > > > Brian, > > > > Actually that is exactly why people started developing their own > proprietary MIB. The MIB simply does not scale to hundreds > > or thousdands (if you take snmpconf-diffpolicy draft into account) > subscribers in the network. Some optimization is needed to > > make this MIB 'friendly' to the NMS tools. Note that some NMS tools > typically will come and refresh it's database > > periodically (daily or weekly). This MIB requires a subtantial amount of > time to do so. Note that NMS has a problem that not > > all configuration are done via the same tool and hence NMS is forced to > refresh it's database from time to time. > > > > Can we at least be willing to deal with the 'optimization' issue with this > MIB? > > > > -faye > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, April 18, 2001 6:28 AM > > To: ah_smith@pacbell.net > > Cc: Kwok-Ho Chan; diffserv; Faye Ly > > Subject: Re: [Diffserv] RE: A few comments for > > draft-ietf-diffserv-mib-09.txt > > > > Andrew, > > > > It has always been understood that either SNMPCONF or the PIB > > would be necessary for diffserv configuration - indeed that is a major > > reason why SNMPCONF was started at all. There is no news there. > > Yes, it's pragmatic, but I don't see the confusion. > > > > Since the WG agreed that the MIB should not represent TCBs, you and > > Faye need to respond to Harrie's arguments. > > > > Multiple SNMP GETs are suboptimal for monitoring? Is that news? > > > > Brian > > > > Andrew Smith wrote: > > > > > > Faye's concern gets to the heart of whether it is best to try to have a > > > single data structure to access information for configuration operations > > > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or > "GETNEXT"). > > > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > > > Diffserv Schemas, I think the current state of the IETF efforts on this > > > topic can best be described as "pragmatic" (or, less charitably, as > > > "confused"). > > > > > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye > provides > > > some good examples of how) and is, on its own without help from the > snmpconf > > > Diffserv Policy MIB, highly suboptimal for configuration. My advice > would be > > > to wait for either the snmpconf work or the COPS Diffserv PIB to > stabilise > > > before designing any Diffserv configuration application (and you'll > probably > > > be needing to write some proprietary MIBs for efficient monitoring of > > > Diffserv on anything other than a small scale). > > > > > > Andrew > > > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > > > documents) > > > > > > -----Original Message----- > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of > > > Kwok-Ho Chan > > > Sent: Tuesday, April 17, 2001 3:42 PM > > > To: Faye Ly > > > Cc: Fred Baker; diffserv > > > Subject: Re: [Diffserv] RE: A few comments for > > > draft-ietf-diffserv-mib-09.txt > > > > > > Faye: > > > We have been down this road before (may be not exactly but similar). > > > Your proposal resembles what used to be in the "Target Table" of > > > the original DiffServ PIB. The original Target Table entries tie > together > > > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > > > There was consensus amongst the co-authors to make the PIB to look > > > like the MIB instead of the other way arround, hence the RowPointer > > > linkage today in both MIB and PIB. > > > There was also the concerns with SNMPCONF WG's usage of the > > > DiffServ MIB. > > > Just some history. > > > -- Kwok -- > > > > > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > > > > > Fred, > > > > > > Certainly. More emails will follow this one as the proposed changes may > > > require more description. > > > > > > Proposed change: > > > > > > Change diffServDataPathStart to point to an entry in the TCS table. > > > > > > TCS Table is defined as: > > > > > > INDEX {TCBIndex} > > > > > > OBJECTS > > > > > > Classifier Filter pointer - points to a set of filters defined in > > > diffServSixTupleClfrTable. Change > > > the indexing of diffServSixTupleClfrTable > > > to double index {ClassifierId, ClfrId} > > > By specifying the classifier ID in this > > > object, NMS can easily retrieve all the > > > filters defined for this classifier. > > > The syntax of this object will be > > > the same as the ClassifierId defined > > > in the diffServSixTupleClfrTable. > > > > > > Meter pointer - points to an entry in the meter table as defined. > > > > > > Action pointer - points to an entry in the Action table as defined. > > > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop > Table. > > > Queue table pointer - points to an entry in the diffServQTable. > > > Scheduler table pointer - points to an entry in the > > > diffServSchedulerTable. > > > > > > Note that these pointers can be zeros meaning the operation should be > > > skipped. Also the NEXT pointer should only be used to point to the next > > > entry in the same table. > > > > > > This matches what is described in [MODEL]: > > > > > > "This model describes the configuration and management of a Diffserv > > > interface in terms of a TCB that contains, by definition, zero or more > > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > > elements. These elements are arranged arbitrarily according to the > > > policy being expressed, but always in the order here. Traffic may be > > > classified; classified traffic may be metered; each stream of traffic > > > identified by a combination of classifiers and meters may have some set > > > of actions performed on it, followed by drop algorithms; packets of the > > > traffic stream may ultimately be stored into a queue and then be > > > scheduled out to the next TCB or physical interface. " > > > > > > The advantage of using the TCS table is to retrieve all the relevant TCB > > > information from one single entry. It also got rid of the Classifier > and > > > Classifier element table by using the double indexing scheme. Unless > other > > > classifer is being considered or else the classifier element table is > not > > > necessary. When other filter is considered, we could always add more > > > objects into the TCS table. I suspect we can further simplify the > design of > > > the meter, action, q and scheduler tables as well using the same > technique. > > > More emails to come. > > > > > > This is just a concept proposal. I will send MIB table definition out > if > > > this concept is acceptable and adoptable. Your thoughts? > > > > > > -faye > > > > > > -----Original Message----- > > > From: Fred Baker [mailto:fred@cisco.com] > > > Sent: Friday, April 13, 2001 10:58 PM > > > To: Faye Ly > > > Cc: diffserv@ietf.org > > > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > > > > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > > > > > >Hi, > > > > > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > > > >list yet. (With the IPO mailing list experience, I am not sure I want > to > > > >:)-) Please feel free to forward this to the mailing list if > appropriete. > > > > > > > >-faye > > > > > > > > >=========================================================================== > > > ============== > > > > > > > >Hi, > > > > > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > > > > > >1. The major problem I see with this MIB is the usage by NMS. The > tables > > > >defined are not very 'friendly' for NMS retrieval. For example, in > order > > > >to find out the filter being applied to a subscriber Joe. > > > > > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > > > derive the datapath entry. For our discussion, I don't count the SNMP > > > > packets required to get here. > > > > > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry > using > > > > the DataPathStart object. > > > > > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS > issues > > > > another SNMP getnext to retrieve the Classifier element until all > > > > elements associated with this classifier are retrieved. > > > > > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > > > tuple classification entry for Joe. > > > > > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for > a > > > >particular subscriber. This is not scalable for NMS that typically has > to > > > >deal with minimum thousands of subscribers. A suggestion is to > eliminate > > > >the Classifier table and have the Datapath table simply provide an > INTEGER > > > >pointer point to the Classifier ID in the Classifier Element Table OR > > > >meterId in the Meter table OR ... Note that the reverse pointer from > > > >the, say Meter table, back to the Classifier table requires the > Classifier > > > >ID only. > > > > > > That is pretty much where we started out. We changed to RowPointer in > > > response to requests from the working group to allow folks to easily add > > > new filter types, such as picking out messages by MAC Address etc. If > you > > > have a specific proposal that would allow for the flexibility we were > asked > > > to provide and addresses your concern (and I agree that this is a lot of > > > round trips), I'd like to hear it. > > > > > > >2. For a full classifier, meter, actions, dropper, queue and scheduler > can > > > >be linked all together via the rowPointer. This is although very smart > > > >but again if the NMS is trying to get all the SLA provisioned on a > single > > > >system. It has to traverse through 6 tables or more in order to get a > > > >single flow's SLA. Again not very scalable. An alternative is to > place > > > >all these table pointers into a single data path table or profile > > > >table. The profile table will have separate object specifying the > > > >relationship between all these tables for a single SLA. The table > pointer > > > >will be NULL if a certain SLA doesn't require, for example, any queue > to > > > >be specified. The datapath table in turns will be assigned with a > single > > > >profile. > > > > > > Could you be more specific? Can you advise how hierarchical systems such > as > > > CBQ would be described using your approach? > > > > > > _______________________________________________ diffserv mailing list > > > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > > tml > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 18:10:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18854 for ; Wed, 18 Apr 2001 18:10:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04264; Wed, 18 Apr 2001 17:56:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04237 for ; Wed, 18 Apr 2001 17:56:25 -0400 (EDT) Received: from ostrich.mail.pas.earthlink.net (ostrich.mail.pas.earthlink.net [207.217.120.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18643 for ; Wed, 18 Apr 2001 17:56:22 -0400 (EDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ostrich.mail.pas.earthlink.net (8.9.3/8.9.3) with ESMTP id OAA27594 for ; Wed, 18 Apr 2001 14:48:41 -0700 (PDT) Received: from ANDREWHOME (user-2ivfiq0.dialup.mindspring.com [165.247.203.64]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id OAA05866; Wed, 18 Apr 2001 14:43:24 -0700 (PDT) From: "Andrew Smith" To: "Brian E Carpenter" Cc: "diffserv" Subject: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) Date: Wed, 18 Apr 2001 14:56:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <3ADDF6DE.B0F85E31@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, 1. Several thousands of interfaces per SNMP agent is not at all uncommon these days. 2. Several thousands of classifier elements on one interface at the edge of a particular Diffserv domain is not unlikely either: it is only the middle of a Diffserv domain that benefits from the 64 limit (for some appropriate definitions of "middle" and "edge"). Probably no need for both of these thousands at the same time though. One solution, of course, would be to implement an appropriately powerful supercomputer for the management plane (I'm less concerned about the network-bandwidth requirements than processing cycles for the SNMP protocol operations). The traditional alternative to this has been some sort of proprietary "encoded octet string" representation to pack the data and indexing into PDUs, passing the processing burden largely to the management station. The latter approach usually sells better. Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, April 18, 2001 1:20 PM To: Faye Ly Cc: diffserv Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Faye, Can you clarify the point about thousands of subscribers for me? Diffserv deals with a small number of traffic aggregates - by construction, at most 64 including best effort. So diffserv technology, including the management plane, only has to scale to 64 queues per interface, and that is a very theoretical number, with just a few queues more likely. If you are talking about scaling to thousands at the NMS, then my remark about SNMP GETs is not frivolous because we aren't talking about saving a small factor; I can't see any solution at that scale that isn't bulked up much more than a generic per-interface per-queue MIB is ever going to support. That doesn't mean I'm against optimising the MIB somewhat of course, but it won't fundamentally affect scaling as far as I can see. I suspect you are asking for what is fundamentally a diagnostic MIB to behave like a bulk monitoring MIB, and maybe that is simply a different beast. Brian > Faye Ly wrote: > > Brian, > > Actually that is exactly why people started developing their own proprietary MIB. The MIB simply does not scale to hundreds > or thousdands (if you take snmpconf-diffpolicy draft into account) subscribers in the network. Some optimization is needed to > make this MIB 'friendly' to the NMS tools. Note that some NMS tools typically will come and refresh it's database > periodically (daily or weekly). This MIB requires a subtantial amount of time to do so. Note that NMS has a problem that not > all configuration are done via the same tool and hence NMS is forced to refresh it's database from time to time. > > Can we at least be willing to deal with the 'optimization' issue with this MIB? > > -faye > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, April 18, 2001 6:28 AM > To: ah_smith@pacbell.net > Cc: Kwok-Ho Chan; diffserv; Faye Ly > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Andrew, > > It has always been understood that either SNMPCONF or the PIB > would be necessary for diffserv configuration - indeed that is a major > reason why SNMPCONF was started at all. There is no news there. > Yes, it's pragmatic, but I don't see the confusion. > > Since the WG agreed that the MIB should not represent TCBs, you and > Faye need to respond to Harrie's arguments. > > Multiple SNMP GETs are suboptimal for monitoring? Is that news? > > Brian > > Andrew Smith wrote: > > > > Faye's concern gets to the heart of whether it is best to try to have a > > single data structure to access information for configuration operations > > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT"). > > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > > Diffserv Schemas, I think the current state of the IETF efforts on this > > topic can best be described as "pragmatic" (or, less charitably, as > > "confused"). > > > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides > > some good examples of how) and is, on its own without help from the snmpconf > > Diffserv Policy MIB, highly suboptimal for configuration. My advice would be > > to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise > > before designing any Diffserv configuration application (and you'll probably > > be needing to write some proprietary MIBs for efficient monitoring of > > Diffserv on anything other than a small scale). > > > > Andrew > > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > > documents) > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > > Kwok-Ho Chan > > Sent: Tuesday, April 17, 2001 3:42 PM > > To: Faye Ly > > Cc: Fred Baker; diffserv > > Subject: Re: [Diffserv] RE: A few comments for > > draft-ietf-diffserv-mib-09.txt > > > > Faye: > > We have been down this road before (may be not exactly but similar). > > Your proposal resembles what used to be in the "Target Table" of > > the original DiffServ PIB. The original Target Table entries tie together > > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > > There was consensus amongst the co-authors to make the PIB to look > > like the MIB instead of the other way arround, hence the RowPointer > > linkage today in both MIB and PIB. > > There was also the concerns with SNMPCONF WG's usage of the > > DiffServ MIB. > > Just some history. > > -- Kwok -- > > > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > > > Fred, > > > > Certainly. More emails will follow this one as the proposed changes may > > require more description. > > > > Proposed change: > > > > Change diffServDataPathStart to point to an entry in the TCS table. > > > > TCS Table is defined as: > > > > INDEX {TCBIndex} > > > > OBJECTS > > > > Classifier Filter pointer - points to a set of filters defined in > > diffServSixTupleClfrTable. Change > > the indexing of diffServSixTupleClfrTable > > to double index {ClassifierId, ClfrId} > > By specifying the classifier ID in this > > object, NMS can easily retrieve all the > > filters defined for this classifier. > > The syntax of this object will be > > the same as the ClassifierId defined > > in the diffServSixTupleClfrTable. > > > > Meter pointer - points to an entry in the meter table as defined. > > > > Action pointer - points to an entry in the Action table as defined. > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > Queue table pointer - points to an entry in the diffServQTable. > > Scheduler table pointer - points to an entry in the > > diffServSchedulerTable. > > > > Note that these pointers can be zeros meaning the operation should be > > skipped. Also the NEXT pointer should only be used to point to the next > > entry in the same table. > > > > This matches what is described in [MODEL]: > > > > "This model describes the configuration and management of a Diffserv > > interface in terms of a TCB that contains, by definition, zero or more > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > elements. These elements are arranged arbitrarily according to the > > policy being expressed, but always in the order here. Traffic may be > > classified; classified traffic may be metered; each stream of traffic > > identified by a combination of classifiers and meters may have some set > > of actions performed on it, followed by drop algorithms; packets of the > > traffic stream may ultimately be stored into a queue and then be > > scheduled out to the next TCB or physical interface. " > > > > The advantage of using the TCS table is to retrieve all the relevant TCB > > information from one single entry. It also got rid of the Classifier and > > Classifier element table by using the double indexing scheme. Unless other > > classifer is being considered or else the classifier element table is not > > necessary. When other filter is considered, we could always add more > > objects into the TCS table. I suspect we can further simplify the design of > > the meter, action, q and scheduler tables as well using the same technique. > > More emails to come. > > > > This is just a concept proposal. I will send MIB table definition out if > > this concept is acceptable and adoptable. Your thoughts? > > > > -faye > > > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com] > > Sent: Friday, April 13, 2001 10:58 PM > > To: Faye Ly > > Cc: diffserv@ietf.org > > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > > > >Hi, > > > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > > >list yet. (With the IPO mailing list experience, I am not sure I want to > > >:)-) Please feel free to forward this to the mailing list if appropriete. > > > > > >-faye > > > > > >=========================================================================== > > ============== > > > > > >Hi, > > > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > > > >1. The major problem I see with this MIB is the usage by NMS. The tables > > >defined are not very 'friendly' for NMS retrieval. For example, in order > > >to find out the filter being applied to a subscriber Joe. > > > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > > derive the datapath entry. For our discussion, I don't count the SNMP > > > packets required to get here. > > > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > > > the DataPathStart object. > > > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > > > another SNMP getnext to retrieve the Classifier element until all > > > elements associated with this classifier are retrieved. > > > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > > tuple classification entry for Joe. > > > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a > > >particular subscriber. This is not scalable for NMS that typically has to > > >deal with minimum thousands of subscribers. A suggestion is to eliminate > > >the Classifier table and have the Datapath table simply provide an INTEGER > > >pointer point to the Classifier ID in the Classifier Element Table OR > > >meterId in the Meter table OR ... Note that the reverse pointer from > > >the, say Meter table, back to the Classifier table requires the Classifier > > >ID only. > > > > That is pretty much where we started out. We changed to RowPointer in > > response to requests from the working group to allow folks to easily add > > new filter types, such as picking out messages by MAC Address etc. If you > > have a specific proposal that would allow for the flexibility we were asked > > to provide and addresses your concern (and I agree that this is a lot of > > round trips), I'd like to hear it. > > > > >2. For a full classifier, meter, actions, dropper, queue and scheduler can > > >be linked all together via the rowPointer. This is although very smart > > >but again if the NMS is trying to get all the SLA provisioned on a single > > >system. It has to traverse through 6 tables or more in order to get a > > >single flow's SLA. Again not very scalable. An alternative is to place > > >all these table pointers into a single data path table or profile > > >table. The profile table will have separate object specifying the > > >relationship between all these tables for a single SLA. The table pointer > > >will be NULL if a certain SLA doesn't require, for example, any queue to > > >be specified. The datapath table in turns will be assigned with a single > > >profile. > > > > Could you be more specific? Can you advise how hierarchical systems such as > > CBQ would be described using your approach? > > > > _______________________________________________ diffserv mailing list > > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Apr 18 20:12:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19844 for ; Wed, 18 Apr 2001 20:12:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06438; Wed, 18 Apr 2001 19:54:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06410 for ; Wed, 18 Apr 2001 19:54:19 -0400 (EDT) Received: from ostrich.mail.pas.earthlink.net (ostrich.mail.pas.earthlink.net [207.217.120.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19745 for ; Wed, 18 Apr 2001 19:54:16 -0400 (EDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by ostrich.mail.pas.earthlink.net (8.9.3/8.9.3) with ESMTP id PAA08001 for ; Wed, 18 Apr 2001 15:29:05 -0700 (PDT) Received: from ANDREWHOME (user-2ivfiq0.dialup.mindspring.com [165.247.203.64]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id PAA00808; Wed, 18 Apr 2001 15:28:18 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Brian E Carpenter" Cc: "diffserv" Subject: RE: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) Date: Wed, 18 Apr 2001 15:41:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <3ADE0D28.45C66148@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit re Numbers of classifiers: then there should be an added disclaimer (Applicability Statement) that says this MIB is meant only for Diffserv Core nodes, not Edge nodes and we should probably go back to the original BA-classifier-only version (-01 I believe). That would be a shame but it might be more honest. re Numbers of interfaces: I don't think I yet understand your position on this (1000s of interfaces per box implies 1000s of classifiers per box - that's physics). But some of these scaling issues are resolvable, for configuration operations, by the use of "template" mechanisms, as in the SNMPCONF work (that makes the writable part of this Diffserv MIB somewhat moot, in my opinion). We haven't yet seen much work on this topic for monitoring operations (RMON-like mechanisms don't help - they help scale the time axis, not the "number of instances" axis) so we should do all we can to optimise the utility of this MIB for monitoring at the present time using existing protocols (specifically SNMP/GETBULK). Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, April 18, 2001 2:55 PM To: Andrew Smith Cc: diffserv Subject: Re: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) I detect agreement here - if there is a requirement for 1000s of classifiers in one box, a special purpose monitoring solution will be needed anyway. I never envisaged the current MIB being used for more than a handful of classifiers per interface. Brian Andrew Smith wrote: > > Brian, > > 1. Several thousands of interfaces per SNMP agent is not at all uncommon > these days. > 2. Several thousands of classifier elements on one interface at the edge of > a particular Diffserv domain is not unlikely either: it is only the middle > of a Diffserv domain that benefits from the 64 limit (for some appropriate > definitions of "middle" and "edge"). > > Probably no need for both of these thousands at the same time though. > > One solution, of course, would be to implement an appropriately powerful > supercomputer for the management plane (I'm less concerned about the > network-bandwidth requirements than processing cycles for the SNMP protocol > operations). The traditional alternative to this has been some sort of > proprietary "encoded octet string" representation to pack the data and > indexing into PDUs, passing the processing burden largely to the management > station. The latter approach usually sells better. > > Andrew > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Wednesday, April 18, 2001 1:20 PM > To: Faye Ly > Cc: diffserv > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Faye, > > Can you clarify the point about thousands of subscribers for me? Diffserv > deals with > a small number of traffic aggregates - by construction, at most 64 including > best effort. > So diffserv technology, including the management plane, only has to scale to > 64 queues > per interface, and that is a very theoretical number, with just a few queues > more > likely. > > If you are talking about scaling to thousands at the NMS, then my remark > about > SNMP GETs is not frivolous because we aren't talking about saving a small > factor; > I can't see any solution at that scale that isn't bulked up much more than a > generic > per-interface per-queue MIB is ever going to support. > > That doesn't mean I'm against optimising the MIB somewhat of course, but it > won't fundamentally affect scaling as far as I can see. > > I suspect you are asking for what is fundamentally a diagnostic MIB to > behave like a bulk monitoring MIB, and maybe that is simply a different > beast. > > Brian > > > Faye Ly wrote: > > > > Brian, > > > > Actually that is exactly why people started developing their own > proprietary MIB. The MIB simply does not scale to hundreds > > or thousdands (if you take snmpconf-diffpolicy draft into account) > subscribers in the network. Some optimization is needed to > > make this MIB 'friendly' to the NMS tools. Note that some NMS tools > typically will come and refresh it's database > > periodically (daily or weekly). This MIB requires a subtantial amount of > time to do so. Note that NMS has a problem that not > > all configuration are done via the same tool and hence NMS is forced to > refresh it's database from time to time. > > > > Can we at least be willing to deal with the 'optimization' issue with this > MIB? > > > > -faye > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, April 18, 2001 6:28 AM > > To: ah_smith@pacbell.net > > Cc: Kwok-Ho Chan; diffserv; Faye Ly > > Subject: Re: [Diffserv] RE: A few comments for > > draft-ietf-diffserv-mib-09.txt > > > > Andrew, > > > > It has always been understood that either SNMPCONF or the PIB > > would be necessary for diffserv configuration - indeed that is a major > > reason why SNMPCONF was started at all. There is no news there. > > Yes, it's pragmatic, but I don't see the confusion. > > > > Since the WG agreed that the MIB should not represent TCBs, you and > > Faye need to respond to Harrie's arguments. > > > > Multiple SNMP GETs are suboptimal for monitoring? Is that news? > > > > Brian > > > > Andrew Smith wrote: > > > > > > Faye's concern gets to the heart of whether it is best to try to have a > > > single data structure to access information for configuration operations > > > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or > "GETNEXT"). > > > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > > > Diffserv Schemas, I think the current state of the IETF efforts on this > > > topic can best be described as "pragmatic" (or, less charitably, as > > > "confused"). > > > > > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye > provides > > > some good examples of how) and is, on its own without help from the > snmpconf > > > Diffserv Policy MIB, highly suboptimal for configuration. My advice > would be > > > to wait for either the snmpconf work or the COPS Diffserv PIB to > stabilise > > > before designing any Diffserv configuration application (and you'll > probably > > > be needing to write some proprietary MIBs for efficient monitoring of > > > Diffserv on anything other than a small scale). > > > > > > Andrew > > > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > > > documents) > > > > > > -----Original Message----- > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of > > > Kwok-Ho Chan > > > Sent: Tuesday, April 17, 2001 3:42 PM > > > To: Faye Ly > > > Cc: Fred Baker; diffserv > > > Subject: Re: [Diffserv] RE: A few comments for > > > draft-ietf-diffserv-mib-09.txt > > > > > > Faye: > > > We have been down this road before (may be not exactly but similar). > > > Your proposal resembles what used to be in the "Target Table" of > > > the original DiffServ PIB. The original Target Table entries tie > together > > > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > > > There was consensus amongst the co-authors to make the PIB to look > > > like the MIB instead of the other way arround, hence the RowPointer > > > linkage today in both MIB and PIB. > > > There was also the concerns with SNMPCONF WG's usage of the > > > DiffServ MIB. > > > Just some history. > > > -- Kwok -- > > > > > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > > > > > Fred, > > > > > > Certainly. More emails will follow this one as the proposed changes may > > > require more description. > > > > > > Proposed change: > > > > > > Change diffServDataPathStart to point to an entry in the TCS table. > > > > > > TCS Table is defined as: > > > > > > INDEX {TCBIndex} > > > > > > OBJECTS > > > > > > Classifier Filter pointer - points to a set of filters defined in > > > diffServSixTupleClfrTable. Change > > > the indexing of diffServSixTupleClfrTable > > > to double index {ClassifierId, ClfrId} > > > By specifying the classifier ID in this > > > object, NMS can easily retrieve all the > > > filters defined for this classifier. > > > The syntax of this object will be > > > the same as the ClassifierId defined > > > in the diffServSixTupleClfrTable. > > > > > > Meter pointer - points to an entry in the meter table as defined. > > > > > > Action pointer - points to an entry in the Action table as defined. > > > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop > Table. > > > Queue table pointer - points to an entry in the diffServQTable. > > > Scheduler table pointer - points to an entry in the > > > diffServSchedulerTable. > > > > > > Note that these pointers can be zeros meaning the operation should be > > > skipped. Also the NEXT pointer should only be used to point to the next > > > entry in the same table. > > > > > > This matches what is described in [MODEL]: > > > > > > "This model describes the configuration and management of a Diffserv > > > interface in terms of a TCB that contains, by definition, zero or more > > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > > elements. These elements are arranged arbitrarily according to the > > > policy being expressed, but always in the order here. Traffic may be > > > classified; classified traffic may be metered; each stream of traffic > > > identified by a combination of classifiers and meters may have some set > > > of actions performed on it, followed by drop algorithms; packets of the > > > traffic stream may ultimately be stored into a queue and then be > > > scheduled out to the next TCB or physical interface. " > > > > > > The advantage of using the TCS table is to retrieve all the relevant TCB > > > information from one single entry. It also got rid of the Classifier > and > > > Classifier element table by using the double indexing scheme. Unless > other > > > classifer is being considered or else the classifier element table is > not > > > necessary. When other filter is considered, we could always add more > > > objects into the TCS table. I suspect we can further simplify the > design of > > > the meter, action, q and scheduler tables as well using the same > technique. > > > More emails to come. > > > > > > This is just a concept proposal. I will send MIB table definition out > if > > > this concept is acceptable and adoptable. Your thoughts? > > > > > > -faye > > > > > > -----Original Message----- > > > From: Fred Baker [mailto:fred@cisco.com] > > > Sent: Friday, April 13, 2001 10:58 PM > > > To: Faye Ly > > > Cc: diffserv@ietf.org > > > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > > > > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > > > > > >Hi, > > > > > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > > > >list yet. (With the IPO mailing list experience, I am not sure I want > to > > > >:)-) Please feel free to forward this to the mailing list if > appropriete. > > > > > > > >-faye > > > > > > > > >=========================================================================== > > > ============== > > > > > > > >Hi, > > > > > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > > > > > >1. The major problem I see with this MIB is the usage by NMS. The > tables > > > >defined are not very 'friendly' for NMS retrieval. For example, in > order > > > >to find out the filter being applied to a subscriber Joe. > > > > > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > > > derive the datapath entry. For our discussion, I don't count the SNMP > > > > packets required to get here. > > > > > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry > using > > > > the DataPathStart object. > > > > > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS > issues > > > > another SNMP getnext to retrieve the Classifier element until all > > > > elements associated with this classifier are retrieved. > > > > > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > > > tuple classification entry for Joe. > > > > > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for > a > > > >particular subscriber. This is not scalable for NMS that typically has > to > > > >deal with minimum thousands of subscribers. A suggestion is to > eliminate > > > >the Classifier table and have the Datapath table simply provide an > INTEGER > > > >pointer point to the Classifier ID in the Classifier Element Table OR > > > >meterId in the Meter table OR ... Note that the reverse pointer from > > > >the, say Meter table, back to the Classifier table requires the > Classifier > > > >ID only. > > > > > > That is pretty much where we started out. We changed to RowPointer in > > > response to requests from the working group to allow folks to easily add > > > new filter types, such as picking out messages by MAC Address etc. If > you > > > have a specific proposal that would allow for the flexibility we were > asked > > > to provide and addresses your concern (and I agree that this is a lot of > > > round trips), I'd like to hear it. > > > > > > >2. For a full classifier, meter, actions, dropper, queue and scheduler > can > > > >be linked all together via the rowPointer. This is although very smart > > > >but again if the NMS is trying to get all the SLA provisioned on a > single > > > >system. It has to traverse through 6 tables or more in order to get a > > > >single flow's SLA. Again not very scalable. An alternative is to > place > > > >all these table pointers into a single data path table or profile > > > >table. The profile table will have separate object specifying the > > > >relationship between all these tables for a single SLA. The table > pointer > > > >will be NULL if a certain SLA doesn't require, for example, any queue > to > > > >be specified. The datapath table in turns will be assigned with a > single > > > >profile. > > > > > > Could you be more specific? Can you advise how hierarchical systems such > as > > > CBQ would be described using your approach? > > > > > > _______________________________________________ diffserv mailing list > > > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > > tml > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 19 03:53:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08349 for ; Thu, 19 Apr 2001 03:53:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18774; Thu, 19 Apr 2001 03:35:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18745 for ; Thu, 19 Apr 2001 03:35:12 -0400 (EDT) Received: from laurana.thenet.ch (laurana.TheNet.CH [193.247.120.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08218 for ; Thu, 19 Apr 2001 03:35:14 -0400 (EDT) Received: from telscom.ch ([192.168.19.12]) by laurana.thenet.ch (8.9.3/8.9.1/Debian/GNU) with ESMTP id JAA08330; Thu, 19 Apr 2001 09:34:48 +0200 Message-ID: <3ADE9507.8935E565@telscom.ch> Date: Thu, 19 Apr 2001 07:34:31 +0000 From: shyam X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Iliff, Tina" CC: "'Andrew Smith'" , diffserv@ietf.org Subject: Re: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY X-Priority: 1 (Highest) References: <492EB4A3F68CD411ABE800508B69362E3F56CA@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hai All I am working on diffserv and mt task is to analyse the performance of af and ef forwarding . Every thing is going well I am not able to read the TOS field .All the queues are set .I an using ethereal and tcpdump.to monitor the reading . Also can anyone pl tell me the usage of rtmon with one example.pl Any help is appreciated TIA shyam _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 19 10:09:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11265 for ; Thu, 19 Apr 2001 10:09:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23832; Thu, 19 Apr 2001 09:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23799 for ; Thu, 19 Apr 2001 09:49:10 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11038 for ; Thu, 19 Apr 2001 09:49:13 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA34872; Thu, 19 Apr 2001 14:48:39 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA23242; Thu, 19 Apr 2001 14:48:39 +0100 Message-ID: <3ADEEC78.D9DFEF1A@hursley.ibm.com> Date: Thu, 19 Apr 2001 08:47:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: shyam CC: diffserv@ietf.org Subject: Re: [Diffserv] RE: diffserv-pib-03: qosAssuredRate PRIORITY References: <492EB4A3F68CD411ABE800508B69362E3F56CA@RIPEXCH002.wcomnet.com> <3ADE9507.8935E565@telscom.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please use the diffserv implementation list for this. Join the list at http://www.tip.csiro.au/dsimplementation/ Thanks Brian Carpenter diffserv WG co-chair shyam wrote: > > Hai All > > I am working on diffserv and mt task is to analyse the performance of af > and ef forwarding . Every thing is going well > I am not able to read the TOS field .All the queues are set .I an using > ethereal and tcpdump.to monitor the reading . > Also can anyone pl tell me the usage of rtmon with one example.pl > > Any help is appreciated > TIA > > shyam _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 19 10:14:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11364 for ; Thu, 19 Apr 2001 10:14:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23757; Thu, 19 Apr 2001 09:47:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23664 for ; Thu, 19 Apr 2001 09:47:28 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11023 for ; Thu, 19 Apr 2001 09:47:28 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA23956; Thu, 19 Apr 2001 14:46:53 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA59020; Thu, 19 Apr 2001 14:46:52 +0100 Message-ID: <3ADEEC0D.FEB82092@hursley.ibm.com> Date: Thu, 19 Apr 2001 08:45:49 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Faye Ly CC: diffserv Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt References: <2BC6020788F6D04B82E413E548072A0907A2B9@sonscenter.SALIRA.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I can't make the layout look right since your user agent sends HTML... Are you suggesting that the problem you want to solve needs a separate solution from the basic MIB? It begins to look like that. I don't think the DSCPs will get modified during retrieval process, unless the NMS itself allows this, or unless some third party interferes. Brian > Faye Ly wrote: > > Brian, > > You actually brought up a very good point. Each subscriber will have only maybe up to 2 DSCP levels. But NMS has to deal > with hundreds of subscribers per network device that supports diffserv. Let's say this network device supports only 16 DSCP > levels but NMS has to be able to read each subscriber DSCP level somehow via the diffserv MIB. In another words, there might > be hundreds of data path's but only a few (e.g. 16) classifiers. > > NMS could retrieve the 16 DSCP configurations (may this be a linked list of classifier, meter, action ...) first and then > retrieve each individual subscriber's information by getting the datapath entries. NMS can do the OID matching easily in it's > database. > > This only presents a problem that there might be a small window that these 16 DSCP levels may be changed during the retrieval > of the datapath entries? > > -faye > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, April 18, 2001 1:20 PM > To: Faye Ly > Cc: diffserv > Subject: Re: [Diffserv] RE: A few comments for > draft-ietf-diffserv-mib-09.txt > > Faye, > > Can you clarify the point about thousands of subscribers for me? Diffserv deals with > a small number of traffic aggregates - by construction, at most 64 including best effort. > So diffserv technology, including the management plane, only has to scale to 64 queues > per interface, and that is a very theoretical number, with just a few queues more > likely. > > If you are talking about scaling to thousands at the NMS, then my remark about > SNMP GETs is not frivolous because we aren't talking about saving a small factor; > I can't see any solution at that scale that isn't bulked up much more than a generic > per-interface per-queue MIB is ever going to support. > > That doesn't mean I'm against optimising the MIB somewhat of course, but it > won't fundamentally affect scaling as far as I can see. > > I suspect you are asking for what is fundamentally a diagnostic MIB to > behave like a bulk monitoring MIB, and maybe that is simply a different > beast. > > Brian > > > Faye Ly wrote: > > > > Brian, > > > > Actually that is exactly why people started developing their own proprietary MIB. The MIB simply does not scale to hundreds > > > or thousdands (if you take snmpconf-diffpolicy draft into account) subscribers in the network. Some optimization is needed > to > > > make this MIB 'friendly' to the NMS tools. Note that some NMS tools typically will come and refresh it's database > > periodically (daily or weekly). This MIB requires a subtantial amount of time to do so. Note that NMS has a problem that > not > > > all configuration are done via the same tool and hence NMS is forced to refresh it's database from time to time. > > > > Can we at least be willing to deal with the 'optimization' issue with this MIB? > > > > -faye > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, April 18, 2001 6:28 AM > > To: ah_smith@pacbell.net > > Cc: Kwok-Ho Chan; diffserv; Faye Ly > > Subject: Re: [Diffserv] RE: A few comments for > > draft-ietf-diffserv-mib-09.txt > > > > Andrew, > > > > It has always been understood that either SNMPCONF or the PIB > > would be necessary for diffserv configuration - indeed that is a major > > reason why SNMPCONF was started at all. There is no news there. > > Yes, it's pragmatic, but I don't see the confusion. > > > > Since the WG agreed that the MIB should not represent TCBs, you and > > Faye need to respond to Harrie's arguments. > > > > Multiple SNMP GETs are suboptimal for monitoring? Is that news? > > > > Brian > > > > Andrew Smith wrote: > > > > > > Faye's concern gets to the heart of whether it is best to try to have a > > > single data structure to access information for configuration operations > > > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT"). > > > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted > > > Diffserv Schemas, I think the current state of the IETF efforts on this > > > topic can best be described as "pragmatic" (or, less charitably, as > > > "confused"). > > > > > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides > > > some good examples of how) and is, on its own without help from the snmpconf > > > Diffserv Policy MIB, highly suboptimal for configuration. My advice would be > > > to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise > > > before designing any Diffserv configuration application (and you'll probably > > > be needing to write some proprietary MIBs for efficient monitoring of > > > Diffserv on anything other than a small scale). > > > > > > Andrew > > > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > > > documents) > > > > > > -----Original Message----- > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > > > Kwok-Ho Chan > > > Sent: Tuesday, April 17, 2001 3:42 PM > > > To: Faye Ly > > > Cc: Fred Baker; diffserv > > > Subject: Re: [Diffserv] RE: A few comments for > > > draft-ietf-diffserv-mib-09.txt > > > > > > Faye: > > > We have been down this road before (may be not exactly but similar). > > > Your proposal resembles what used to be in the "Target Table" of > > > the original DiffServ PIB. The original Target Table entries tie together > > > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > > > There was consensus amongst the co-authors to make the PIB to look > > > like the MIB instead of the other way arround, hence the RowPointer > > > linkage today in both MIB and PIB. > > > There was also the concerns with SNMPCONF WG's usage of the > > > DiffServ MIB. > > > Just some history. > > > -- Kwok -- > > > > > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > > > > > Fred, > > > > > > Certainly. More emails will follow this one as the proposed changes may > > > require more description. > > > > > > Proposed change: > > > > > > Change diffServDataPathStart to point to an entry in the TCS table. > > > > > > TCS Table is defined as: > > > > > > INDEX {TCBIndex} > > > > > > OBJECTS > > > > > > Classifier Filter pointer - points to a set of filters defined in > > > diffServSixTupleClfrTable. Change > > > the indexing of diffServSixTupleClfrTable > > > to double index {ClassifierId, ClfrId} > > > By specifying the classifier ID in this > > > object, NMS can easily retrieve all the > > > filters defined for this classifier. > > > The syntax of this object will be > > > the same as the ClassifierId defined > > > in the diffServSixTupleClfrTable. > > > > > > Meter pointer - points to an entry in the meter table as defined. > > > > > > Action pointer - points to an entry in the Action table as defined. > > > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop Table. > > > Queue table pointer - points to an entry in the diffServQTable. > > > Scheduler table pointer - points to an entry in the > > > diffServSchedulerTable. > > > > > > Note that these pointers can be zeros meaning the operation should be > > > skipped. Also the NEXT pointer should only be used to point to the next > > > entry in the same table. > > > > > > This matches what is described in [MODEL]: > > > > > > "This model describes the configuration and management of a Diffserv > > > interface in terms of a TCB that contains, by definition, zero or more > > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > > elements. These elements are arranged arbitrarily according to the > > > policy being expressed, but always in the order here. Traffic may be > > > classified; classified traffic may be metered; each stream of traffic > > > identified by a combination of classifiers and meters may have some set > > > of actions performed on it, followed by drop algorithms; packets of the > > > traffic stream may ultimately be stored into a queue and then be > > > scheduled out to the next TCB or physical interface. " > > > > > > The advantage of using the TCS table is to retrieve all the relevant TCB > > > information from one single entry. It also got rid of the Classifier and > > > Classifier element table by using the double indexing scheme. Unless other > > > classifer is being considered or else the classifier element table is not > > > necessary. When other filter is considered, we could always add more > > > objects into the TCS table. I suspect we can further simplify the design of > > > the meter, action, q and scheduler tables as well using the same technique. > > > More emails to come. > > > > > > This is just a concept proposal. I will send MIB table definition out if > > > this concept is acceptable and adoptable. Your thoughts? > > > > > > -faye > > > > > > -----Original Message----- > > > From: Fred Baker [mailto:fred@cisco.com] > > > Sent: Friday, April 13, 2001 10:58 PM > > > To: Faye Ly > > > Cc: diffserv@ietf.org > > > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > > > > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > > > > > >Hi, > > > > > > > >I apologize but I haven't gotten a chance to subscribe to the diffserv > > > >list yet. (With the IPO mailing list experience, I am not sure I want to > > > >:)-) Please feel free to forward this to the mailing list if appropriete. > > > > > > > >-faye > > > > > > > >=========================================================================== > > > ============== > > > > > > > >Hi, > > > > > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > > > > > >1. The major problem I see with this MIB is the usage by NMS. The tables > > > >defined are not very 'friendly' for NMS retrieval. For example, in order > > > >to find out the filter being applied to a subscriber Joe. > > > > > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > > > derive the datapath entry. For our discussion, I don't count the SNMP > > > > packets required to get here. > > > > > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry using > > > > the DataPathStart object. > > > > > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS issues > > > > another SNMP getnext to retrieve the Classifier element until all > > > > elements associated with this classifier are retrieved. > > > > > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the six > > > > tuple classification entry for Joe. > > > > > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a > > > >particular subscriber. This is not scalable for NMS that typically has to > > > >deal with minimum thousands of subscribers. A suggestion is to eliminate > > > >the Classifier table and have the Datapath table simply provide an INTEGER > > > >pointer point to the Classifier ID in the Classifier Element Table OR > > > >meterId in the Meter table OR ... Note that the reverse pointer from > > > >the, say Meter table, back to the Classifier table requires the Classifier > > > >ID only. > > > > > > That is pretty much where we started out. We changed to RowPointer in > > > response to requests from the working group to allow folks to easily add > > > new filter types, such as picking out messages by MAC Address etc. If you > > > have a specific proposal that would allow for the flexibility we were asked > > > to provide and addresses your concern (and I agree that this is a lot of > > > round trips), I'd like to hear it. > > > > > > >2. For a full classifier, meter, actions, dropper, queue and scheduler can > > > >be linked all together via the rowPointer. This is although very smart > > > >but again if the NMS is trying to get all the SLA provisioned on a single > > > >system. It has to traverse through 6 tables or more in order to get a > > > >single flow's SLA. Again not very scalable. An alternative is to place > > > >all these table pointers into a single data path table or profile > > > >table. The profile table will have separate object specifying the > > > >relationship between all these tables for a single SLA. The table pointer > > > >will be NULL if a certain SLA doesn't require, for example, any queue to > > > >be specified. The datapath table in turns will be assigned with a single > > > >profile. > > > > > > Could you be more specific? Can you advise how hierarchical systems such as > > > CBQ would be described using your approach? > > > > > > _______________________________________________ diffserv mailing list > > > diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > > tml > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 19 10:48:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11893 for ; Thu, 19 Apr 2001 10:48:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24617; Thu, 19 Apr 2001 10:20:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24594 for ; Thu, 19 Apr 2001 10:20:55 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11492 for ; Thu, 19 Apr 2001 10:20:58 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA32144; Thu, 19 Apr 2001 15:20:25 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA49026; Thu, 19 Apr 2001 15:20:24 +0100 Message-ID: <3ADEEFA0.D82D9C8A@hursley.ibm.com> Date: Thu, 19 Apr 2001 09:01:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ah_smith@pacbell.net, Fred Baker CC: diffserv Subject: Re: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, There will be lots of enterprise and ISP edge routers with modest numbers of interfaces. An MF classifier MIB is entirely appropriate for them. That is indeed what we've been working on for the last couple of years. You are referring to consumer-subscriber edge boxes and that is certainly a different ball game. We could argue philosophy here (will we be applying diffserv per home user or per small office user?) but for present purposes I agree that we should qualify the diffserv MIB as not scaling to that situation. Fred, can you insert an appropriate applicability sentence? Brian Andrew Smith wrote: > > re Numbers of classifiers: then there should be an added disclaimer > (Applicability Statement) that says this MIB is meant only for Diffserv Core > nodes, not Edge nodes and we should probably go back to the original > BA-classifier-only version (-01 I believe). That would be a shame but it > might be more honest. > > re Numbers of interfaces: I don't think I yet understand your position on > this (1000s of interfaces per box implies 1000s of classifiers per box - > that's physics). > > But some of these scaling issues are resolvable, for configuration > operations, by the use of "template" mechanisms, as in the SNMPCONF work > (that makes the writable part of this Diffserv MIB somewhat moot, in my > opinion). We haven't yet seen much work on this topic for monitoring > operations (RMON-like mechanisms don't help - they help scale the time axis, > not the "number of instances" axis) so we should do all we can to optimise > the utility of this MIB for monitoring at the present time using existing > protocols (specifically SNMP/GETBULK). > > Andrew > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Wednesday, April 18, 2001 2:55 PM > To: Andrew Smith > Cc: diffserv > Subject: Re: Scaling of management plane for Diffserv (was RE: > [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) > > I detect agreement here - if there is a requirement for 1000s of classifiers > in one box, a special purpose monitoring solution will be needed anyway. > I never envisaged the current MIB being used for more than a handful of > classifiers per interface. > > Brian > > Andrew Smith wrote: > > > > Brian, > > > > 1. Several thousands of interfaces per SNMP agent is not at all uncommon > > these days. > > 2. Several thousands of classifier elements on one interface at the edge > of > > a particular Diffserv domain is not unlikely either: it is only the middle > > of a Diffserv domain that benefits from the 64 limit (for some appropriate > > definitions of "middle" and "edge"). > > > > Probably no need for both of these thousands at the same time though. > > > > One solution, of course, would be to implement an appropriately powerful > > supercomputer for the management plane (I'm less concerned about the > > network-bandwidth requirements than processing cycles for the SNMP > protocol > > operations). The traditional alternative to this has been some sort of > > proprietary "encoded octet string" representation to pack the data and > > indexing into PDUs, passing the processing burden largely to the > management > > station. The latter approach usually sells better. > > > > Andrew > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Brian E Carpenter > > Sent: Wednesday, April 18, 2001 1:20 PM > > To: Faye Ly > > Cc: diffserv > > Subject: Re: [Diffserv] RE: A few comments for > > draft-ietf-diffserv-mib-09.txt > > > > Faye, > > > > Can you clarify the point about thousands of subscribers for me? Diffserv > > deals with > > a small number of traffic aggregates - by construction, at most 64 > including > > best effort. > > So diffserv technology, including the management plane, only has to scale > to > > 64 queues > > per interface, and that is a very theoretical number, with just a few > queues > > more > > likely. > > > > If you are talking about scaling to thousands at the NMS, then my remark > > about > > SNMP GETs is not frivolous because we aren't talking about saving a small > > factor; > > I can't see any solution at that scale that isn't bulked up much more than > a > > generic > > per-interface per-queue MIB is ever going to support. > > > > That doesn't mean I'm against optimising the MIB somewhat of course, but > it > > won't fundamentally affect scaling as far as I can see. > > > > I suspect you are asking for what is fundamentally a diagnostic MIB to > > behave like a bulk monitoring MIB, and maybe that is simply a different > > beast. > > > > Brian > > > > > Faye Ly wrote: > > > > > > Brian, > > > > > > Actually that is exactly why people started developing their own > > proprietary MIB. The MIB simply does not scale to hundreds > > > or thousdands (if you take snmpconf-diffpolicy draft into account) > > subscribers in the network. Some optimization is needed to > > > make this MIB 'friendly' to the NMS tools. Note that some NMS tools > > typically will come and refresh it's database > > > periodically (daily or weekly). This MIB requires a subtantial amount > of > > time to do so. Note that NMS has a problem that not > > > all configuration are done via the same tool and hence NMS is forced to > > refresh it's database from time to time. > > > > > > Can we at least be willing to deal with the 'optimization' issue with > this > > MIB? > > > > > > -faye > > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday, April 18, 2001 6:28 AM > > > To: ah_smith@pacbell.net > > > Cc: Kwok-Ho Chan; diffserv; Faye Ly > > > Subject: Re: [Diffserv] RE: A few comments for > > > draft-ietf-diffserv-mib-09.txt > > > > > > Andrew, > > > > > > It has always been understood that either SNMPCONF or the PIB > > > would be necessary for diffserv configuration - indeed that is a major > > > reason why SNMPCONF was started at all. There is no news there. > > > Yes, it's pragmatic, but I don't see the confusion. > > > > > > Since the WG agreed that the MIB should not represent TCBs, you and > > > Faye need to respond to Harrie's arguments. > > > > > > Multiple SNMP GETs are suboptimal for monitoring? Is that news? > > > > > > Brian > > > > > > Andrew Smith wrote: > > > > > > > > Faye's concern gets to the heart of whether it is best to try to have > a > > > > single data structure to access information for configuration > operations > > > > (a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or > > "GETNEXT"). > > > > Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and > assorted > > > > Diffserv Schemas, I think the current state of the IETF efforts on > this > > > > topic can best be described as "pragmatic" (or, less charitably, as > > > > "confused"). > > > > > > > > As it stands, the Diffserv MIB is suboptimal for monitoring (Faye > > provides > > > > some good examples of how) and is, on its own without help from the > > snmpconf > > > > Diffserv Policy MIB, highly suboptimal for configuration. My advice > > would be > > > > to wait for either the snmpconf work or the COPS Diffserv PIB to > > stabilise > > > > before designing any Diffserv configuration application (and you'll > > probably > > > > be needing to write some proprietary MIBs for efficient monitoring of > > > > Diffserv on anything other than a small scale). > > > > > > > > Andrew > > > > (speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB > > > > documents) > > > > > > > > -----Original Message----- > > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On > Behalf > > Of > > > > Kwok-Ho Chan > > > > Sent: Tuesday, April 17, 2001 3:42 PM > > > > To: Faye Ly > > > > Cc: Fred Baker; diffserv > > > > Subject: Re: [Diffserv] RE: A few comments for > > > > draft-ietf-diffserv-mib-09.txt > > > > > > > > Faye: > > > > We have been down this road before (may be not exactly but similar). > > > > Your proposal resembles what used to be in the "Target Table" of > > > > the original DiffServ PIB. The original Target Table entries tie > > together > > > > Classifiers, Meters, Actions, Droppers, Queues, Schedulers. > > > > There was consensus amongst the co-authors to make the PIB to look > > > > like the MIB instead of the other way arround, hence the RowPointer > > > > linkage today in both MIB and PIB. > > > > There was also the concerns with SNMPCONF WG's usage of the > > > > DiffServ MIB. > > > > Just some history. > > > > -- Kwok -- > > > > > > > > At 11:22 AM 4/17/01 -0700, Faye Ly wrote: > > > > > > > > Fred, > > > > > > > > Certainly. More emails will follow this one as the proposed changes > may > > > > require more description. > > > > > > > > Proposed change: > > > > > > > > Change diffServDataPathStart to point to an entry in the TCS table. > > > > > > > > TCS Table is defined as: > > > > > > > > INDEX {TCBIndex} > > > > > > > > OBJECTS > > > > > > > > Classifier Filter pointer - points to a set of filters defined in > > > > diffServSixTupleClfrTable. Change > > > > the indexing of > diffServSixTupleClfrTable > > > > to double index {ClassifierId, ClfrId} > > > > By specifying the classifier ID in this > > > > object, NMS can easily retrieve all the > > > > filters defined for this classifier. > > > > The syntax of this object will be > > > > the same as the ClassifierId defined > > > > in the diffServSixTupleClfrTable. > > > > > > > > Meter pointer - points to an entry in the meter table as defined. > > > > > > > > Action pointer - points to an entry in the Action table as defined. > > > > > > > > Algorithm Drop pointer - points to an entry in the Algorithm Drop > > Table. > > > > Queue table pointer - points to an entry in the diffServQTable. > > > > Scheduler table pointer - points to an entry in the > > > > diffServSchedulerTable. > > > > > > > > Note that these pointers can be zeros meaning the operation should be > > > > skipped. Also the NEXT pointer should only be used to point to the > next > > > > entry in the same table. > > > > > > > > This matches what is described in [MODEL]: > > > > > > > > "This model describes the configuration and management of a Diffserv > > > > interface in terms of a TCB that contains, by definition, zero or more > > > > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler > > > > elements. These elements are arranged arbitrarily according to the > > > > policy being expressed, but always in the order here. Traffic may be > > > > classified; classified traffic may be metered; each stream of traffic > > > > identified by a combination of classifiers and meters may have some > set > > > > of actions performed on it, followed by drop algorithms; packets of > the > > > > traffic stream may ultimately be stored into a queue and then be > > > > scheduled out to the next TCB or physical interface. " > > > > > > > > The advantage of using the TCS table is to retrieve all the relevant > TCB > > > > information from one single entry. It also got rid of the Classifier > > and > > > > Classifier element table by using the double indexing scheme. Unless > > other > > > > classifer is being considered or else the classifier element table is > > not > > > > necessary. When other filter is considered, we could always add more > > > > objects into the TCS table. I suspect we can further simplify the > > design of > > > > the meter, action, q and scheduler tables as well using the same > > technique. > > > > More emails to come. > > > > > > > > This is just a concept proposal. I will send MIB table definition out > > if > > > > this concept is acceptable and adoptable. Your thoughts? > > > > > > > > -faye > > > > > > > > -----Original Message----- > > > > From: Fred Baker [mailto:fred@cisco.com] > > > > Sent: Friday, April 13, 2001 10:58 PM > > > > To: Faye Ly > > > > Cc: diffserv@ietf.org > > > > Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt > > > > > > > > At 03:23 PM 4/13/2001 -0700, Faye Ly wrote: > > > > > > > > >Hi, > > > > > > > > > >I apologize but I haven't gotten a chance to subscribe to the > diffserv > > > > >list yet. (With the IPO mailing list experience, I am not sure I > want > > to > > > > >:)-) Please feel free to forward this to the mailing list if > > appropriete. > > > > > > > > > >-faye > > > > > > > > > > > > >=========================================================================== > > > > ============== > > > > > > > > > >Hi, > > > > > > > > > >Here are some comments for "draft-ietf-diffserv-mib-09.txt". > > > > > > > > > >1. The major problem I see with this MIB is the usage by NMS. The > > tables > > > > >defined are not very 'friendly' for NMS retrieval. For example, in > > order > > > > >to find out the filter being applied to a subscriber Joe. > > > > > > > > > > 1.1 NMS has to first get the logical interface entry for Joe and > > > > > derive the datapath entry. For our discussion, I don't count the > SNMP > > > > > packets required to get here. > > > > > > > > > > 1.2 It then issue a SNMP get to retrieve the classifier entry > > using > > > > > the DataPathStart object. > > > > > > > > > > 1.3 Using the ClfrId retrieved from the classifier table, NMS > > issues > > > > > another SNMP getnext to retrieve the Classifier element until all > > > > > elements associated with this classifier are retrieved. > > > > > > > > > > 1.4 NMS issue SNMP get on each Specific object to retrieve the > six > > > > > tuple classification entry for Joe. > > > > > > > > > >It takes NMS a minimum 4 SNMP requests to retrieve a single filter > for > > a > > > > >particular subscriber. This is not scalable for NMS that typically > has > > to > > > > >deal with minimum thousands of subscribers. A suggestion is to > > eliminate > > > > >the Classifier table and have the Datapath table simply provide an > > INTEGER > > > > >pointer point to the Classifier ID in the Classifier Element Table OR > > > > >meterId in the Meter table OR ... Note that the reverse pointer > from > > > > >the, say Meter table, back to the Classifier table requires the > > Classifier > > > > >ID only. > > > > > > > > That is pretty much where we started out. We changed to RowPointer in > > > > response to requests from the working group to allow folks to easily > add > > > > new filter types, such as picking out messages by MAC Address etc. If > > you > > > > have a specific proposal that would allow for the flexibility we were > > asked > > > > to provide and addresses your concern (and I agree that this is a lot > of > > > > round trips), I'd like to hear it. > > > > > > > > >2. For a full classifier, meter, actions, dropper, queue and > scheduler > > can > > > > >be linked all together via the rowPointer. This is although very > smart > > > > >but again if the NMS is trying to get all the SLA provisioned on a > > single > > > > >system. It has to traverse through 6 tables or more in order to get > a > > > > >single flow's SLA. Again not very scalable. An alternative is to > > place > > > > >all these table pointers into a single data path table or profile > > > > >table. The profile table will have separate object specifying the > > > > >relationship between all these tables for a single SLA. The table > > pointer > > > > >will be NULL if a certain SLA doesn't require, for example, any queue > > to > > > > >be specified. The datapath table in turns will be assigned with a > > single > > > > >profile. > > > > > > > > Could you be more specific? Can you advise how hierarchical systems > such > > as > > > > CBQ would be described using your approach? > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 19 15:49:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17488 for ; Thu, 19 Apr 2001 15:49:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01257; Thu, 19 Apr 2001 15:20:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01227 for ; Thu, 19 Apr 2001 15:20:36 -0400 (EDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16992 for ; Thu, 19 Apr 2001 15:20:41 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [9.20.62.15]) by mail-gw2.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA10192 for ; Thu, 19 Apr 2001 20:19:52 +0100 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA12668; Thu, 19 Apr 2001 20:18:34 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA19974; Thu, 19 Apr 2001 20:17:57 +0100 Message-ID: <3ADF3907.FB99E6E9@hursley.ibm.com> Date: Thu, 19 Apr 2001 14:14:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Faye Ly CC: diffserv Subject: Re: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) References: <2BC6020788F6D04B82E413E548072A09083E3F@sonscenter.SALIRA.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Faye, This addresses your other message as well. Firstly the core. There won't be thousands of data paths through core routers. There will be a small number of diffserv traffic aggregates - the whole idea is to make it scale like NM (N= number of interfaces and M= number of DSCPs). That's the diffserv model. If you get to thousands, you are trying to recreate Intserv using Diffserv and that clearly doesn't scale; the MIB is the least of your problems. Secondly the ISP edge. You will have a few large feeds (either a few large enterprise customers, or a few aggregated NAS clusters). The scale is the same as in the core, except that you will have MF classifiers. Thirdly the campus. I would expect the admission control and MF classification to be done by each LAN's router - no particular scaling problem. The campus aggregation router(s) will not see any detail - just a few traffic aggregates handled by a few BA classifiers. The only place I see the scaling going to thousands is if, and only if, you want to do admission control per subscriber on network access servers. And as I said before, that clearly exceeds the scaling limit of the current MIB. Brian Faye Ly wrote: > > Brian, > > Can you please explain why is that the ISP edge router will support only > a limited > number of interfaces?? What about campus edge routers? Thanks. > > -faye _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 19 18:03:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19015 for ; Thu, 19 Apr 2001 18:03:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03816; Thu, 19 Apr 2001 17:46:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03787 for ; Thu, 19 Apr 2001 17:46:45 -0400 (EDT) Received: from sonscenter.SALIRA.COM ([64.168.86.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18919 for ; Thu, 19 Apr 2001 17:46:35 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C91A.33B3D9B2" Date: Thu, 19 Apr 2001 14:46:34 -0700 Message-ID: <2BC6020788F6D04B82E413E548072A0907A2C4@sonscenter.SALIRA.COM> Thread-Topic: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) Thread-Index: AcDJBcCnOkL2LYyMRxqeL3jZ11q4/QAEy6xA From: "Faye Ly" To: "Brian E Carpenter" Cc: "diffserv" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C0C91A.33B3D9B2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, That was very clear, thank you. I guess what you are saying is that each=20 router is managed by a different network management tool? Or is it a single NM tool that manages both campus LAN routers and corporate center core=20 routers? Do you still think it will not scale up to thousands of interfaces? What about the case where the ILEC is actually the ISP also? Wouldn't they be managing all the edge/core routers using the same network management tool? I guess you are trying to say this is out of the scope of the diffServ and it should be done in the SNMPCONF? I am fine with that since a lot of the north-bound interfaces will not be SNMP only. I was hoping too much I guess! Thanks. -faye -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, April 19, 2001 12:14 PM To: Faye Ly Cc: diffserv Subject: Re: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) Faye, This addresses your other message as well. Firstly the core. There won't be thousands of data paths through core routers. There will be a small number of diffserv traffic aggregates - the whole idea is to make it scale like NM (N=3D number of interfaces and M=3D number = of DSCPs). That's the diffserv model. If you get to thousands, you are trying to recreate=20 Intserv using Diffserv and that clearly doesn't scale; the MIB is the least=20 of your problems. Secondly the ISP edge. You will have a few large feeds (either a few large enterprise customers, or a few aggregated NAS clusters). The scale is the same as in the core, except that you will have MF classifiers. Thirdly the campus. I would expect the admission control and MF classification to be done by each LAN's router - no particular scaling problem. The campus aggregation router(s) will not see any detail - just a few traffic aggregates handled by a few BA classifiers. The only place I see the scaling going to thousands is if, and only if, you want to do admission control per subscriber on network access servers. And as I said before, that clearly exceeds the scaling limit of the current MIB. Brian Faye Ly wrote: >=20 > Brian, >=20 > Can you please explain why is that the ISP edge router will support only > a limited > number of interfaces?? What about campus edge routers? Thanks. >=20 > -faye ------_=_NextPart_001_01C0C91A.33B3D9B2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Scaling of management plane for Diffserv (was RE: [Diffserv] = RE: A few comments for draft-ietf-diffserv-mib-09.txt)

Brian,

That was very clear, thank you.  I guess what you = are saying is that each
router is managed by a different network management = tool?  Or is it a single
NM tool that manages both campus LAN routers and = corporate center core
routers?  Do you still think it will not scale = up to thousands of interfaces?

What about the case where the ILEC is actually the ISP = also?  Wouldn't they
be managing all the edge/core routers using the same = network management
tool?  I guess you are trying to say this is out = of the scope of the diffServ
and it should be done in the SNMPCONF?  I am = fine with that since a lot of
the north-bound interfaces will not be SNMP = only.  I was hoping too much I guess!

Thanks.

-faye

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Thursday, April 19, 2001 12:14 PM
To: Faye Ly
Cc: diffserv
Subject: Re: Scaling of management plane for Diffserv = (was RE:
[Diffserv] RE: A few comments for = draft-ietf-diffserv-mib-09.txt)


Faye,

This addresses your other message as well.

Firstly the core. There won't be thousands of data = paths through core routers.
There will be a small number of diffserv traffic = aggregates - the whole idea
is to make it scale like NM (N=3D number of = interfaces and M=3D number of DSCPs).
That's the diffserv model. If you get to thousands, = you are trying to recreate
Intserv using Diffserv and that clearly doesn't = scale; the MIB is the least
of your problems.

Secondly the ISP edge. You will have a few large feeds = (either a few large
enterprise customers, or a few aggregated NAS = clusters). The scale is
the same as in the core, except that you will have MF = classifiers.

Thirdly the campus. I would expect the admission = control and MF classification
to be done by each LAN's router - no particular = scaling problem. The campus
aggregation router(s) will not see any detail - just = a few traffic aggregates
handled by a few BA classifiers.

The only place I see the scaling going to thousands is = if, and only if, you
want to do admission control per subscriber on = network access servers. And as
I said before, that clearly exceeds the scaling limit = of the current MIB.

   Brian

Faye Ly wrote:
>
> Brian,
>
> Can you please explain why is that the ISP edge = router will support only
> a limited
> number of interfaces??  What about campus = edge routers?  Thanks.
>
> -faye

------_=_NextPart_001_01C0C91A.33B3D9B2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 20 05:02:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09117 for ; Fri, 20 Apr 2001 05:02:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19031; Fri, 20 Apr 2001 04:40:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19000 for ; Fri, 20 Apr 2001 04:40:04 -0400 (EDT) Received: from lisanza.net ([151.29.213.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08977 for ; Fri, 20 Apr 2001 04:40:01 -0400 (EDT) Received: from covalent.net (localhost [127.0.0.1]) by lisanza.net (8.9.3/8.9.3) with ESMTP id KAA01000; Fri, 20 Apr 2001 10:40:35 +0200 (CEST) (envelope-from harrie@covalent.net) Message-ID: <3ADFEA28.FB8ADE0E@covalent.net> Date: Fri, 20 Apr 2001 09:50:00 +0200 From: Harrie Hazewinkel Organization: Covalent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Faye Ly CC: Brian E Carpenter , Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt References: <2BC6020788F6D04B82E413E548072A0907A2B7@sonscenter.SALIRA.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit HI Faye, > Faye Ly wrote: > > Harrie, > > Another point you mentioned is the ordering. You are very right that > I have not addressed it. The fact is I didn't know that some TCB text > is subject to be dropped from the [MODEL]. The proposal I proposed > does ensure the ordering to be (as you rightly pointed out): > > classifier -> meter -> action (count or dropper) -> queue -> scheduler SO, you restrict the order by only the order as given above. I believe the DIFFSERV-MIB does not want that. How do I for instance, a count action and a absolute drop action for a perticular part of a datapath?? Not possible here, since the datapath element that follows the action is a queue and not another action. What happens when someone wants to have an action before the meter?? For instance, after a classification on DSCP 34, I want to count all that traffic after which I want to meter that traffic. Correct me if I am wrong but that does not fit in your schema. > > One solution came to my mind is to add an ordering object that specify > the ordering via a string of OIDs. Or some other numbering scheme > like assigning each table with an ENUM value and show the ENUM value > order in the ordering object. If you add an ordering object, you still have the problem when you want 2 actions. In this proposal you can neither have a split in a datapath, ie. after a meter how do you handle a FailNext and SucceedNext?? You cannot you have only 1 pointer. Or am I missing something?? > > In conclusion, ordering can be resolved. If by resolving the ordering > we can somehow provide NMS a more scalable MIB, I think it is well > worth it. > > Your thoughts? As Brian mentioned, the amount of datapath elements and so will be at a reasonable scale. Your proposal neither seems to reflect what is needed from the DIFFSERV-MIB. Harrie PS: I am not taking anyside on whether to add it or not. I just look at the proposal which I think does not work for what it needs to represent. -- phone: +39-3474932300 http://www.lisanza.net/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 20 15:45:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17033 for ; Fri, 20 Apr 2001 15:45:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27006; Fri, 20 Apr 2001 13:02:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26974 for ; Fri, 20 Apr 2001 13:02:20 -0400 (EDT) Received: from sonscenter.SALIRA.COM ([64.168.86.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14553 for ; Fri, 20 Apr 2001 13:02:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9BB.A00B256A" Date: Fri, 20 Apr 2001 10:02:04 -0700 Message-ID: <2BC6020788F6D04B82E413E548072A0907A2C6@sonscenter.SALIRA.COM> Thread-Topic: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Thread-Index: AcDJdXYPQnR5a/AcSLGNYOnEyReEdwAQt2MA From: "Faye Ly" To: "Harrie Hazewinkel" Cc: "Brian E Carpenter" , "Fred Baker" , Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C0C9BB.A00B256A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harrie, Yes, I think we are in violent agreement that no ordering should be forced by the MIB. Only implied as a linked list by the current MIB design. =20 Let's try to look at the MIB design from another angle: If we try to vidualize a NMS screen that allow you to provision a 'flow' or a 'data path', one way will be listing all the possible items you can pick from and this includes all the classifier, meter, action ... Very unfortunately we have to list all the options on a single screen and other screens will popup based on the selection such as six-tuple filters. A GUI becomes a lot less flexible than a straight command line in this case given the MIB designed. But this MIB works perfectly well if you allow customer to enter configuration via command line like interface. This is a pure design issue but with my personal experience, GUI works much better if you list all the things out explicitely and all the customer needs to do is to point and click.=20 If you agree with this kind of NMS screen design, you will find that we will have to provide all the selections (classifier, meter ...) in one screen or one table. =20 Why not make the MIB match it? If certain ordering is to be enforced as the=20 current linked list MIB objects indicated, we can always design a smart MIB=20 object to dictate the ordering. That is, customer can specify it explicitely. Another point you mentioned is multiple actions, this is a relatively easy issue. Just have a double indexed action table and the problem is solved. At this point, I suspect the list doesn't really want to change the MIB design. I will most likely use portion of this MIB and portion of proprietary MIB.=20 Thank you very much for all your inputs though as they are all very helpful to me.=20 -faye =20 -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@covalent.net] Sent: Friday, April 20, 2001 12:50 AM To: Faye Ly Cc: Brian E Carpenter; Fred Baker; diffserv@ietf.org Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt HI Faye, > Faye Ly wrote: >=20 > Harrie, >=20 > Another point you mentioned is the ordering. You are very right that > I have not addressed it. The fact is I didn't know that some TCB text > is subject to be dropped from the [MODEL]. The proposal I proposed > does ensure the ordering to be (as you rightly pointed out): >=20 > classifier -> meter -> action (count or dropper) -> queue -> scheduler SO, you restrict the order by only the order as given above. I believe the DIFFSERV-MIB does not want that. How do I for instance, a count action and a absolute drop action for a perticular part of a datapath?? Not possible here, since the datapath element that follows the action is a queue and not another action. What happens when someone wants to have an action before the meter?? For instance, after a classification on DSCP 34, I want to count all that traffic after which I want to meter that traffic. Correct me if I am wrong but that does not fit in your schema. >=20 > One solution came to my mind is to add an ordering object that specify > the ordering via a string of OIDs. Or some other numbering scheme > like assigning each table with an ENUM value and show the ENUM value > order in the ordering object. If you add an ordering object, you still have the problem when you want 2 actions. In this proposal you can neither have a split in a datapath, ie. after a meter how do you handle a FailNext and SucceedNext?? You cannot you have only 1 pointer. Or am I missing something?? >=20 > In conclusion, ordering can be resolved. If by resolving the ordering > we can somehow provide NMS a more scalable MIB, I think it is well > worth it. >=20 > Your thoughts? As Brian mentioned, the amount of datapath elements and so will be at a reasonable scale. Your proposal neither seems to reflect what is needed from the DIFFSERV-MIB. Harrie PS: I am not taking anyside on whether to add it or not. I just look at the proposal which I think does not work for what it needs to represent. --=20 phone: +39-3474932300 http://www.lisanza.net/ ------_=_NextPart_001_01C0C9BB.A00B256A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RE: A few comments for = draft-ietf-diffserv-mib-09.txt

Harrie,

Yes, I think we are in violent agreement that no = ordering should be forced
by the MIB.  Only implied as a linked list by = the current MIB design. 

Let's try to look at the MIB design from another = angle:

If we try to vidualize a NMS screen that allow you to = provision
a 'flow' or a 'data path', one way will be listing = all the possible items
you can pick from and this includes all the = classifier, meter, action ...
Very unfortunately we have to list all the options on = a single screen and
other screens will popup based on the selection such = as six-tuple filters.

A GUI becomes a lot less flexible than a straight = command line in this case
given the MIB designed.  But this MIB works = perfectly well if you allow
customer to enter configuration via command line like = interface.  This is a
pure design issue but with my personal experience, = GUI works much better if
you list all the things out explicitely and all the = customer needs to do is to
point and click.

If you agree with this kind of NMS screen design, you = will find that we will
have to provide all the selections (classifier, meter = ...) in one screen or
one table. 
Why not make the MIB match it?  If certain = ordering is to be enforced as the
current linked list MIB objects indicated, we can = always design a smart MIB
object to dictate the ordering.  That is, = customer can specify it explicitely.

Another point you mentioned is multiple actions, this = is a relatively easy
issue.  Just have a double indexed action table = and the problem is solved.

At this point, I suspect the list doesn't really want = to change the MIB design.
I will most likely use portion of this MIB and = portion of proprietary MIB.
Thank you very much for all your inputs though as = they are all very helpful to
me.

-faye 


-----Original Message-----
From: Harrie Hazewinkel [mailto:harrie@covalent.net]
Sent: Friday, April 20, 2001 12:50 AM
To: Faye Ly
Cc: Brian E Carpenter; Fred Baker; = diffserv@ietf.org
Subject: Re: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt


HI Faye,

> Faye Ly wrote:
>
> Harrie,
>
> Another point you mentioned is the = ordering.  You are very right that
> I have not addressed it.  The fact is I = didn't know that some TCB text
> is subject to be dropped from the [MODEL].  = The proposal I proposed
> does ensure the ordering to be (as you rightly = pointed out):
>
> classifier -> meter -> action (count or = dropper) -> queue -> scheduler

SO, you restrict the order by only the order as given = above.
I believe the DIFFSERV-MIB does not want that.
How do I for instance, a count action and a = absolute
drop action for a perticular part of a = datapath??
Not possible here, since the datapath element = that
follows the action is a queue and not another = action.

What happens when someone wants to have an action = before the meter??
For instance, after a classification on DSCP 34, I = want to count all
that traffic after which I want to meter that = traffic.

Correct me if I am wrong but that does not fit in your = schema.

>
> One solution came to my mind is to add an = ordering object that specify
> the ordering via a string of OIDs.  Or some = other numbering scheme
> like assigning each table with an ENUM value and = show the ENUM value
> order in the ordering object.

If you add an ordering object, you still have the = problem when you want
2 actions. In this proposal you can neither have a = split in a datapath,
ie. after a meter how do you handle a FailNext and = SucceedNext??
You cannot you have only 1 pointer. Or am I missing = something??

>
> In conclusion, ordering can be resolved.  = If by resolving the ordering
> we can somehow provide NMS a more scalable MIB, = I think it is well
> worth it.
>
> Your thoughts?

As Brian mentioned, the amount of datapath elements = and so
will be at a reasonable scale. Your proposal neither = seems
to reflect what is needed from the = DIFFSERV-MIB.

Harrie

PS: I am not taking anyside on whether to add it or = not.
I just look at the proposal which I think does not = work
for what it needs to represent.
--
phone: +39-3474932300
http://www.lisanza.net/

------_=_NextPart_001_01C0C9BB.A00B256A-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 20 20:27:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20340 for ; Fri, 20 Apr 2001 20:27:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03376; Fri, 20 Apr 2001 20:06:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03339 for ; Fri, 20 Apr 2001 20:06:06 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20144 for ; Fri, 20 Apr 2001 20:06:06 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA26190; Fri, 20 Apr 2001 17:05:51 -0700 (PDT) Message-Id: <5.0.2.1.2.20010420165639.02994590@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 20 Apr 2001 17:04:06 -0700 To: "Faye Ly" From: Fred Baker Subject: RE: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) Cc: "Brian E Carpenter" , , "diffserv" In-Reply-To: <2BC6020788F6D04B82E413E548072A09083E3F@sonscenter.SALIRA.C OM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:31 AM 4/19/2001 -0700, Faye Ly wrote: >Can you please explain why is that the ISP edge router will support only a >limited >number of interfaces?? What about campus edge routers? what my ISP customers tell me is that they would like it to be able to support a large number of interfaces - the more the merrier, it seems. If they can support N access customers (whose line is already a single point of failure) with one box instead of ten, they seem to be happy to do so. They also tell me, and this is where snmpconf comes in, that these access contracts often fall into a few categories. For example, if I call Verizon and ask for DSL service to my home, they ask me to choose from a short menu of DSL contracts they sell. Or if I go as a business to get a leased line to their network, they tend to say "what speed, and with what worst case latency within our network", and maybe a couple more questions. Anything beyond that gets real sticky. So a DSL access device might support some number of thousands of interfaces, but they will fall into a few categories of contract and therefore of configuration. At this point, I expect Andrew to chime in and say "so they would be configured by describing a "role" for each such contract, configuring the router with a set of role templates, and telling each interface what role they support. They then derive their configuration from the template. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 20 21:21:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20803 for ; Fri, 20 Apr 2001 21:21:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04636; Fri, 20 Apr 2001 21:06:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04577 for ; Fri, 20 Apr 2001 21:06:25 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20681 for ; Fri, 20 Apr 2001 21:06:24 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA14182; Fri, 20 Apr 2001 18:05:49 -0700 (PDT) Message-Id: <5.0.2.1.2.20010420170745.033797b0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 20 Apr 2001 17:53:38 -0700 To: "Faye Ly" From: Fred Baker Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Cc: "Harrie Hazewinkel" , "Brian E Carpenter" , In-Reply-To: <2BC6020788F6D04B82E413E548072A0907A2C6@sonscenter.SALIRA.C OM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 10:02 AM 4/20/2001 -0700, Faye Ly wrote: >If we try to vidualize a NMS screen that allow you to provision >a 'flow' or a 'data path', one way will be listing all the possible items >you can pick from and this includes all the classifier, meter, action ... >Very unfortunately we have to list all the options on a single screen and >other screens will popup based on the selection such as six-tuple filters. true, but as your words imply, that is not the only way to design the screen. When I write a document, I use an outline generator called "Inspiration". I like it, it's a good tool, and it allows me to do a number of fairly flexible things. One of the things it enables me to do is easily build flow charts, such as the ones I deployed in ftp://ftpeng.cisco.com/fred/diffserv/Diffserv-MIB.htm, which is the presentation I used when I originally proposed this approach to the MIB to the working group in Oslo. I'd suggest you glance through it. You get a flavor of my thinking at the time, some of which has been retained. Now, the tool I used to build those flow charts, Inspiration, gives me some simple graphics and the ability to link them together by pointing and clicking. I am not a GUI designer, but if I were designing a GUI for using this MIB to configure, my GUI would have a lot of the same characteristics. It would have a think I could grab and drop in place for each kind of meter/action/etc, and it would allow me to link them together in certain ways, and it would allow me to easily parameterize the various boxes I was putting in. The relationship between the SNMP stuff and the pictures on the screen would be apparent to someone who knew the MIB, but not determined by the structure of the MIB. every arrow on the screen would correspond to a RowPointer, for example, but every RowPointer in the MIB need not show up as an arrow. the idea behind the mumble-specific pointers, for example, is to be able to write something down once and apply it may times. If I were configuring a role, and then applying the role to the interface, I don't know that the fact of the mumble-specific pointer would appear on the screen at all - I suspect it would be a fact hidden by the tool. I can also imagine that there might be some templates built into the tool, that allowed you to say "I want to configure one EF and three AF classes" and then start filling in blanks. As to the counters coming out, I suspect that I might put them into a format I could easily import to a plotter or spread sheet. I don't see how all this relates to the UI in any way, frankly, unless the UI is being designed in a very simplistic manner that only supports a very limited set of features... SNMP is not designed to be a user interface, or to guide the development of user interfaces. It is intended to be a machine to machine language that lets whatever the UI did to materialize somewhere else. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 20 21:22:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20829 for ; Fri, 20 Apr 2001 21:22:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04607; Fri, 20 Apr 2001 21:06:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04570 for ; Fri, 20 Apr 2001 21:06:24 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20679 for ; Fri, 20 Apr 2001 21:06:23 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA14174; Fri, 20 Apr 2001 18:05:48 -0700 (PDT) Message-Id: <5.0.2.1.2.20010420170442.02994de0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 20 Apr 2001 17:06:44 -0700 To: Harrie Hazewinkel From: Fred Baker Subject: Re: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt Cc: Faye Ly , Brian E Carpenter , diffserv@ietf.org In-Reply-To: <3ADFEA28.FB8ADE0E@covalent.net> References: <2BC6020788F6D04B82E413E548072A0907A2B7@sonscenter.SALIRA.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 09:50 AM 4/20/2001 +0200, Harrie Hazewinkel wrote: > > classifier -> meter -> action (count or dropper) -> queue -> scheduler > >SO, you restrict the order by only the order as given above. >I believe the DIFFSERV-MIB does not want that. yes. That is exactly what was originally proposed, and folks asked for things like CBQ hierarchical queuing support, or the ability to support multiple actions (both counting and RED dropping, for example), or the ability to cascade schedulers (use priority scheduling for some queues and some form of processor sharing for the rest, for example). So we specifically made it general enough that one can string together whatever one likes, like tinker toys. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 20 22:20:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22129 for ; Fri, 20 Apr 2001 22:20:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04567; Fri, 20 Apr 2001 21:06:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04537 for ; Fri, 20 Apr 2001 21:06:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20677 for ; Fri, 20 Apr 2001 21:06:00 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA14189; Fri, 20 Apr 2001 18:05:51 -0700 (PDT) Message-Id: <5.0.2.1.2.20010420165521.00af1568@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 20 Apr 2001 17:54:15 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: Scaling of management plane for Diffserv (was RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt) Cc: ah_smith@pacbell.net, diffserv In-Reply-To: <3ADEEFA0.D82D9C8A@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 09:01 AM 4/19/2001 -0500, Brian E Carpenter wrote: >Fred, can you insert an appropriate applicability sentence? of course. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 22:47:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29609 for ; Thu, 26 Apr 2001 22:47:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03798; Thu, 26 Apr 2001 22:25:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03769 for ; Thu, 26 Apr 2001 22:25:40 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28174 for ; Thu, 26 Apr 2001 22:25:39 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 22:47:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29620 for ; Thu, 26 Apr 2001 22:47:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03873; Thu, 26 Apr 2001 22:28:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03842 for ; Thu, 26 Apr 2001 22:28:47 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28213 for ; Thu, 26 Apr 2001 22:28:46 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 22:47:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29634 for ; Thu, 26 Apr 2001 22:47:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03835; Thu, 26 Apr 2001 22:27:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03803 for ; Thu, 26 Apr 2001 22:27:16 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28182 for ; Thu, 26 Apr 2001 22:27:14 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 23:00:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29868 for ; Thu, 26 Apr 2001 23:00:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04332; Thu, 26 Apr 2001 22:44:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04303 for ; Thu, 26 Apr 2001 22:44:23 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29597 for ; Thu, 26 Apr 2001 22:44:22 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 23:16:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00124 for ; Thu, 26 Apr 2001 23:16:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04654; Thu, 26 Apr 2001 23:00:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04597 for ; Thu, 26 Apr 2001 22:59:58 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29852 for ; Thu, 26 Apr 2001 22:59:56 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 23:32:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00883 for ; Thu, 26 Apr 2001 23:32:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05174; Thu, 26 Apr 2001 23:15:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05147 for ; Thu, 26 Apr 2001 23:15:31 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00121 for ; Thu, 26 Apr 2001 23:15:30 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Apr 26 23:49:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01180 for ; Thu, 26 Apr 2001 23:49:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05640; Thu, 26 Apr 2001 23:31:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05617 for ; Thu, 26 Apr 2001 23:31:07 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00700 for ; Thu, 26 Apr 2001 23:31:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 00:03:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01427 for ; Fri, 27 Apr 2001 00:03:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05950; Thu, 26 Apr 2001 23:46:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05921 for ; Thu, 26 Apr 2001 23:46:44 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01170 for ; Thu, 26 Apr 2001 23:46:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 00:20:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01649 for ; Fri, 27 Apr 2001 00:20:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06547; Fri, 27 Apr 2001 00:02:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06516 for ; Fri, 27 Apr 2001 00:02:27 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01419 for ; Fri, 27 Apr 2001 00:02:24 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 00:35:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02030 for ; Fri, 27 Apr 2001 00:35:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06959; Fri, 27 Apr 2001 00:18:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06928 for ; Fri, 27 Apr 2001 00:18:04 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01630 for ; Fri, 27 Apr 2001 00:18:05 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 00:52:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02309 for ; Fri, 27 Apr 2001 00:52:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07508; Fri, 27 Apr 2001 00:33:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07483 for ; Fri, 27 Apr 2001 00:33:43 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02023 for ; Fri, 27 Apr 2001 00:33:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 01:06:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02623 for ; Fri, 27 Apr 2001 01:06:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07918; Fri, 27 Apr 2001 00:49:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07885 for ; Fri, 27 Apr 2001 00:49:16 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02269 for ; Fri, 27 Apr 2001 00:49:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 01:23:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04402 for ; Fri, 27 Apr 2001 01:23:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08447; Fri, 27 Apr 2001 01:05:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08359 for ; Fri, 27 Apr 2001 01:04:59 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02501 for ; Fri, 27 Apr 2001 01:05:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 01:39:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06270 for ; Fri, 27 Apr 2001 01:39:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15545; Fri, 27 Apr 2001 01:20:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15514 for ; Fri, 27 Apr 2001 01:20:45 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04080 for ; Fri, 27 Apr 2001 01:20:45 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 01:54:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08070 for ; Fri, 27 Apr 2001 01:54:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16019; Fri, 27 Apr 2001 01:36:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15983 for ; Fri, 27 Apr 2001 01:36:24 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06001 for ; Fri, 27 Apr 2001 01:36:25 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 02:08:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA14545 for ; Fri, 27 Apr 2001 02:08:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16339; Fri, 27 Apr 2001 01:52:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16308 for ; Fri, 27 Apr 2001 01:51:56 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07685 for ; Fri, 27 Apr 2001 01:51:56 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 02:24:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17013 for ; Fri, 27 Apr 2001 02:24:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16795; Fri, 27 Apr 2001 02:07:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16765 for ; Fri, 27 Apr 2001 02:07:29 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13954 for ; Fri, 27 Apr 2001 02:07:29 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 02:39:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17259 for ; Fri, 27 Apr 2001 02:39:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17102; Fri, 27 Apr 2001 02:23:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17074 for ; Fri, 27 Apr 2001 02:23:03 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17008 for ; Fri, 27 Apr 2001 02:23:03 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 02:58:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17498 for ; Fri, 27 Apr 2001 02:58:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17621; Fri, 27 Apr 2001 02:38:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17590 for ; Fri, 27 Apr 2001 02:38:36 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17236 for ; Fri, 27 Apr 2001 02:38:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 03:13:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17718 for ; Fri, 27 Apr 2001 03:13:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17918; Fri, 27 Apr 2001 02:54:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17891 for ; Fri, 27 Apr 2001 02:54:09 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17427 for ; Fri, 27 Apr 2001 02:54:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 03:26:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17888 for ; Fri, 27 Apr 2001 03:26:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18525; Fri, 27 Apr 2001 03:08:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18495 for ; Fri, 27 Apr 2001 03:08:26 -0400 (EDT) Received: from iere.net.avaya.com ([198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17601 for ; Fri, 27 Apr 2001 03:08:26 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f3R77tW15888 for ; Fri, 27 Apr 2001 03:07:55 -0400 (EDT) Received: from rhw.post.avaya.com (rhw [135.74.205.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f3R77sJ15881; Fri, 27 Apr 2001 03:07:54 -0400 (EDT) Received: from natasha.auslabs.avaya.com by rhw.post.avaya.com (8.9.3+Sun/EMS-1.5a Solaris/Relay/POST) id DAA08117; Fri, 27 Apr 2001 03:08:24 -0400 (EDT) Received: by natasha.auslabs.avaya.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 17:08:22 +1000 Message-ID: From: "Minhazuddin, Muneyb" To: =?iso-8859-1?Q?=27amuratt_=FDloglu=27?= , diffserv@ietf.org Subject: RE: [Diffserv] Diffserv Complaint in terms of DSCP Date: Fri, 27 Apr 2001 17:08:22 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA18496 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id DAA18525 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17888 Read RFC2474 Section 4. Cheers Muneyb. Muneyb Minhazuddin Avaya Labs R&D North Ryde NSW 2113 Phone : +61 2 9352 8620 Mobile : +61 414 543 458 > -----Original Message----- > From: amuratt 齦oglu [mailto:alimrt@hotmail.com] > Sent: Friday, 27 April 2001 12:25 PM > To: diffserv@ietf.org > Subject: [Diffserv] Diffserv Complaint in terms of DSCP > > > > In RFC 791 and RFC 1812, it is recommended not to use IP PRE > 6 and 7 for > user traffic ( reserved for internetwork and network control traffic). > Can anyone argueits diffserv compatibility If somebody use > 110 or 111 Class > Selector Code point in defining user data classes. > Plaese send your comments > Ali Iloglu > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > ent/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 03:26:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17917 for ; Fri, 27 Apr 2001 03:26:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18563; Fri, 27 Apr 2001 03:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18532 for ; Fri, 27 Apr 2001 03:09:50 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17623 for ; Fri, 27 Apr 2001 03:09:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 03:43:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18225 for ; Fri, 27 Apr 2001 03:43:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18894; Fri, 27 Apr 2001 03:25:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18858 for ; Fri, 27 Apr 2001 03:25:24 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17876 for ; Fri, 27 Apr 2001 03:25:23 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 03:58:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18491 for ; Fri, 27 Apr 2001 03:58:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19602; Fri, 27 Apr 2001 03:41:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19571 for ; Fri, 27 Apr 2001 03:41:05 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18178 for ; Fri, 27 Apr 2001 03:41:04 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 04:14:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18794 for ; Fri, 27 Apr 2001 04:14:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20091; Fri, 27 Apr 2001 03:56:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20059 for ; Fri, 27 Apr 2001 03:56:40 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18428 for ; Fri, 27 Apr 2001 03:56:38 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 04:30:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18983 for ; Fri, 27 Apr 2001 04:30:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20820; Fri, 27 Apr 2001 04:12:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20789 for ; Fri, 27 Apr 2001 04:12:33 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18741 for ; Fri, 27 Apr 2001 04:12:32 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 04:46:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19229 for ; Fri, 27 Apr 2001 04:46:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21206; Fri, 27 Apr 2001 04:28:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21184 for ; Fri, 27 Apr 2001 04:28:20 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18961 for ; Fri, 27 Apr 2001 04:28:19 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 04:54:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19338 for ; Fri, 27 Apr 2001 04:54:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21731; Fri, 27 Apr 2001 04:38:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21699 for ; Fri, 27 Apr 2001 04:38:12 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19090 for ; Fri, 27 Apr 2001 04:38:10 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA19412; Fri, 27 Apr 2001 01:38:10 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id BAA20634; Fri, 27 Apr 2001 01:38:10 -0700 (PDT) Date: Fri, 27 Apr 2001 01:38:10 -0700 (PDT) From: demir To: =?X-UNKNOWN?Q?amuratt_=FDloglu?= cc: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv Complaint in terms of DSCP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Ali, Your email has been received more than one time. I think there is something wrong. You should stop sending the same email to the group. Answering your question: Class selector codepoints support legacy use of the IP precedence field. These codepoints span the TOS field as well as the predecence field, but the TOS field is not recognized by class seelctor PHB group. I think there is no restriction on the usage of selectors for user data. I.e. Default PHB (DSCP: 000000) which is a class selector PHB corresponding to the lowest level of IP predecence might offer "best-effort" service for user data. However, all is implementation dependant. Different implementations might offer differt services for Class Selector PHB group using various resource allocation mechanisms. The only requirement is that traffic marked for higher precedence level is assured a higher or equal probability of forwarding than packets marked with a lower level precedence level. RFC 2474 gives more on the issue in detail. Alper K. Demir > In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for > user traffic ( reserved for internetwork and network control traffic). > Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class > Selector Code point in defining user data classes. > Plaese send your comments > Ali Iloglu > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 05:00:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19450 for ; Fri, 27 Apr 2001 05:00:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21936; Fri, 27 Apr 2001 04:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21909 for ; Fri, 27 Apr 2001 04:44:05 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19210 for ; Fri, 27 Apr 2001 04:44:03 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 05:19:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19794 for ; Fri, 27 Apr 2001 05:19:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22293; Fri, 27 Apr 2001 04:59:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22262 for ; Fri, 27 Apr 2001 04:59:40 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19420 for ; Fri, 27 Apr 2001 04:59:38 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 05:57:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20288 for ; Fri, 27 Apr 2001 05:57:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23417; Fri, 27 Apr 2001 05:30:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23386 for ; Fri, 27 Apr 2001 05:30:48 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19947 for ; Fri, 27 Apr 2001 05:30:45 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 06:05:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20433 for ; Fri, 27 Apr 2001 06:05:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23738; Fri, 27 Apr 2001 05:46:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23702 for ; Fri, 27 Apr 2001 05:46:27 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20122 for ; Fri, 27 Apr 2001 05:46:24 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 06:11:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20501 for ; Fri, 27 Apr 2001 06:11:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22892; Fri, 27 Apr 2001 05:15:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22861 for ; Fri, 27 Apr 2001 05:15:12 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19724 for ; Fri, 27 Apr 2001 05:15:10 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 06:30:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20736 for ; Fri, 27 Apr 2001 06:30:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24298; Fri, 27 Apr 2001 06:02:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24264 for ; Fri, 27 Apr 2001 06:01:59 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20411 for ; Fri, 27 Apr 2001 06:01:57 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 06:41:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20844 for ; Fri, 27 Apr 2001 06:41:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24653; Fri, 27 Apr 2001 06:17:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24631 for ; Fri, 27 Apr 2001 06:17:36 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20605 for ; Fri, 27 Apr 2001 06:17:33 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 06:52:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21716 for ; Fri, 27 Apr 2001 06:52:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25183; Fri, 27 Apr 2001 06:33:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25154 for ; Fri, 27 Apr 2001 06:33:14 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20770 for ; Fri, 27 Apr 2001 06:33:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 07:08:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22498 for ; Fri, 27 Apr 2001 07:08:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25448; Fri, 27 Apr 2001 06:44:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25350 for ; Fri, 27 Apr 2001 06:44:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20948; Fri, 27 Apr 2001 06:44:04 -0400 (EDT) Message-Id: <200104271044.GAA20948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 27 Apr 2001 06:44:04 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-efresolve-01.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : A Delay Bound alternative revision of RFC2598 Author(s) : G. Armitage et al. Filename : draft-ietf-diffserv-efresolve-01.txt Pages : 9 Date : 26-Apr-01 At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC2598, bearing in mind the issues raised in the DiffServ group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-efresolve-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-efresolve-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-efresolve-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010426132312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-efresolve-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-efresolve-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010426132312.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 07:15:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22759 for ; Fri, 27 Apr 2001 07:15:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25619; Fri, 27 Apr 2001 06:49:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25588 for ; Fri, 27 Apr 2001 06:49:02 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21504 for ; Fri, 27 Apr 2001 06:49:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 07:32:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23615 for ; Fri, 27 Apr 2001 07:32:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26319; Fri, 27 Apr 2001 07:05:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26288 for ; Fri, 27 Apr 2001 07:05:15 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22393 for ; Fri, 27 Apr 2001 07:05:14 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 07:44:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24021 for ; Fri, 27 Apr 2001 07:44:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26699; Fri, 27 Apr 2001 07:21:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26667 for ; Fri, 27 Apr 2001 07:21:08 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22931 for ; Fri, 27 Apr 2001 07:21:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 07:57:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24443 for ; Fri, 27 Apr 2001 07:57:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27338; Fri, 27 Apr 2001 07:36:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27308 for ; Fri, 27 Apr 2001 07:36:42 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23782 for ; Fri, 27 Apr 2001 07:36:39 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 08:16:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25400 for ; Fri, 27 Apr 2001 08:16:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27816; Fri, 27 Apr 2001 07:52:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27782 for ; Fri, 27 Apr 2001 07:52:14 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24286 for ; Fri, 27 Apr 2001 07:52:12 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Apr 27 08:27:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25892 for ; Fri, 27 Apr 2001 08:27:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28400; Fri, 27 Apr 2001 08:07:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28372 for ; Fri, 27 Apr 2001 08:07:47 -0400 (EDT) Received: from hotmail.com (f105.law3.hotmail.com [209.185.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24867 for ; Fri, 27 Apr 2001 08:07:45 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Apr 2001 19:25:09 -0700 Received: from 32.100.64.165 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 27 Apr 2001 02:25:09 GMT X-Originating-IP: [32.100.64.165] From: "amuratt 齦oglu" To: diffserv@ietf.org Date: Fri, 27 Apr 2001 05:25:09 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Apr 2001 02:25:09.0914 (UTC) FILETIME=[480C27A0:01C0CEC1] Subject: [Diffserv] Diffserv Complaint in terms of DSCP Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In RFC 791 and RFC 1812, it is recommended not to use IP PRE 6 and 7 for user traffic ( reserved for internetwork and network control traffic). Can anyone argueits diffserv compatibility If somebody use 110 or 111 Class Selector Code point in defining user data classes. Plaese send your comments Ali Iloglu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 06:19:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03819 for ; Mon, 30 Apr 2001 06:19:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05448; Mon, 30 Apr 2001 05:48:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05417 for ; Mon, 30 Apr 2001 05:48:30 -0400 (EDT) Received: from mta3.263.net ([202.96.44.45]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03527 for ; Mon, 30 Apr 2001 05:48:28 -0400 (EDT) Received: by mta3.263.net (Postfix, from userid 60001) id 1834148DA0; Mon, 30 Apr 2001 17:48:30 +0800 (CST) MIME-Version: 1.0 Message-Id: <3AED34EE.11027@mta3> Date: Mon, 30 Apr 2001 17:48:30 +0800 (CST) From: "Zhou Wei" To: diffserv@ietf.org, end2end-interest@postel.org X-Priority: 3 X-Originating-IP: [216.104.228.154] Subject: [Diffserv] Detailed Evaluation of CSFQ ? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Type: text/plain; charset=unknown-8bit X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id FAA05448 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03819 Hi, I am a student from Tsinghua University. Could you tell me where I can find a detailed evaluation of Core Stateless Fair Queueing from CMU ? How is it working ? Thank you very much! Zhou Wei _____________________________________________ 化妆品热卖，淑女也疯狂 http://shopping.263.net/category04.htm 精品MP3、随身听，价格震撼 http://shopping.263.net/fs/81shop/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 06:25:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03896 for ; Mon, 30 Apr 2001 06:25:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05535; Mon, 30 Apr 2001 05:59:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05512 for ; Mon, 30 Apr 2001 05:59:35 -0400 (EDT) Received: from sophia.inria.fr ([138.96.32.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03637 for ; Mon, 30 Apr 2001 05:59:33 -0400 (EDT) Received: from sophia.inria.fr by sophia.inria.fr (8.11.1/8.10.0) with ESMTP id f3U9xPD23214; Mon, 30 Apr 2001 11:59:25 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host rover.inria.fr [138.96.88.61] claimed to be sophia.inria.fr Message-ID: <3AED3777.C1254AE0@sophia.inria.fr> Date: Mon, 30 Apr 2001 11:59:19 +0200 From: Fethi Filali Organization: INRIA Sophia-Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: Zhou Wei CC: diffserv@ietf.org, end2end-interest@postel.org Subject: Re: [Diffserv] Detailed Evaluation of CSFQ ? References: <3AED34EE.11027@mta3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Try this link: http://www.cs.cmu.edu/~istoica/csfq/ Zhou Wei wrote: > > Hi, > > I am a student from Tsinghua University. Could you tell me where I can find a detailed evaluation of Core Stateless Fair Queueing from CMU ? How is it working ? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 08:06:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06336 for ; Mon, 30 Apr 2001 08:06:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07192; Mon, 30 Apr 2001 07:45:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07165 for ; Mon, 30 Apr 2001 07:45:04 -0400 (EDT) Received: from omta03.mta.everyone.net ([216.200.145.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05810 for ; Mon, 30 Apr 2001 07:45:02 -0400 (EDT) Received: from sitemail.everyone.net (reports [216.200.145.62]) by omta03.mta.everyone.net (Postfix) with ESMTP id 1C51C4A3CA; Mon, 30 Apr 2001 04:42:54 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id E937B36F9; Mon, 30 Apr 2001 04:42:49 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) Date: Mon, 30 Apr 2001 04:42:49 -0700 (PDT) From: Mark Davis To: "Zhou Wei" , diffserv@ietf.org, end2end-interest@postel.org Subject: Re: [Diffserv] Detailed Evaluation of CSFQ ? Reply-To: mtdavis@techemail.com X-Originating-Ip: [4.48.153.235] Message-Id: <20010430114249.E937B36F9@sitemail.everyone.net> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id HAA07192 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06336 There is another paper (from CMU too) at: http://www.ece.cmu.edu/~haifengz/scale-wfs/ that fully evaluates CSFQ with different flow weights, Round Trip Times, protocols (TCP and UDP), under exact-, over- and under-provisionings and multiple congested gateways. It seems CSFQ is not working well in many cases, while the Three Color Marker works pretty well sometimes. It also comments on some other schemes. Hope this helps. Regards, Mark --- "Zhou Wei" > wrote: >Hi, > >I am a student from Tsinghua University. Could you tell me where I can find a detailed evaluation of Core Stateless Fair Queueing from CMU ? How is it working ? > >Thank you very much! > >Zhou Wei > >_____________________________________________ >化妆品热卖，淑女也疯狂 http://shopping.263.net/category04.htm >精品MP3、随身听，价格震撼 http://shopping.263.net/fs/81shop/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _____________________________________________________________ Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 08:41:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07533 for ; Mon, 30 Apr 2001 08:41:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07646; Mon, 30 Apr 2001 08:06:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07601 for ; Mon, 30 Apr 2001 08:06:23 -0400 (EDT) Received: from sophia.inria.fr ([138.96.32.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06316 for ; Mon, 30 Apr 2001 08:06:21 -0400 (EDT) Received: from sophia.inria.fr by sophia.inria.fr (8.11.1/8.10.0) with ESMTP id f3UC67D27887; Mon, 30 Apr 2001 14:06:09 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host rover.inria.fr [138.96.88.61] claimed to be sophia.inria.fr Message-ID: <3AED552A.8D3D689F@sophia.inria.fr> Date: Mon, 30 Apr 2001 14:06:02 +0200 From: Fethi Filali Organization: INRIA Sophia-Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: mtdavis@techemail.com CC: Zhou Wei , diffserv@ietf.org, end2end-interest@postel.org Subject: Re: [Diffserv] Detailed Evaluation of CSFQ ? References: <20010430114249.E937B36F9@sitemail.everyone.net> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id f3UC67D27887 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA07602 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id IAA07646 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA07533 A new stateless mechanism which perform better and less complex than CSFQ in this INFOCOM 2001 paper: TUF : Tag-based Unified Fairness Antoine Clerget (INRIA), Walid Dabbous (INRIA) availabe at : http://infocom.ucsd.edu/papers/666.ps Mark Davis wrote: > > There is another paper (from CMU too) at: > > http://www.ece.cmu.edu/~haifengz/scale-wfs/ > > that fully evaluates CSFQ with different > flow weights, Round Trip Times, protocols (TCP and UDP), under exact-, over- and under-provisionings and multiple congested gateways. > > It seems CSFQ is not working well in many cases, while the Three Color Marker works pretty well sometimes. > It also comments on some other schemes. Hope this helps. > > Regards, > > Mark > > --- "Zhou Wei" > > wrote: > >Hi, > > > >I am a student from Tsinghua University. Could you tell me where I can find a detailed evaluation of Core Stateless Fair Queueing from CMU ? How is it working ? > > > >Thank you very much! > > > >Zhou Wei > > > >_____________________________________________ > >化妆品热卖，淑女也疯狂 http://shopping.263.net/category04.htm > >精品MP3、随身听，价格震撼 http://shopping.263.net/fs/81shop/ > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _____________________________________________________________ > Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- 0----------------------------------------------------------------0 | Fethi Filali | http://www.inria.fr/planete/filali | | Ph.D. Student, INRIA | Work: +33 4 92 38 76 70 | | Fax: +33 4 92 38 79 78 | Cellular: +33 6 20 32 85 73 | 0----------------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 10:09:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11304 for ; Mon, 30 Apr 2001 10:09:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09247; Mon, 30 Apr 2001 09:43:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09220 for ; Mon, 30 Apr 2001 09:43:02 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09854 for ; Mon, 30 Apr 2001 09:43:02 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 261 for ; Mon, 30 Apr 2001 09:45:23 -0400 From: "Susie Riley" To: Date: Mon, 30 Apr 2001 09:45:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] questions regarding ipsec and diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit hi, i've been reading up on vpns and ipsec, and i've got a question for the diffserv group - if someone could shed some light in this matter i would really appreciate it. once a packet is encrypted according to ipsec, the tcp header is no longer visible to any edge router that is trying to perform the diffserv function. this means the diffserv classifier can only examine the ip header for encrypted packets. is this considered to be an issue for diffserv? will not the proliferation of ipsec on PCs (soon ipsec will become standard issue on microsoft os)and PKI mean that eventually a large number of sessions over the internet will be encrypted, thus challenging the usefulness of diffserv's 5-tuple approach? thanks in advance, susie ****************************** Susie Kim Riley * Senior Consulting Engineer * ADCT * Tel: 508-898-8840 * ****************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 11:43:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15973 for ; Mon, 30 Apr 2001 11:43:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10801; Mon, 30 Apr 2001 11:13:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10768 for ; Mon, 30 Apr 2001 11:13:15 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14566 for ; Mon, 30 Apr 2001 11:13:13 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA56748; Mon, 30 Apr 2001 17:12:42 +0200 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36706 from ; Mon, 30 Apr 2001 17:12:39 +0200 Message-Id: <3AED804B.E3145DAF@hursley.ibm.com> Date: Mon, 30 Apr 2001 10:10:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Susie Riley Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Interaction with IPSEC is discussed in several diffserv RFCs (2474, 2475 and 2983). RFC 2983 is the most relevant to your question. The problem you raise is real enough, and it's why diffserv marking by the originating host (i.e. before encryption) is a useful mechanism. Brian Carpenter Susie Riley wrote: > > hi, > > i've been reading up on vpns and ipsec, and i've got a question for the > diffserv group - if someone could shed some light in this matter i would > really appreciate it. > > once a packet is encrypted according to ipsec, the tcp header is no longer > visible to any edge router that is trying to perform the diffserv function. > this means the diffserv classifier can only examine the ip header for > encrypted packets. is this considered to be an issue for diffserv? will > not the proliferation of ipsec on PCs (soon ipsec will become standard issue > on microsoft os)and PKI mean that eventually a large number of sessions over > the internet will be encrypted, thus challenging the usefulness of > diffserv's 5-tuple approach? > > thanks in advance, > susie > > ****************************** > Susie Kim Riley * > Senior Consulting Engineer * > ADCT * > Tel: 508-898-8840 * > ****************************** > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 11:48:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16258 for ; Mon, 30 Apr 2001 11:48:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10883; Mon, 30 Apr 2001 11:16:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10852 for ; Mon, 30 Apr 2001 11:16:35 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14660 for ; Mon, 30 Apr 2001 11:16:33 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA41520; Mon, 30 Apr 2001 17:16:01 +0200 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25718 from ; Mon, 30 Apr 2001 17:15:58 +0200 Message-Id: <3AED8111.671994B5@hursley.ibm.com> Date: Mon, 30 Apr 2001 10:13:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Fethi Filali Cc: mtdavis@techemail.com, Zhou Wei , diffserv@ietf.org Subject: Re: [Diffserv] Detailed Evaluation of CSFQ ? References: <20010430114249.E937B36F9@sitemail.everyone.net> <3AED552A.8D3D689F@sophia.inria.fr> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10853 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA10883 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16258 Hi. This discussion belongs on the diffserv-interest or ds-implementation list. Brian Carpenter diffserv co-chair Fethi Filali wrote: > > A new stateless mechanism which perform better and less complex than > CSFQ in this INFOCOM 2001 paper: > > TUF : Tag-based Unified Fairness > Antoine Clerget (INRIA), Walid Dabbous (INRIA) > > availabe at : http://infocom.ucsd.edu/papers/666.ps > > Mark Davis wrote: > > > > There is another paper (from CMU too) at: > > > > http://www.ece.cmu.edu/~haifengz/scale-wfs/ > > > > that fully evaluates CSFQ with different > > flow weights, Round Trip Times, protocols (TCP and UDP), under exact-, over- and under-provisionings and multiple congested gateways. > > > > It seems CSFQ is not working well in many cases, while the Three Color Marker works pretty well sometimes. > > It also comments on some other schemes. Hope this helps. > > > > Regards, > > > > Mark > > > > --- "Zhou Wei" > > > wrote: > > >Hi, > > > > > >I am a student from Tsinghua University. Could you tell me where I can find a detailed evaluation of Core Stateless Fair Queueing from CMU ? How is it working ? > > > > > >Thank you very much! > > > > > >Zhou Wei > > > > > >_____________________________________________ > > >化妆品热卖，淑女也疯狂 http://shopping.263.net/category04.htm > > >精品MP3、随身听，价格震撼 http://shopping.263.net/fs/81shop/ > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _____________________________________________________________ > > Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > 0----------------------------------------------------------------0 > | Fethi Filali | http://www.inria.fr/planete/filali | > | Ph.D. Student, INRIA | Work: +33 4 92 38 76 70 | > | Fax: +33 4 92 38 79 78 | Cellular: +33 6 20 32 85 73 | > 0----------------------------------------------------------------0 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 12:06:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16945 for ; Mon, 30 Apr 2001 12:06:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11443; Mon, 30 Apr 2001 11:37:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11419 for ; Mon, 30 Apr 2001 11:37:53 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15668 for ; Mon, 30 Apr 2001 11:37:52 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 139; Mon, 30 Apr 2001 11:40:07 -0400 From: "Susie Riley" To: "Brian E Carpenter" Cc: Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Mon, 30 Apr 2001 11:40:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AED804B.E3145DAF@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit yes, i understand about the diffserv marking by the originating host, but devices at the edge may want to remark the packet because it wants to mark the packets based on its policies, instead of 'trusting' the end station. it seems the discussions in the rfcs are primarily relevant for tunnel terminating edge devices - the scenario i am talking about is the case of a home PC, hooking up to a provider. yes, the pc will have to do the 'right' marking, but the edge device at the provider may want to be able to verify or reclassify based on the 5-tuple. i guess what it comes down to in this scenario is that provider edge devices will only be able to classify based on the top level ip header for ipsec packets, and there's no way to get around this limitation. would you agree? is this an issue the diffserv group is going to explore further? susie -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Monday, April 30, 2001 11:10 AM To: Susie Riley Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Interaction with IPSEC is discussed in several diffserv RFCs (2474, 2475 and 2983). RFC 2983 is the most relevant to your question. The problem you raise is real enough, and it's why diffserv marking by the originating host (i.e. before encryption) is a useful mechanism. Brian Carpenter Susie Riley wrote: > > hi, > > i've been reading up on vpns and ipsec, and i've got a question for the > diffserv group - if someone could shed some light in this matter i would > really appreciate it. > > once a packet is encrypted according to ipsec, the tcp header is no longer > visible to any edge router that is trying to perform the diffserv function. > this means the diffserv classifier can only examine the ip header for > encrypted packets. is this considered to be an issue for diffserv? will > not the proliferation of ipsec on PCs (soon ipsec will become standard issue > on microsoft os)and PKI mean that eventually a large number of sessions over > the internet will be encrypted, thus challenging the usefulness of > diffserv's 5-tuple approach? > > thanks in advance, > susie > > ****************************** > Susie Kim Riley * > Senior Consulting Engineer * > ADCT * > Tel: 508-898-8840 * > ****************************** > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Apr 30 12:44:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18466 for ; Mon, 30 Apr 2001 12:44:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12461; Mon, 30 Apr 2001 12:21:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12430 for ; Mon, 30 Apr 2001 12:21:04 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17483 for ; Mon, 30 Apr 2001 12:21:01 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA44590; Mon, 30 Apr 2001 18:20:31 +0200 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52560 from ; Mon, 30 Apr 2001 18:20:28 +0200 Message-Id: <3AED9010.8AD1C530@hursley.ibm.com> Date: Mon, 30 Apr 2001 11:17:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Susie Riley Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit What you say is correct. Actually there is nothing diffserv can do about it. It would need a change to IPSEC (to avoid encrypting the transport header). Somehow that doesn't seem very likely. Brian Susie Riley wrote: > > yes, i understand about the diffserv marking by the originating host, but > devices at the edge may want to remark the packet because it wants to mark > the packets based on its policies, instead of 'trusting' the end station. > > it seems the discussions in the rfcs are primarily relevant for tunnel > terminating edge devices - the scenario i am talking about is the case of a > home PC, hooking up to a provider. yes, the pc will have to do the 'right' > marking, but the edge device at the provider may want to be able to verify > or reclassify based on the 5-tuple. i guess what it comes down to in this > scenario is that provider edge devices will only be able to classify based > on the top level ip header for ipsec packets, and there's no way to get > around this limitation. would you agree? is this an issue the diffserv > group is going to explore further? > > susie > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, April 30, 2001 11:10 AM > To: Susie Riley > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > Interaction with IPSEC is discussed in several diffserv RFCs > (2474, 2475 and 2983). RFC 2983 is the most relevant to your > question. > > The problem you raise is real enough, and it's why diffserv marking > by the originating host (i.e. before encryption) is a useful mechanism. > > Brian Carpenter > > Susie Riley wrote: > > > > hi, > > > > i've been reading up on vpns and ipsec, and i've got a question for the > > diffserv group - if someone could shed some light in this matter i would > > really appreciate it. > > > > once a packet is encrypted according to ipsec, the tcp header is no longer > > visible to any edge router that is trying to perform the diffserv > function. > > this means the diffserv classifier can only examine the ip header for > > encrypted packets. is this considered to be an issue for diffserv? will > > not the proliferation of ipsec on PCs (soon ipsec will become standard > issue > > on microsoft os)and PKI mean that eventually a large number of sessions > over > > the internet will be encrypted, thus challenging the usefulness of > > diffserv's 5-tuple approach? > > > > thanks in advance, > > susie > > > > ****************************** > > Susie Kim Riley * > > Senior Consulting Engineer * > > ADCT * > > Tel: 508-898-8840 * > > ****************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html